12:45 p.m.
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-...
4. http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html
5. http://www.apache.org/licenses/LICENSE-2.0