[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 \
://softwarefreedom.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