Does KDE have a policy for shipping libraries licensed under the Apache license?

Tue Dec 20 13:21:24 GMT 2022

On Dienstag, 20. Dezember 2022 05:41:11 CET Nicolás Alvarez wrote:
> (This is "as I understand it", not legal advice, I am not a lawyer, etc etc)
> 
> The system library clause is, for example, what lets KDE Connect (under the
> GPL) link to the iOS system frameworks (under a proprietary license).
> 
> System libraries have nothing to do with the Apache situation. GPLv2 and
> Apachev2 are incompatible due to the details of the patent termination
> terms, while GPLv3 and Apachev2 are compatible, with no need to invoke the
> system library clause. See
> https://www.apache.org/licenses/GPL-compatibility.html
> 
> A project under the GPLv3 can incorporate files under the Apache2 license,
> and the combined work, like the compiled binary, will be considered to be
> under the GPLv3. You have to be very careful during development to not copy
> code from the GPLv3 files to the Apache2 files (the copyright holder would
> need to explicitly consent to relicensing that code to Apache2) or
> viceversa (copying Apache2 code into GPLv3 files would need to preserve the
> original copyright/license/warranty notices).
> 
> A project under the GPLv3 can also link to a library under Apachev2, and
> then things are even easier since you don't have to worry about pieces of
> code getting copied between files (the library source code is not in your
> project and you won't be modifying it).
> 
> I found more info here (especially about the complications in the
> non-library case):
> https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

That matches my understanding as well, and with OpenSSL moving to Apache 2 
this is something eventually affecting the distribution of large parts of our 
work, not just KDE Connect. 

The licensing policy doesn't allow GPL-2.0-only code anymore for that reason 
(compatibility with Apache 2), which is as close as we get to an existing 
policy on the original question I think.

> Note that the GPLv3 has the famous "anti-tivoization" clause (not present in
> GPLv2) which requires, in some cases, distributing signing keys that let
> you run the modified software, and this seems like it would clash with the
> App Store. However, it is my understanding that this does *not* apply to
> App Stores. It only applies when the software is shipped with a hardware
> device and distributed along with the sale of the device. (The messy
> wording in the GPLv3 is to avoid "but we're not really *selling* it"
> loopholes). Apple can't put GPLv3 code in iOS itself, but third party apps
> should be fine.

I don't think that applies here, as signing is not meant to prevent you from 
running modified versions of our code, it merely proves that you are running 
our binaries. You can build (and sign) your own APK and run that without 
limitations, this isn't any different from e.g. Linux distro packages being 
signed as well.

Regards,
Volker

> Also, while you may want to say somewhere "KDE Connect for iOS is licensed
> under the GPLv3", the individual source code files (at least those not
> directly interacting with this library) can keep saying GPLv2/v3/eV. That
> would let us copy code into other KDE projects without having to ask people
> for relicensing just to add v2 again.
> > El 20 dic. 2022, a la(s) 00:47, Simon Redman <simon at ergotech.com>
> > escribió:
> >  Hi Andrius,
> > 
> > Thanks for your input.
> > 
> > That is the textbook answer, but doesn't actually fit this case. GPLv3 is
> > only compatible with Apache because it has an exclusion for system
> > libraries, but KDE Connect is an Android app so there is no concept of
> > system libraries.
> > 
> > It doesn't get to the core of the issue: What is KDE's position?
> > 
> > To take another angle:
> > If I assume the whole package falls under the "entire work", and if I
> > package Apache v2 and my own GPL v2 code together, and distribute it, I'd
> > have broken the GPLv2 license of my own code because I cannot relicence
> > the Apache parts of the "whole work", but I'm not going to sue myself so
> > there is no legal issue.
> > 
> > The simple example gets complicated when it's a global organization, and
> > not just my code but the code of other contributors as well. But that's
> > why I'm asking if there's a defined policy.
> > 
> > Thanks,
> > Simon
> > 
> > On December 19, 2022 5:54:38 PM EST, "Andrius Štikonas" <stikonas at kde.org> 
wrote:
> >> Hi,
> >> 
> >> Quick check seems to indicate that KDE Connect license is:
> >> 
> >> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> >> Apache v2 licensed code is not compatible with GPL-2.0-only but
> >> is compatible with GPLv3. So by combining KDE Conenct with
> >> that library you lose right to redistribute the whole thing
> >> as GPL2 but you still have the right to redistribute combined code under
> >> 
> >> GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> >> I.e. you are essentially dropping GPLv2 support and only keeping GPLv3.
> >> So you must first check that you have no GPLv2 only dependencies.
> >> 
> >> Kind regards,
> >> Andrius
> >> 
> >> 2022 m. gruodžio 19 d., pirmadienis 23:34:11 CET Simon Redman rašė:
> >> > KDE Connect has had this PR languishing for a couple of years, with a
> >> > question I am not able to answer.
> >> > https://invent.kde.org/network/kdeconnect-android/-/merge_requests/192
> >> > 
> >> > The author has added a (very useful) library, which happens to be
> >> > licensed under the Apache v2 license.
> >> > 
> >> > KDE Connect code is GPL-licensed. GPL section 2 says that the entire
> >> > work must be distributed as GPL.
> >> > https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
> >> > 
> >> > In my eyes, the only meaningful part of the work is the source code, at
> >> > which level the concept of distributing a library does not apply. The
> >> > .apk that we give to users is just a convenience to them, they could
> >> > just as well build it themselves. The .apk contains both the KDE
> >> > Connect
> >> > GPL code and the Apache-licensed libraries, but by itself has no
> >> > specific license (and doesn't claim to).
> >> > 
> >> > But my view don't matter, what matters is what happens in court, in the
> >> > event anyone ever accuses KDE of violating license terms. As I am not
> >> > qualified to expose KDE to any additional risk, is there a policy (or
> >> > accepted precedent) for distributing Apache-licensed libraries?
> >> > 
> >> > Thanks,
> >> > Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20221220/e29ca3e4/attachment.sig>