-
Notifications
You must be signed in to change notification settings - Fork 6.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add (part of) the LLVM Exception to the License #55861
Comments
The GPL license specifically states this, so can you expand on how this is in any way, shape or form compatible with the apache 2 license?
|
The Apache foundation claims that it's compatible in one way, that is, you can combine GPLv2 and Apache 2.0 code and treat the result as GPLv2. This would be similar to how u-boot uses GPLv2+ for most things, but some driver code is ported from Linux and thus GPLv2. If you don't select any GPLv2 code to be compiled into the resulting binary, then the resulting binary would be GPLv2+, since it only links in GPLv2+ code. The FSF claims that the patent clause in the Apache license means the licenses are incompatible in both ways, which would be unfortunate. The LLVM exception (resp. the part that pertains to this) says that IF a court should determine that the FSF was right, you can ignore those patent clauses AS LONG AS the combined work would be considered as GPLv2. Note: both the Apache foundation and the FSF consider GPLv3 to be one-way compatible with Apache 2.0, which is great, but that doesn't necessarily help with avoiding duplicate work since most Linux drivers are GPLv2 only |
Right so zephyr is apache licensed, the idea being that you do not have to distribute the application source code in a finished product, why would that wanted to be changed to a GPL license whereby source code must be provided? |
right now, any third party can't use zephyr together with GPLv2 code |
@Mis012 thanks for the proposal. I've pinged @kestewart and @nashif internally and this will be discussed in the TSC. |
Be that as it may, the "gathering agreements from all developers" part is going to be extremely difficult, if not impossible, considering the number of developers who have contributed to Zephyr (over 1500 people). |
well, the LLVM project is arguably even larger, and they somehow managed. as a sidenote, it would be nice to have more examples of there being zero upsides to CLAs |
They do have a long tail that is pending though: |
well, it's not trivial, but it seems worth a try I'm not sure if they already excluded things like single letter spelling fixes which are arguably not subject to copyright or if they're going to resort to that once there is nothing else left |
Agreed, no objections to that.
Yes, but Zephyr has a bit of a bigger problem, doesn't it? I imagine that LLVM can be built into multiple separate executables and/or dynamic libraries, but Zephyr is always linked together monolithically, which means that we need to get most if not all to sign in order for this to work. |
well, since with Zephyr you would typically want to have a lean image, not linking in things you don't need (since it's meant to run in quite resource limited environments), I'd imagine there would be a lot of platform drivers that won't ever be relevant to a new platform which would benefit from ported code |
Yes, that is true. It would all boil down to tracking enough contributors down to be able to relicense the main common parts, like the kernel. This will likely be discussed in the next TSC meeting if you're interested in joining. |
I'll put it in a calendar so I at least don't forget about it, but we'll see |
outdated, closing. Please open new issue with updated information if this is still needed. |
Introduction
There is a disagreement between the Free Software Foundation and
the Apache foundation about whether the Apache 2.0 license is compatible
with GPLv2.
The LLVM project, which was interested in adopting the Apache 2.0 license,
worked with their lawyers to craft an exception which resolves this issue.
Problem description
As a Linux Foundation backed project and according to some sources
the currently most popular RTOS, Zephyr seems to be a clear first choice
for many.
The use of Linux concepts invites trying to share driver code in cases where
the copyleft nature of GPLv2 is not seen as a problem. Having to write (sometimes
complex) drivers from scratch just because of a licensing incompatibility seems
absurd, especially when Apache themselves claim they don't see any incompatibility.
LLVM has shown that it's clearly possible to add an exception which is void
in case Apache is correct and there is indeed no incompatibility, and doing so
seems like a no-brainer, unless (uncertainty about) incompatibility with GPLv2
is explicitly desired (which seems impossible for a Linux Foundation backed project)
Proposed change
Follow in LLVM's footsteps (https://foundation.llvm.org/docs/relicensing/),
adding just the GPLv2 compatibility disambiguation exception.
Detailed RFC
add the following (resp. copy it from LLVM's license file directly):
to the License, and make an effort to gather an agreement from all developers
with this change.
Dependencies
gathering agreements from all developers
Concerns and Unresolved Questions
it may be easy to excuse not doing this by saying it's a considerable amount of work,
even if the real reason is that incompatibility with GPLv2 is undesirable.
Alternatives
using a different RTOS (lots of duplicate work just because of a license incompatibility that the Apache foundation feels doesn't exist)
writing drivers from scratch when they could be reused (lots of duplicate work just because of a license incompatibility that the Apache foundation feels doesn't exist)
violating the license and hoping nobody notices (this was indeed suggested as an alternative to me, I don't think it needs to be explained here why that's a ridiculous idea)
using Linux as an RTOS (clearly anyone contributing to this project doesn't see that as viable for most usecases)
The text was updated successfully, but these errors were encountered: