--Apple-Mail-DB670D35-4893-4E9A-A41C-8D168E24655E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =EF=BB=BFOops, I somehow misunderstood the question as being about iOS but i= t'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=C3=A1s Alvarez escribi=C3=B3: > =EF=BB=BF > (This is "as I understand it", not legal advice, I am not a lawyer, etc et= c) >=20 > The system library clause is, for example, what lets KDE Connect (under th= e GPL) link to the iOS system frameworks (under a proprietary license). >=20 > System libraries have nothing to do with the Apache situation. GPLv2 and A= pachev2 are incompatible due to the details of the patent termination terms,= while GPLv3 and Apachev2 are compatible, with no need to invoke the system l= ibrary clause. See https://www.apache.org/licenses/GPL-compatibility.html >=20 > 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 u= nder the GPLv3. You have to be very careful during development to not copy c= ode from the GPLv3 files to the Apache2 files (the copyright holder would ne= ed to explicitly consent to relicensing that code to Apache2) or viceversa (= copying Apache2 code into GPLv3 files would need to preserve the original co= pyright/license/warranty notices). >=20 > A project under the GPLv3 can also link to a library under Apachev2, and t= hen things are even easier since you don't have to worry about pieces of cod= e getting copied between files (the library source code is not in your proje= ct and you won't be modifying it). >=20 > I found more info here (especially about the complications in the non-libr= ary case): > https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html >=20 > Note that the GPLv3 has the famous "anti-tivoization" clause (not present i= n GPLv2) which requires, in some cases, distributing signing keys that let y= ou run the modified software, and this seems like it would clash with the Ap= p Store. However, it is my understanding that this does *not* apply to App S= tores. It only applies when the software is shipped with a hardware device a= nd distributed along with the sale of the device. (The messy wording in the G= PLv3 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. >=20 > 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 dire= ctly interacting with this library) can keep saying GPLv2/v3/eV. That would l= et us copy code into other KDE projects without having to ask people for rel= icensing just to add v2 again. >=20 > --=20 > Nicolas > I'm not a FOSS lawyer, I just play as one on the Internet sometimes >=20 >> El 20 dic. 2022, a la(s) 00:47, Simon Redman escribi= =C3=B3: >> =EF=BB=BF Hi Andrius, >>=20 >> Thanks for your input. >>=20 >> 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 librarie= s, but KDE Connect is an Android app so there is no concept of system librar= ies. >>=20 >> It doesn't get to the core of the issue: What is KDE's position? >>=20 >> To take another angle: >> If I assume the whole package falls under the "entire work", and if I pac= kage Apache v2 and my own GPL v2 code together, and distribute it, I'd have b= roken 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 l= egal issue. >>=20 >> The simple example gets complicated when it's a global organization, and n= ot just my code but the code of other contributors as well. But that's why I= 'm asking if there's a defined policy. >>=20 >> Thanks, >> Simon >>=20 >>=20 >> On December 19, 2022 5:54:38 PM EST, "Andrius =C5=A0tikonas" wrote: >>>=20 >>> Hi, >>>=20 >>> Quick check seems to indicate that KDE Connect license is: >>>=20 >>> 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= >>>=20 >>> 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. >>>=20 >>> Kind regards, >>> Andrius >>>=20 >>> 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/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, a= t >>> > 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 Conne= ct >>> > 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 th= e >>> > 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 >>> > --Apple-Mail-DB670D35-4893-4E9A-A41C-8D168E24655E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=EF=BB=BFOops, I somehow misund= erstood the question as being about iOS but it's actually Android. Do you wo= rk on both? Your name may be what confused me.

My reply s= hould still be applicable anyway, other than the specific examples and refer= ences to Apple :)

El 20 dic. 2022, a la(s) 01:41, Nicol=C3=A1s Alvarez <nicolas.alvarez= @gmail.com> escribi=C3=B3:

=EF=BB=BF
(This is "as I understand it= ", not legal advice, I am not a lawyer, etc etc)

The system library c= lause is, for example, what lets KDE Connect (under the GPL) link to the iOS= system frameworks (under a proprietary license).

System libraries have not= hing to do with the Apache situation. GPLv2 and Apachev2 are incompatible du= e to the details of the patent termination terms, while GPLv3 and Apachev2 a= re 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, a= nd the combined work, like the compiled binary, will be considered to be und= er the GPLv3. You have to be very careful during development to not copy cod= e from the GPLv3 files to the Apache2 files (the copyright holder would need= to explicitly consent to relicensing that code to Apache2) or viceversa (co= pying Apache2 code into GPLv3 files would need to preserve the original copy= right/license/warranty notices).

A project under th= e GPLv3 can also link to a library under Apachev2, and then things are even e= asier since you don't have to worry about pieces of code getting copied betw= een files (the library source code is not in your project and you won't be m= odifying it).

I found more info here (especially ab= out the complications in the non-library case):
<= div>
Note that the GPLv3 has the famous "anti-tivoization" cla= use (not present in GPLv2) which requires, in some cases, distributing signi= ng 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 *n= ot* 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 mes= sy wording in the GPLv3 is to avoid "but we're not really *selling* it" loop= holes). Apple can't put GPLv3 code in iOS itself, but third party apps shoul= d be fine.

Also, while you may want to say somewher= e "KDE Connect for iOS is licensed under the GPLv3", the individual source c= ode files (at least those not directly interacting with this library) can ke= ep saying GPLv2/v3/eV. That would let us copy code into other KDE projects w= ithout 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

<= blockquote type=3D"cite">El 20 dic. 2022, a la(s) 00:47, Simon Redman <si= mon@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 b= ecause it has an exclusion for system libraries, but KDE Connect is an Andro= id app so there is no concept of system libraries.

It doesn't get to t= he core of the issue: What is KDE's position?

To take another angle:<= br>If I assume the whole package falls under the "entire work", and if I pac= kage Apache v2 and my own GPL v2 code together, and distribute it, I'd have b= roken 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 l= egal issue.

The simple example gets complicated when it's a global or= ganization, 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,
Si= mon


On December 19, 2022 5:54:38 PM ES= T, "Andrius =C5=A0tikonas" <stikonas@kde.org> wrote:

Hi,<= /p>

= Quick check seems to indicate that KDE Connect license is:


= GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Ac= cepted-GPL

Apac= he v2 licensed code is not compatible with GPL-2.0-only but

is c= ompatible with GPLv3. So by combining KDE Conenct with

that= library you lose right to redistribute the whole thing

as G= PL2 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 y= ou must first check that you have no GPLv2 only dependencies.


= Kind regards,

Andr= ius


= 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/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

>=



= --Apple-Mail-DB670D35-4893-4E9A-A41C-8D168E24655E--