I really like this and wanted this on my own projects rather than downgrading to MIT. Personally I really like the strong patent guarantees in the Apache 2.0 license.
The question is, isn't this a new license? Should this be considered the Apache 2.1 or Apache 2.c for compatible?
I'd like to reuse this license provision and drop My use of MIT.
The GCC makes the similar exceptions. Libs/Snippets from peephole optimizations are technically covered by the compiler's license as they're part of the compiler. So the output program is in a sense a derivative work. This really hasn't been challenged in court, but you can see how this could invoke a rather lengthy case if you say pissed off Peter Thiel.
To cover this the GCC's GPL license has exceptions to the GPLv3 for output programs, or programs that use it's headers. You really can't argue the GCC isn't licensed by the GPL. It merely has a handful of exceptions that are specific to the legal oddity of a program who's copyright copyrights derived works, and its sole purpose is to produce derived works.
The Linux Kernel has similar exceptions as syscall functions are inserted into your program at load time. And really everything links against it's headers.
GPLv3 has a framework for exceptions built-in. Apache 2.0 supposes no exceptions. The question is why FSF/SFLC thought it insufficient to simply enumerate the exceptions alongside the license.
The exceptions provide gpl2 compatibility, gplv3 is already compatible with Apache 2.
As for why nobody did this before, i suspect the fsf wanted folks to move to gplv3, and neither side really wanted to do something like this. There are disadvantages to doing it like this, but it was felt this was the best we could really do.
Remember also that both those organizations have very different goals.
ASLv2 is compatible with GPLv3 (works under ASLv2 can be inorporated into GPLv3), but not vice versa. This is because GPL has (arguably useful) restrictions which ASL does not. A common goal of ASLv2 and GPLv3 is the restriction on patents, which makes them both incompatible with GPLv2. This is an important difference which makes GPLv3 a superior freedom-preserving license to v2, and the resulting incompatibility is not a matter of interpretation - you can't downgrade licenses. It is unfortunate that Linux was not licensed as GPLv2 or later which is, alongside Linus' support for TiVoization(DrM) and the corporate lawyers' spreading of FUD, the reason why we're still forced to discuss GPLv2.
"The question is, isn't this a new license? Should this be considered the Apache 2.1 or Apache 2.c for compatible?
"
No.
It's literally not.
It's the apache license, it's just saying "you can do these things even though you normally can't".
It's essentially "a set of additional permissions and guarantees".
This is the same way adding an explicit separate rights grant does not make a new license, it is just an explicit separate set of rights.
I could release software under the GPL, and put alongside it a file that says "Though all of this software is licensed under the GPL, you are allowed to do whatever you want with it, including violate the GPL".
That is not a new license, it's a covenant not to enforce :)
Careful, though. The GPL has a no-added-restrictions clause which says that if you receive the work covered under the GPL and additional text that has additional restrictions, you may disregard the additional text. It's like a failsafe against homebrew license writers who might want to distribute the work under the GPL plus some other shenanigans.
Removing restrictions is always ok, though. That's like the linking exception GNU Classpath:
I'm very aware, i helped write the current exception used with GCC, et al :)
Note that it only grants additional permissions, it contains no additional restrictions.
Additionally, in the absolute worst case, and we screw it up, the GPL folks are in no worse a position than if we had just used apache2 without exceptions :)
> says that if you receive the work covered under the GPL and additional text that has additional restrictions, you may disregard the additional text.
No, it doesn't (EDIT: as below, the GPLv3 actually does, I had forgotten this element of its changes from the GPLv2 in the additional terms area; there's good downthread discussion of this and its effects, I'm not going to revise the rest of this piece to address it.) It says that it is illegal to add additional restrictions to GPL covered work. It does not say that if you receive a work with the GPL and other restrictive text you may ignore the other restrictive text, nor is that its effect (its effect that if the author was legally obligated to release a work under the GPL because it was derivative of an upstream GPL-licensed work, then the author releasing it with additional restrictive text is in violation of the GPL and can be subject to whatever the legal system decides to assign as a sanction for that violation. Absent a decision by the legal system to do so, or compelling the author to do so, that doesn't give anyone else downstream permission to use that author's work other than under the conditions -- the GPL with the additional restrictions -- which they released it with.) And there are certainly situations where the legal system would not compel the distributor of the work distributed with the GPL + additional restrictions to allow it to be used GPL only (such as where the work was a derivative of both GPL work and work under a different licenses requiring some other restrictions.)
And if the GPL + additional restrictions was the decision of the original author, it doesn't even have that effect (and what downstream effect it has is less clear.)
“If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.”
Dragonwriter is correct about GPLv2.
You are correct about GPlv3.
FWIW: This does not actually make it true :)
I do not believe this is actually sufficient to override superseding written contracts with a complete integration clause.
I think those superseding written contracts just cause a license violation instead.
(IE the end result would be "you would be in breach of the written contract with the restriction", "they would be in breach of the GPL").
The GPL attempts to create privity through licensing through the original licensor, in order to try to make this work. It's not clear this will be successful in a court of law, however (I suspect this also varies by country). I believe the drafting committee that looked into this came to the same conclusion.
This is the same way adding an explicit separate rights grant does not make a new license, it is just an explicit separate set of rights.
Them's some strikingly lawyerly semantics. If I were to release a work without a license (governed by the default of copyright law), and then explicitly grant a few new rights that don't exist in the absence of that "set of rights", non-lawyers might be inclined to think of this as a "new license".
Are you saying that it's a not a license if you unilaterally grant rights without requiring anything of the user, or is there something more subtle here?
FWIW: This does not actually make it true :)
Speaking of that, what's the extent of case law for open-source licenses? Is there a compilation somewhere of decisions that make for good background reading?
The law explicitly makes a difference between consistent additional terms/amendments and new agreements :)
So i'm not shocked you find it this way, but it is what it is ...
Basically, there is a difference between having an agreement that happens to be spread out over multiple things, and two separate agreements.
If you next try to ask where that line is, without a complete integration clause, the answer is basically ¯\_(ツ)_/¯ without going to court. You will get different answers from different folks.
"If I were to release a work without a license (governed by the default of copyright law), and then explicitly grant a few new rights that don't exist in the absence of that "set of rights", non-lawyers might be inclined to think of this as a "new license"."
Well, this is a slightly different case. In this case, you had no rights at all, and you are giving rights for the first time. This probably semantically would be viewed as a new license.
In the LLVM case, there is a license agreement. It is being supplemented :)
"Speaking of that, what's the extent of case law for open-source licenses? Is there a compilation somewhere of decisions that make for good background reading?
"
Sadly, no.
There's basically only one or two decisions you can find at all.
The rest is basically viewpoints based on contract law.
"Speaking of that, what's the extent of case law for open-source licenses? Is there a compilation somewhere of decisions that make for good background reading? "
Sadly, no. There's basically only one or two decisions you can find at all.
Something is better than nothing. Can you name the ones that you think are relevant and readable?
and all the related appeals.
This covers whether or not license violations are copyright infringement or breach of contract (something OSS lawyers felt was not settled for some reason, but has actually been well settled out in hollywood for many many years), what damages are for GPL if nobody is charging, etc.
There is also busybox v. westinghouse and some other german cases as well i will try to pull out and paste links to here when i get a chance.
You really shouldn't call it “Apache <anything>” without the express approval of the Apache foundation. If you want to call it something other than “Modified Apache 2.0”, you'll have to come up with a new name.
Though what's interesting is that since the license text itself is not explicitly under any license, it's technically just under regular copyright.
LLVM explicitly chose not to create a new license (this was one of the goals of doing this).
The issues we faced were simply those of license compatibility and attribution for runtime libraries, and we chose what we saw as the simplest set of additional permissions to make those work.
(For example, if we didn't care about the usage of LLVM in GPL software, we could have avoided all of the exception related wording here. Instead, we tried to come up with something that would let them still be able to use LLVM without worrying about various compatibility boogeymen)
MPL2 requires that you make available the source of any changed files. Apple builds its version of LLVM off of a patched tree, and given that they're not particularly open about even the base revision of the public LLVM repositories their stuff is on, I can't imagine they would be happy having to publish those files publicly.
Yes.
We want folks to be able to keep their private chips private.
Past that, Mpl has some interesting baggage and requirements, and in the end, folks wanted something they all understood well, felt others would understand well, etc.
It's not a bad license, mind you. This was just the best path in terms of resistance, complexity, etc
The current license is effectively the MIT license, which lets downstream developers repackage the code for development works to do what they want, with the most important boilerplate being the part that says "we're not legally liable if this software causes problems."
The biggest flaw of MIT-like licenses is their silence on patent issues, compilers unfortunately being one of the cases where patents are indeed an issue (SEH and Steensgards being two major things well-known as being under patent). Legal opinions differ on what the effect is, and some companies with more aggressive legal departments are twitchy about the matter.
The Apache license covers patents in a satisfactory way while still retaining the permissibility of the MIT license. However, Apache and GPL aren't necessarily compatible with each other--Apache v2 and GPLv3 work around it by adding explicit compatibility clauses. The Apache v2/GPLv2 compatibility story is something that legal opinions differ on [1]. The exceptions being proposed are designed to explicitly guarantee compatibility between the two licenses.
[1] The consensus seems to be that it would just work. However, it is worth keeping in mind that Apple is a prominent contributor to LLVM, and Apple does seem to generally take a more pessimistic legal approach, as well as being very well-known for their abhorrence of GPLv3 code.
If users care about freedom why are they choosing software that violate their freedom? Probably because the software does what they need and I'd rather see proprietary software where some parts are MIT licensed than software that is entirely proprietary.
Depends on whether or not you believe that "freedom to not respect other users' freedom by creating proprietary forks" is a freedom that should be protected. I do not, so I disagree that the GPL (or any free software license) respects user freedom more or less -- the GPL is just much better at protecting freedom than other licenses.
I really like this and wanted this on my own projects rather than downgrading to MIT. Personally I really like the strong patent guarantees in the Apache 2.0 license.
The question is, isn't this a new license? Should this be considered the Apache 2.1 or Apache 2.c for compatible?
I'd like to reuse this license provision and drop My use of MIT.