Add (part of) the LLVM Exception to the License

[Mis012]

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):

As an exception, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 (“Combined Software”) and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software.

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)

[nordicjm]

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?

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

   a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

   b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

   c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

[Mis012]

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

[nordicjm]

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?

[Mis012]

right now, any third party can't use zephyr together with GPLv2 code whether the GPLv2 code would be hosted in-tree or out-of-tree, there is an ambiguity as to whether GPLv2 code and Apache 2.0 code can be linked together, and nobody wants to find out in court

[carlescufi]

@Mis012 thanks for the proposal. I've pinged @kestewart and @nashif internally and this will be discussed in the TSC.

[stephanosio]

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.

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).

[Mis012]

well, the LLVM project is arguably even larger, and they somehow managed. 2,854 contributors to date according to github, and I assume with git it should be quite accurate

as a sidenote, it would be nice to have more examples of there being zero upsides to CLAs

[carlescufi]

well, the LLVM project is arguably even larger, and they somehow managed. 2,854 contributors to date according to github, and I assume with git it should be quite accurate

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: https://docs.google.com/spreadsheets/d/18_0Hog_eSwES8lKwf7WJal3yBwwcYfvPu1yCfZnTcek/edit#gid=522707592

[Mis012]

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

[carlescufi]

well, it's not trivial, but it seems worth a try

Agreed, no objections to that.

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

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.

[Mis012]

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

[carlescufi]

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.

[Mis012]

I'll put it in a calendar so I at least don't forget about it, but we'll see

[nashif]

outdated, closing. Please open new issue with updated information if this is still needed.