Re: MPL2 instead of LGPL
Am 19. August 2020 19:27:09 MESZ schrieb Roman Gilg : On Wed, Aug 19, 2020 at 6:01 PM Sandro Andrade wrote: On Sun, Aug 16, 2020 at 5:11 AM Roman Gilg wrote: > > Hi, Hi Roman, > * Proprietary code static linking LGPL code is not practically doable. > [5] See also above ZeroMQ exception. This is a topic every now and then pops around when discussing licensing issues. The FSF is pretty clear in stating the providing object files are enough to enable users to relink with different versions of the LGPL library. I see some projects using LGPL + static linking exceptions and I've read all the things regarding "work based on the library" vs "work which uses the library", header dependencies, and so on but such LGPL exceptions look more like a clarification point than a thing not already covered by LGPL. I really don't see the point of comments like "If you statically link a LGPL library, then the application itself must be LGPL. We have had our lawyer double-check on this in the past. Dynamically linking to a LGPL library is the only way to avoid becoming LGPL", presented in the stackoverflow link [5] you provided. Could you elaborate a bit why this is not practically doable or legally incorrect? Hi Sandro, no I can't. I was just rephrasing what I read in some sources online and asking here for educated opinions on if this interpretation is right or wrong. Thanks for taking the time to "debunk" some of the myths floating around. Do you see it the same way in regards to the usage of templates in C++ libraries licensed under the LGPL? Is this also a "non-issue" in the end? I think all of this is pretty much a non issue. You are looking at this from the position of an engineer. But licenses are legal-speech and would be interpreted by a judge. Most likely a judge does not have the technical knowledge to understand the differences. It is very unlikely that a judge would understand the implications of different linker flags (static vs. dynamic linking). Anybody without a high technical background won't understand that. What matters more is the intention of the license. And that is clear. It's the "lesser" gpl. And it would be interpreted like that. The (l)gpl was written with C in mind. Adapting it to other languages is difficult for us, but probably not for a legal person. A template library is a library. That it is kind of static linking is an implementation detail. And here the intention matters: if one would have wanted the gpl restrictions one would choose gpl as license. But using lgpl clearly states that one doesn't want the gpl restrictions to hold. Granted all of that has not been tested in a court. Thus if one wants to be clear it might make sense to dual license or use class path exceptions, etc. But for our frameworks it's a non issue as we always stated the intention: allow users of Qt's commercial license to use our libraries. If a copyright holder would turn into a McHardy he would hopefully lose at court, especially if we as the community would contradict the claims. Cheers and IANAL Martin
Re: KDE Apps name trademarks
Am 2020-07-08 20:45, schrieb Jack: On 2020.07.08 14:20, Ben Cooksley wrote: On Thu, Jul 9, 2020 at 6:09 AM Christoph Cullmann wrote: > > On 2020-07-08 18:12, Jonathan Riddell wrote: > > Recently we've noticed some KDE apps ending up on the Microsoft Store > > uploaded by unknown third parties. Maybe to up some credit score for > > their developer account. Maybe to install bitcoin miners. We don't > > know the motivations. Since it's all free software the licence allows > > it. > > Hi, > > have you some links to these applications? I believe Jonathan will be referring to https://www.microsoft.com/en-gb/p/kdiff-3-diff-utility/9ndvvx243rfh?activetab=pivot:overviewtab# If I follow that link, and click for the US version, I see KDiff3 for sale at $4.99. Does the license actually allow charging? (I wonder how that is split between MS and the uploader.) GPLv3 Section 6 d "Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. " So yes, charging is fine, not providing the source code looks to me like a GPL violation. And I think that puts the ball to KDE e.V. board to contact Microsoft. Cheers Martin
Re: KDE Apps name trademarks
Am 2020-07-08 18:12, schrieb Jonathan Riddell: Recently we've noticed some KDE apps ending up on the Microsoft Store uploaded by unknown third parties. Maybe to up some credit score for their developer account. Maybe to install bitcoin miners. We don't know the motivations. Since it's all free software the licence allows it. Honestly I don't think we should try to get software from Microsoft Store based on trademark. As you already notice our license allows this. And even more on Linux it's the normal way that someone else distributes our software. Back in the days SuSE even sold our software. It's even common that our distributors apply patches to our software. So we shouldn't treat the Microsoft Store different to Linux distributions. Granted I consider it as a huge problem that the Microsoft Store might contain copies of our software with malware. But to that we have solutions: the GPL. We can demand the source code from those distributors. If they don't comply: even better, than we have something! If they comply and our software is reproducible, we can verify that the uploaded binary is not tampered with (and that it doesn't comply to GPL). Yes, that puts work on our shoulders. If our software doesn't build reproducible, we need to fix that. Otherwise I suggest that we bring all our software in the Microsoft Store to ensure we at least uploaded it. If we have it uploaded and someone else uploads it as well, we can still ask Microsoft to do something about it. I hope that Microsoft is interested in not distributing malware and removes copies of open source projects or adds links to the original authors. After all Microsoft really tries to be on the good side currently, so we should try ;-) Cheers Martin
