On 11/10/2017 06:33 AM, Zdenek Dohnal wrote:

I'm interested in this issue too as Fedora/RHEL maintainer of printing packages. Legal guys, would you mind helping us with this?

Please keep in mind that IANAL, this should not be considered Legal Advise.

= License compatibility is fun. Hold on to your butts. =

CUPS is moving to Apache 2.0. The FSF believes that the combination of Apache 2.0 and GPL version 2 are incompatible, because Apache 2.0 contains "certain patent termination and indemnification provisions" [1]. The FSF also defines "compatible with the GPL" as the ability to combine code released under the other license with code released under the GNU GPL in one larger program [2].

The FSF thinks that the Apache 2.0 patent provisions are a "good thing", and worked to ensure that GPL version 3 was compatible with them.

Thus, pretty much everyone is in agreement that GPLv3 + Apache 2.0 is a fine combination. If the combination is GPLv2 or later, then you can resolve any concerns about compatibility between GPLv2 and Apache 2.0 by using the GPLv3 license in situations where that work is combined with an Apache 2.0 work.

My understanding is that the bulk of the CUPS ecosystem (if not all of it is GPLv2+ or GPLv3).

As far as LGPL compatibility goes, because the LGPL provides permission for anyone to use the LGPL work under the terms of the GPL (section 3 of the LGPLv2 and section 2.b of the LGPLv3). LGPLv2 permits the terms of GPLv2 or GPLv3 (or any future version of GPL) to be applied in place of the LGPLv2 terms. LGPLv3 permits the terms of GPLv3 to be applied in place of the LGPLv3 terms.

Thus, LGPLv2 + Apache 2.0 _and_ LGPLv3 + Apache 2.0 are considered compatible.

(I am intentionally dodging the question of whether LGPLv2/v3 is compatible without triggering the GPL conversion clause, as there is very little material published on this topic.)

So, that leaves us with GPL version 2 (only) and Apache 2.0. In this scenario, it is worth noting a few things:

A. The intent of the upstream copyright holders matters when determining compatibility. If both upstreams believe their licensing to be compatible, and document this, it will have an impact on the practical compatibility of combining the works. It is not clear to me how Apple feels about the compatibility of Apache 2.0 and GPLv2 only.

It is worth noting that there is a drafted exception for the Apache 2.0 license to resolve the GPLv2 compatibility concern [3]:

—- Exceptions to the Apache 2.0 License: —-

In addition, 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.

This is also what LLVM does [4]. I do not know if anyone has asked Apple if they would apply this exception text to CUPS or not.

*****

B. Linking is different from combining. It may be a semantic difference, but the architecture which permits the separation of code via shared libraries creates a sort of gray area when it comes to license compatibility. The FSF feels strongly that code which links to libraries needs to be under compatible licenses, but others do not feel this to be the case. In the case of the Apache 2.0 license, this separation is described, where a combined work (code is copied from Project A into Apache 2.0 project B) is called a "Derivative Work". Apache 2.0 says, when defining the term "Derivative Work" [5]:

For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

So, as far as the authors of the Apache 2.0 license are concerned, a GPLv2 Project A linked to an Apache 2.0 Project B do not result in a Derivative Work.

This is all a nice way of saying that the Apache authors do not believe that the Apache 2.0 terms apply to anything that merely links to an Apache 2.0 component. Given that this belief is incorporated in the Apache 2.0 license text, it is reasonably safe to assume (in my humble opinion) that by choosing the Apache 2.0 license without modifications to apply to CUPS, Apple also believes this to be true.

*****

C. As a general rule in Fedora, we do not believe that linking results in a combined or Derivative Work, since it is possible to easily separate these items out (and even to replace them with code that uses the same API but different licensing, see NVIDIA/Mesa). Fedora's use of packaging (RPM) and shared libraries (.so files) permits a logical and clear separation of works, so that it is easy to see that Apache 2.0 applies to Library A and that GPL 2.0 applies only to Program B.

(Static linking blurs this, which is one of the reasons we discourage it in Fedora.)

*****

In conclusion:

AA. Fedora is not (at this time) concerned about license compatibility issues arising from the relicensing of CUPS to Apache 2.0, in as much as this applies to linking of components together (our use case).

BB. If you are planning on (or have) copying code from CUPS and including it in a GPLv2 only licensed work, seek legal counsel, that is a more complicated scenario that Fedora does not face right now (as far as I know).

Hope that helps,

~tom

1. https://www.gnu.org/licenses/license-list.html#apache2 2. https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean 3. https://blog.gerv.net/2016/09/gplv2-combination-exception-for-the-apache-2-l... 4. http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html 5. http://www.apache.org/licenses/LICENSE-2.0