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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >>>> 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" <[email protected]> >>>> >>> 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 >>>>>> >>>>>
