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

[Albert Vaca Cintora]

I've opened a PR to change the license listed in F-Droid:
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12310

If I understand correctly, this only affects the license of the APK but the
code continues to be GPL2?

On Thu, Dec 22, 2022 at 2:32 PM Simon Redman <simon at ergotech.com> wrote:

> Thanks everyone for your thoughts and comments.
>
> It sounds like this would be a "nice to have" an official policy on, so
> that we developer can have something to point to.
>
> That said, for my situation it sounds like it's safe to move ahead with
> the Apache v2 library. We simply need to declare that the .apk is
> distributed as GPLv3 only.
>
> Since Nicolás touched on it, I'll mention that the iOS app is an
> interesting case. Apple does not allow GPL apps on their store, so the
> kdeconnect-ios code has a special call-out to the GPL license that derived
> works may be distributed on the Apple store. IIRC (though it's not written
> down, so maybe I do not recall correctly), kdeconnect-ios is released to
> the App Store under a non-GPL license.
>
> Thanks,
> Simon
>
>
> On December 20, 2022 8:21:24 AM EST, Volker Krause <vkrause at kde.org>
> wrote:
>>
>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20221223/39889ade/attachment-0001.htm>