[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: Nicolás_Alvarez <nicolas.alvarez () gmail ! com>
Date: 2022-12-20 4:46:08
Message-ID: 5FDA10CF-EC77-48AD-9A8A-4DF36E2DBCBA () gmail ! com
[Download RAW message or body]
Oops, I somehow misunderstood the question as being about iOS but it's actually Android. Do \
you work on both? Your name may be what confused me.
My reply should still be applicable anyway, other than the specific examples and references to \
Apple :)
> El 20 dic. 2022, a la(s) 01:41, Nicolás Alvarez <nicolas.alvarez@gmail.com> escribió:
> 
> (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@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@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
> > > >
[Attachment #3 (text/html)]
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body \
dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; \
charset=utf-8">Oops, I somehow misunderstood the question as being about iOS but it's actually \
Android. Do you work on both? Your name may be what confused me.<div><br></div><div>My reply \
should still be applicable anyway, other than the specific examples and references to Apple \
:)<div><br></div><div><div dir="ltr"><blockquote type="cite">El 20 dic. 2022, a la(s) 01:41, \
Nicolás Alvarez <nicolas.alvarez@gmail.com> \
escribió:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta \
http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"><meta \
http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"><span \
style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">(This is "as I understand it", not \
legal advice, I am not a lawyer, etc etc)</span><div><span style="caret-color: rgb(0, 0, 0); \
color: rgb(0, 0, 0);"><br></span></div><div><span style="caret-color: rgb(0, 0, 0); color: \
rgb(0, 0, 0);">The system library clause is, for example, what lets KDE Connect (under the GPL) \
link to the iOS system frameworks (under a proprietary license).</span><br style="caret-color: \
rgb(0, 0, 0); color: rgb(0, 0, 0);"><br><div>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 <a \
href="https://www.apache.org/licenses/GPL-compatibility.html">https://www.apache.org/licenses/GPL-compatibility.html</a><div><div><br></div><div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>I found more info here \
(especially about the complications in the non-library case):</div><div><a \
href="https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html">https://softwar \
efreedom.org/resources/2007/gpl-non-gpl-collaboration.html</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-- </div><div>Nicolas</div><div>I'm not a FOSS lawyer, \
I just play as one on the Internet sometimes</div><div><br><div dir="ltr"><blockquote \
type="cite">El 20 dic. 2022, a la(s) 00:47, Simon Redman <simon@ergotech.com> \
escribió:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Hi Andrius,<br><br>Thanks for your input.<br><br>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.<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 \
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.<br><br>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.<br><br>Thanks,<br>Simon<br><br><br><div class="gmail_quote">On December 19, 2022 \
5:54:38 PM EST, "Andrius Å tikonas" <stikonas@kde.org> wrote:<blockquote \
class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, \
204); padding-left: 1ex;"> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Hi,</p> <br><p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Quick check seems to \
indicate that KDE Connect license is:</p> <br><p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><span \
style="background-color:#ffffff;"><span style="color:#ff5454;"><strong><span \
style="font-family:monospace;">GPL-2.0-only</span></strong></span><span \
style="color:#000000;"> OR GPL-3.0-only OR \
LicenseRef-KDE-Accepted-GPL</span></span><br></p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Apache v2 licensed code is \
not compatible with GPL-2.0-only but</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">is compatible with GPLv3. So \
by combining KDE Conenct with</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">that library you lose right \
to redistribute the whole thing</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">as GPL2 but you still have \
the right to redistribute combined code under</p> <br><p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><span \
style="color:#000000;"><span style="background-color:#ffffff;">GPL-3.0-only OR \
LicenseRef-KDE-Accepted-GPL</span></span><br></p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">I.e. you are essentially \
dropping GPLv2 support and only keeping GPLv3.</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">So you must first check that \
you have no GPLv2 only dependencies.</p> <br><p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Kind regards,</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Andrius</p> <br><p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">2022 m. gruodžio 19 d., \
pirmadienis 23:34:11 CET Simon Redman rašė:</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> KDE Connect has had \
this PR languishing for a couple of years, with a </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> question I am not able \
to answer.</p> <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> \
https://invent.kde.org/network/kdeconnect-android/-/merge_requests/192</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> The author has added a \
(very useful) library, which happens to be </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> licensed under the \
Apache v2 license.</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> KDE Connect code is \
GPL-licensed. GPL section 2 says that the entire </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> work must be \
distributed as GPL. </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> \
https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> In my eyes, the only \
meaningful part of the work is the source code, at </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> which level the concept \
of distributing a library does not apply. The </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> .apk that we give to \
users is just a convenience to them, they could </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> just as well build it \
themselves. The .apk contains both the KDE Connect </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> GPL code and the \
Apache-licensed libraries, but by itself has no </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> specific license (and \
doesn't claim to).</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> But my view don't \
matter, what matters is what happens in court, in the </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> event anyone ever \
accuses KDE of violating license terms. As I am not </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> qualified to expose KDE \
to any additional risk, is there a policy (or </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> accepted precedent) for \
distributing Apache-licensed libraries?</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> </p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> Thanks,</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> Simon</p> <p \
style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">> </p> \
<br><br></blockquote></div> \
</div></blockquote></div></div></div></div></div></div></div></div></blockquote></div></div></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic