Formal Requirements Elicitation Tool(github.com)
github.com
Formal Requirements Elicitation Tool
https://github.com/NASA-SW-VnV/fret
30 comments
Reminds me of Planguage by Tom Gilb, see e.g. https://www.amazon.com/-/de/dp-0750665076/dp/0750665076.
Many attempts have been made with varying degrees of formalization. Another one is e.g. https://en.wikipedia.org/wiki/Gellish.
It would be interesting to know what FRET is supposed to be able to do better than previous approaches.
Many attempts have been made with varying degrees of formalization. Another one is e.g. https://en.wikipedia.org/wiki/Gellish.
It would be interesting to know what FRET is supposed to be able to do better than previous approaches.
This is the first time I heard about the "NASA Open Source Agreement" [0] software license, which, sadly, is not GPL-compatible. I am confused why a government agency can release something more restrictive than the public domain.
I wish license awareness was a part of more discussions. I've noticed a trend on HN to be dismissive or unaware of the implications of such things until it's too late.
[0] https://en.wikipedia.org/wiki/NASA_Open_Source_Agreement
I wish license awareness was a part of more discussions. I've noticed a trend on HN to be dismissive or unaware of the implications of such things until it's too late.
[0] https://en.wikipedia.org/wiki/NASA_Open_Source_Agreement
The work was probably done by a contractor. In that case it’s not a work of the US Government and the government can be assigned copyright.
> which, sadly, is not GPL-compatible
A lot of even more common open-source licences are not "GPL compatible", mostly because they don't require "copyleft" (which also applies to the NASA license). All approaches have their specific advantages and disadvantages. GPL has disadvantages as well.
A lot of even more common open-source licences are not "GPL compatible", mostly because they don't require "copyleft" (which also applies to the NASA license). All approaches have their specific advantages and disadvantages. GPL has disadvantages as well.
A license doesn't have to be copyleft to be GPL compatible.
In fact, permissive licenses are much more likely to be GPL compatible/combine-able because they don't care if you relicense the combined work to GPL, whereas copyleft licenses are much more likely to include a provision that the result can only be under the same license, and since GPL imposes the same requirement you're left with incompatibility.
Unless you want to use GPL code in your project which uses a non-copyleft license?
There are many licenses that have fewer requirements than a GPL or copyleft license. People can take that code and make their own versions that are proprietary/closed source for example. If the license is "compatible" then it allows anything the GPL or copyleft requires and is similar to a company taking the code and making it proprietary as far as the original license is concerned.
I.e. then GPL is not "your non-copyleft license"-compatible. License compatibility often is not bidirectional.
CDDL and GPL are both copyleft. They are not compatible.
Pls define "compatible"; this is a totally ambiguous/undefined term; that's why I put it in quotes in all of my comments.
It's a perfectly well accepted term in context (jargon); if it's new to you then that's fine but it's not a fault of the term. When you use open source code, you have to comply with the license requirements on that code. Sometimes, it's possible to combine code because the licenses can both be applied to the combined result at the same time. For instance, many permissive licenses boil down to a requirement that you include the original author in credits for the program. The GPL requires that you share the source code that went into a binary with anybody who gets a copy of binary (basically). Since you can fulfill both of these requirements at the same time, you can freely combine code into the two licenses (although the result will effectively be all GPL), so they're compatible. Because GPL & CDDL both require that the relevant code must be licensed under their license specifically, you can't fulfill both requirements at the same time unless the code was originally dual-licensed by the original authors, because you can't change GPL code to CDDL or vice-versa.
(IANAL and this is simplified; tread cautiously)
(IANAL and this is simplified; tread cautiously)
Thanks. The question was meant more rhetorically, since lawyers (I also studied law) usually have a hard time with OSS licenses, and many developers make assumptions that often don't match reality. A seemingly "well accepted" assumption often turns out to be a costly mistake. I therefore share your recommendation: tread cautiously.
"Compatible" means that two licenses don't have terms/conditions that contradict. CDDL was deliberately designed to conflict with GPL.
For example https://www.fsf.org/licensing/zfs-and-linux
For example https://www.fsf.org/licensing/zfs-and-linux
CDDL wasn't deliberately designed to be incompatible with GPL - that's one person's off-hand remark at one conference. Simultaneously we know that teams that insisted against GPLv3 expected that CDDL code will be compatible with GPLv2 projects like linux.
> means that two licenses don't have terms/conditions that contradict
This approach is too simplistic. It should also be remembered that each state has its own legislation and the effect and enforceability (and thus the "compatibility") of the licenses differs in each country. It also depends on what you specifically intend to do with the OSS licensed components. A conclusion can only be reached for the specific case at hand, not in general. As long as there are no supreme court rulings for the specific case or a sufficiently similar case, the legal situation remains uncertain.
This approach is too simplistic. It should also be remembered that each state has its own legislation and the effect and enforceability (and thus the "compatibility") of the licenses differs in each country. It also depends on what you specifically intend to do with the OSS licensed components. A conclusion can only be reached for the specific case at hand, not in general. As long as there are no supreme court rulings for the specific case or a sufficiently similar case, the legal situation remains uncertain.
There's plenty of enforcement precedent. The fact that big-pocket companies settle rather than go to court against the FSF says more than you think it does.
> There's plenty of enforcement precedent.
Unfortunately not. There are some rulings on a few issues, but far too few to establish solid practice.
> settle rather than go to court
Unfortunately, this is a practice that is already known from the patent field, and which unfortunately also opens the door to trolls. Especially the big companies would have the necessary budget to have important license issues clarified in court. By the way, the FSF and others could also take legal action on various unclear points of their license, but they knowingly refrain from doing so because the risk is too great for them, too.
Unfortunately not. There are some rulings on a few issues, but far too few to establish solid practice.
> settle rather than go to court
Unfortunately, this is a practice that is already known from the patent field, and which unfortunately also opens the door to trolls. Especially the big companies would have the necessary budget to have important license issues clarified in court. By the way, the FSF and others could also take legal action on various unclear points of their license, but they knowingly refrain from doing so because the risk is too great for them, too.
FSF and SFC take plenty of enforcement actions and are quite successful. You seem to be just spreading lawyer FUD.
Then maybe you can provide references to the leading judgments in matters of e.g. "Tivoization" or termination/reinstatement of the license.
> As long as there are no supreme court rulings for the specific case or a sufficiently similar case, the legal situation remains uncertain.
By that standard, no open Source license is understandable or tested in any situation, forget combining them.
By that standard, no open Source license is understandable or tested in any situation, forget combining them.
This is a reason why many companies still avoid using OSS altogether.
This is fantastic if you don't mind your requirements being out of date by the time you finish writing them down. That is assuming your business stays alive long enough.
Jokes aside, I would suggest not to corrupt your mind by looking at it, unless you are responsible for a complex safety critical application (never good idea to mix complex and safety critical -- you likely have more important problem to solve) or where a single software error can cause multi-billion dollar loss (never good idea to design your application so that single error can cause huge loss -- you likely have more important problems to solve).
I have seen many attempts to formalise requirements this way and they all utterly failed. Main reason being that the people who tried to implement it were not ready for the vast effort needed to actually get it done and then to maintain it as requirements inevitably change.
But the more fundamental reason for all these failures was that there always have been much more important things to get done and people who pushed these tools just did not understand what is important and this usually ends in project failure.
Jokes aside, I would suggest not to corrupt your mind by looking at it, unless you are responsible for a complex safety critical application (never good idea to mix complex and safety critical -- you likely have more important problem to solve) or where a single software error can cause multi-billion dollar loss (never good idea to design your application so that single error can cause huge loss -- you likely have more important problems to solve).
I have seen many attempts to formalise requirements this way and they all utterly failed. Main reason being that the people who tried to implement it were not ready for the vast effort needed to actually get it done and then to maintain it as requirements inevitably change.
But the more fundamental reason for all these failures was that there always have been much more important things to get done and people who pushed these tools just did not understand what is important and this usually ends in project failure.
This looks comprehensive. What commercial software does this replace / compete with? Does one exist?
There are a lot. I work in the industry and IBM Doors is the traditional tool but everyone hates it. Jama and Valispace are more modern tools, and there are various addons for JIRA as well. Those are all for general use, if you consider software requirements there are a ton of other tools.
MS Word plus manual tracking is also common but revision and configuration is control is a nightmare.
MS Word plus manual tracking is also common but revision and configuration is control is a nightmare.
i wonder what tool was used to gather the requirements for FRET?
It requires python2. Guess there was some red tape involved.
Instead, it's:
1. having domain experts understand the requirements well-enough to recognize and push back on impossible/impractical requirements (this being the reason the person doing the requirements-gathering is almost always an engineer of some kind); and
2. communicating that impossibility/impracticality back to the client, so that they'll understand it well-enough to be able to iterate on the requirements (or, potentially, realize that the problem is now entirely impossible/impractical to be solved with the general approach they have in mind.)
Is there any tool in this category that tries to eliminate at least some of this human labor, acting as a "compiler for requirements" that can be fed "requirements validation rules" — or maybe constructing the requirements into an expert system or proof-language and running it to find contradictions?
Not as something to assist the engineer in validating, to be clear (there's plenty of those); but rather as something to sit as the equivalent of a "level-one CSR" in front of engineers, to give some level of pre-validation to things before they're tasked with fully validating them. Something that could live on the backend of a "Requirements Elicitation" tool like this, to act as a CI system, preventing clients from "finalizing" their requirements until they've corrected any obvious errors.