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

[Nicolás Alvarez]

(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

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.

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.

-- 
Nicolas
I'm not a FOSS lawyer, I just play as one on the Internet sometimes

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20221220/d2669584/attachment-0001.htm>