[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-community
Subject: Re: Does KDE have a policy for shipping libraries licensed under the Apache license?
From: Albert Vaca Cintora <albertvaka () gmail ! com>
Date: 2022-12-23 11:44:45
Message-ID: CAAQViEveV=wEqxTBbZZOxDze6atU9PdhENeAygCeqtEhrUpC+w () mail ! gmail ! com
[Download RAW message or body]
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@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=C3=A1s 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 derive=
d
> works may be distributed on the Apple store. IIRC (though it's not writte=
n
> 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@kde.org>
> wrote:
>>
>> On Dienstag, 20. Dezember 2022 05:41:11 CET Nicol=C3=A1s 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 an=
d
>>> 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 licen=
se,
>>> 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 wo=
uld
>>> 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, an=
d
>>> 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 yo=
ur
>>> 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.ht=
ml
>>>
>>
>> That matches my understanding as well, and with OpenSSL moving to Apache=
2
>> this is something eventually affecting the distribution of large parts o=
f our
>> work, not just KDE Connect.
>>
>> The licensing policy doesn't allow GPL-2.0-only code anymore for that re=
ason
>> (compatibility with Apache 2), which is as close as we get to an existin=
g
>> policy on the original question I think.
>>
>> Note that the GPLv3 has the famous "anti-tivoization" clause (not presen=
t in
>>> GPLv2) which requires, in some cases, distributing signing keys that le=
t
>>> 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 t=
o
>>> App Stores. It only applies when the software is shipped with a hardwar=
e
>>> 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 a=
pps
>>> 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 run=
ning
>> 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 be=
ing
>> signed as well.
>>
>> Regards,
>> Volker
>>
>> Also, while you may want to say somewhere "KDE Connect for iOS is licens=
ed
>>> under the GPLv3", the individual source code files (at least those not
>>> directly interacting with this library) can keep saying GPLv2/v3/eV. Th=
at
>>> would let us copy code into other KDE projects without having to ask pe=
ople
>>> for relicensing just to add v2 again.
>>>
>>>> El 20 dic. 2022, a la(s) 00:47, Simon Redman <simon@ergotech.com>
>>>> escribi=C3=B3:
>>>> =EF=BB=BF 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 relicenc=
e
>>>> 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, a=
nd
>>>> 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 =C5=A0tikonas" <stikonas=
@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 un=
der
>>>>>
>>>>> GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
>>>>> I.e. you are essentially dropping GPLv2 support and only keeping GPLv=
3.
>>>>> So you must first check that you have no GPLv2 only dependencies.
>>>>>
>>>>> Kind regards,
>>>>> Andrius
>>>>>
>>>>> 2022 m. gruod=C5=BEio 19 d., pirmadienis 23:34:11 CET Simon Redman ra=
=C5=A1=C4=97:
>>>>>
>>>>>> 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/1=
92
>>>>>>
>>>>>> 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. Th=
e
>>>>>> .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 no=
t
>>>>>> qualified to expose KDE to any additional risk, is there a policy (o=
r
>>>>>> accepted precedent) for distributing Apache-licensed libraries?
>>>>>>
>>>>>> Thanks,
>>>>>> Simon
>>>>>>
>>>>>
[Attachment #3 (text/html)]
<div dir="ltr">I've opened a PR to change the license listed in F-Droid: <a \
href="https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12310">https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12310</a><div><br></div><div>If \
I understand correctly, this only affects the license of the APK but the code \
continues to be GPL2?</div></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, Dec 22, 2022 at 2:32 PM Simon Redman <<a \
href="mailto:simon@ergotech.com">simon@ergotech.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Thanks everyone \
for your thoughts and comments.<br><br>It sounds like this would be a "nice to \
have" an official policy on, so that we developer can have something to point \
to.<br><br>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.<br><br>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.<br><br>Thanks,<br>Simon<br><br><br><div class="gmail_quote">On December 20, \
2022 8:21:24 AM EST, Volker Krause <<a href="mailto:vkrause@kde.org" \
target="_blank">vkrause@kde.org</a>> wrote:<blockquote class="gmail_quote" \
style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <pre dir="auto">On Dienstag, 20. Dezember 2022 \
05:41:11 CET Nicolás Alvarez wrote:<br><blockquote class="gmail_quote" \
style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid \
rgb(114,159,207);padding-left:1ex">(This is "as I understand it", not legal \
advice, I am not a lawyer, etc etc)<br><br>The system library clause is, for example, \
what lets KDE Connect (under the<br>GPL) link to the iOS system frameworks (under a \
proprietary license).<br><br>System libraries have nothing to do with the Apache \
situation. GPLv2 and<br>Apachev2 are incompatible due to the details of the patent \
termination<br>terms, while GPLv3 and Apachev2 are compatible, with no need to invoke \
the<br>system library clause. See<br><a \
href="https://www.apache.org/licenses/GPL-compatibility.html" \
target="_blank">https://www.apache.org/licenses/GPL-compatibility.html</a><br><br>A \
project under the GPLv3 can incorporate files under the Apache2 license,<br>and the \
combined work, like the compiled binary, will be considered to be<br>under the GPLv3. \
You have to be very careful during development to not copy<br>code from the GPLv3 \
files to the Apache2 files (the copyright holder would<br>need to explicitly consent \
to relicensing that code to Apache2) or<br>viceversa (copying Apache2 code into GPLv3 \
files would need to preserve the<br>original copyright/license/warranty \
notices).<br><br>A project under the GPLv3 can also link to a library under Apachev2, \
and<br>then things are even easier since you don't have to worry about pieces \
of<br>code getting copied between files (the library source code is not in \
your<br>project and you won't be modifying it).<br><br>I found more info here \
(especially about the complications in the<br>non-library case):<br><a \
href="https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html" \
target="_blank">https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html</a><br></blockquote><br>That \
matches my understanding as well, and with OpenSSL moving to Apache 2 <br>this is \
something eventually affecting the distribution of large parts of our <br>work, not \
just KDE Connect. <br><br>The licensing policy doesn't allow GPL-2.0-only code \
anymore for that reason <br>(compatibility with Apache 2), which is as close as we \
get to an existing <br>policy on the original question I think.<br><br><blockquote \
class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid \
rgb(114,159,207);padding-left:1ex">Note that the GPLv3 has the famous \
"anti-tivoization" clause (not present in<br>GPLv2) which requires, in some \
cases, distributing signing keys that let<br>you run the modified software, and this \
seems like it would clash with the<br>App Store. However, it is my understanding that \
this does *not* apply to<br>App Stores. It only applies when the software is shipped \
with a hardware<br>device and distributed along with the sale of the device. (The \
messy<br>wording in the GPLv3 is to avoid "but we're not really *selling* \
it"<br>loopholes). Apple can't put GPLv3 code in iOS itself, but third party \
apps<br>should be fine.<br></blockquote><br>I don't think that applies here, as \
signing is not meant to prevent you from <br>running modified versions of our code, \
it merely proves that you are running <br>our binaries. You can build (and sign) your \
own APK and run that without <br>limitations, this isn't any different from e.g. \
Linux distro packages being <br>signed as \
well.<br><br>Regards,<br>Volker<br><br><blockquote class="gmail_quote" \
style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid \
rgb(114,159,207);padding-left:1ex">Also, while you may want to say somewhere \
"KDE Connect for iOS is licensed<br>under the GPLv3", the individual source \
code files (at least those not<br>directly interacting with this library) can keep \
saying GPLv2/v3/eV. That<br>would let us copy code into other KDE projects without \
having to ask people<br>for relicensing just to add v2 again.<br><blockquote \
class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid \
rgb(173,127,168);padding-left:1ex">El 20 dic. 2022, a la(s) 00:47, Simon Redman \
<<a href="mailto:simon@ergotech.com" \
target="_blank">simon@ergotech.com</a>><br>escribió:<br> Hi \
Andrius,<br><br>Thanks for your input.<br><br>That is the textbook answer, but \
doesn't actually fit this case. GPLv3 is<br>only compatible with Apache because \
it has an exclusion for system<br>libraries, but KDE Connect is an Android app so \
there is no concept of<br>system libraries.<br><br>It doesn't get to the core of \
the issue: What is KDE's position?<br><br>To take another angle:<br>If I assume \
the whole package falls under the "entire work", and if I<br>package Apache \
v2 and my own GPL v2 code together, and distribute it, I'd<br>have broken the \
GPLv2 license of my own code because I cannot relicence<br>the Apache parts of the \
"whole work", but I'm not going to sue myself so<br>there is no legal \
issue.<br><br>The simple example gets complicated when it's a global \
organization, and<br>not just my code but the code of other contributors as well. But \
that's<br>why I'm asking if there's a defined \
policy.<br><br>Thanks,<br>Simon<br><br>On December 19, 2022 5:54:38 PM EST, \
"Andrius Å tikonas" <<a href="mailto:stikonas@kde.org" \
target="_blank">stikonas@kde.org</a>> \
<br></blockquote></blockquote>wrote:<br><blockquote class="gmail_quote" \
style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid \
rgb(114,159,207);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0pt \
0pt 1ex 0.8ex;border-left:1px solid rgb(173,127,168);padding-left:1ex"><blockquote \
class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid \
rgb(138,226,52);padding-left:1ex">Hi,<br><br>Quick check seems to indicate that KDE \
Connect license is:<br><br>GPL-2.0-only OR GPL-3.0-only OR \
LicenseRef-KDE-Accepted-GPL<br>Apache v2 licensed code is not compatible with \
GPL-2.0-only but<br>is compatible with GPLv3. So by combining KDE Conenct \
with<br>that library you lose right to redistribute the whole thing<br>as GPL2 but \
you still have the right to redistribute combined code under<br><br>GPL-3.0-only OR \
LicenseRef-KDE-Accepted-GPL<br>I.e. you are essentially dropping GPLv2 support and \
only keeping GPLv3.<br>So you must first check that you have no GPLv2 only \
dependencies.<br><br>Kind regards,<br>Andrius<br><br>2022 m. gruodžio 19 d., \
pirmadienis 23:34:11 CET Simon Redman rašė:<br><blockquote class="gmail_quote" \
style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid \
rgb(252,175,62);padding-left:1ex">KDE Connect has had this PR languishing for a \
couple of years, with a<br>question I am not able to answer.<br><a \
href="https://invent.kde.org/network/kdeconnect-android/-/merge_requests/192" \
target="_blank">https://invent.kde.org/network/kdeconnect-android/-/merge_requests/192</a><br><br>The \
author has added a (very useful) library, which happens to be<br>licensed under the \
Apache v2 license.<br><br>KDE Connect code is GPL-licensed. GPL section 2 says that \
the entire<br>work must be distributed as GPL.<br><a \
href="https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html" \
target="_blank">https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html</a><br><br>In \
my eyes, the only meaningful part of the work is the source code, at<br>which level \
the concept of distributing a library does not apply. The<br>.apk that we give to \
users is just a convenience to them, they could<br>just as well build it themselves. \
The .apk contains both the KDE<br>Connect<br>GPL code and the Apache-licensed \
libraries, but by itself has no<br>specific license (and doesn't claim \
to).<br><br>But my view don't matter, what matters is what happens in court, in \
the<br>event anyone ever accuses KDE of violating license terms. As I am \
not<br>qualified to expose KDE to any additional risk, is there a policy \
(or<br>accepted precedent) for distributing Apache-licensed \
libraries?<br><br>Thanks,<br>Simon<br></blockquote></blockquote></blockquote></blockquote></pre></blockquote></div></div></blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic