Re: Does KDE have a policy for shipping libraries licensed under the Apache license?
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 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 > 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 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
Re: Does KDE have a policy for shipping libraries licensed under the Apache license?
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 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 >> > 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
Re: Does KDE have a policy for shipping libraries licensed under the Apache license?
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 > > 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" 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. > >> > >>
Re: Does KDE have a policy for shipping libraries licensed under the Apache license?
On Montag, 19. Dezember 2022 23:34:11 CET Simon Redman wrote: > 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? I'm not aware of an official policy for shipping libraries licensed under the Apache license as part of build artifacts published by KDE. Traditionally, we only published source code where this question didn't arise. The KDE licensing policy only applies to "new source code and related data files in KDE repositories". Your question applies equally to the installers for Windows and macOS and the AppImages, FlatPaks, Snaps, etc. which KDE publishes. All of those installers/ packages include loads of third-party libraries and data that is published under all kinds of Open Source licenses. I think our policy could be something like "Everything (executable, libraries, images, data, etc.) included in installers, AppImages, FlatPaks, Snaps, etc. published by KDE must be licensed under an Open Source license.". Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Does KDE have a policy for shipping libraries licensed under the Apache license?
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 > 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 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" >> 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
Re: Does KDE have a policy for shipping libraries licensed under the Apache license?
(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 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" > 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
Re: Does KDE have a policy for shipping libraries licensed under the Apache license?
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" 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 >> > >
Re: Does KDE have a policy for shipping libraries licensed under the Apache license?
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 >
Does KDE have a policy for shipping libraries licensed under the Apache license?
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
