7 ms·

> There’s a lot of GPL software that operates in the grey (and many OSS devs who don’t understand their license choices), Do you have examples? What kinds of m

> There’s a lot of GPL software that operates in the grey (and many OSS devs who don’t understand their license choices), Do you have examples? What kinds of misunderstanding are there? And what gets clarified by this case that wasn’t clear before?

dagmx 3y ago
I can’t give specific examples without calling out some projects. But usually it’s a misunderstanding of what derivative works are. E.g building an extension to a GPL app. Many don’t believe that simply importing a GPL Python module is enough to make your extension have to comply to GPL. Or things like what constitutes distribution. E.g employees vs contractors vs third party collaborators etc… But when I have to deal with said project owners, they bring up that the GPL is about the spirit of the license, not the exact words. They often say not to worry about litigation. This case doesn’t specifically clarify those terms but it does highlight that GPL violation is a serious issue that can’t just be treated as a suggestion. That any lawsuit has taken place and won means that 1. I can point to cases where the license choice is impactful when working with existing projects or when setting up new OSS projects in my industry 2. It also means that the license proponents may feel more empowered (as they should) to take action against infringement. Basically, very few people take software licenses as seriously as they should. Cases like these help make them a more serious matter. The more seriously people take it, the easier my job gets for multiple reasons. And since someone might ask, the license I advocate for the most is Apache 2.0. It covers the most ground, with the most clarity and the most protections for all parties involved.
- pooper 3y ago
  On the other hand, some people freak out too much. All I did was use a ghostscript dll, which is LGPL if I recall correctly. :/
- consp 3y ago
  > Many don’t believe that simply importing a GPL Python module is enough to make your extension have to comply to GPL Wasn't this the, "if the source is in your tree everything is GPL" and otherwise "if it's downloaded module as a package it is not"? Or was that LGPL? Asking to show clarification for everyone. edit: the question was stated as ignorant to get a few decent explanations. Thank you for the effort!
  - juliusdavies 3y ago
    Pipe/exec into GPL generally considered okay (not a derivative work) What you described only okay with LGPL
    - actionfromafar 3y ago
      And pipe/exec not because it's a magic boundary, but because that kind of interface is often so generic and simple it's not constituting a derivate work to use that boundary. But one could easily come up with an example where it is.
      - mytailorisrich 3y ago
        It is a "magic" boundary in that it is an interface to another process, i.e. effectively another program altogether.
        lupusreal 3y ago
        Another process is not necessarily "another program altogether". What presents as "a program" to the user may be a collection of several processes using a variety of IPC methods to interface with each other. "Process" has a fairly concrete technical meaning but "program" is more loosely goosey. A shell script could be called "a program" even though it's executed by a shell process and invokes dozens of other processes, without which it is nothing.
        mytailorisrich 3y ago
        That's a nitpick. Within this discussion if you take a GPL'd piece of software, a "program", and interface to it via pipe/exec you're just using an external program, you're not linking to it and are 'immune' from GPL 'contamination'. If not it would effectively not be possible, or very difficult, to run commercial license programs on Linux, for instance.
        3y ago
- Semaphor 3y ago
  Interesting examples. Also, a weird take for them to think that’s not triggering the virality, if not that, what then? Directly using the source code only? > the GPL is about the spirit of the license, not the exact words. They often say not to worry about litigation. Even weirder. Especially since then, why pick the GPL at all? The only reasons I can see is that you care about free software, and want virality for that reason, and/or you want companies to pick a commercial license.
  - dagmx 3y ago
    Usually, the developers (and this is over multiple different GPL projects with different leads) have the following thought: 1. If you’re not touching the core code, it’s not under the GPL. I try and get them to LGPL license the extension points but they don’t see the benefit in trying to relicense it with all their contributors. 2. For your second point, the issue is that the GPL is intentionally vague as a deterrent for corporate abuse. The issue becomes that, as a corporate user: I have to take the most pessimistic view to protect myself. If I switch my hat to someone non corporate, then I take the most optimistic view. In those cases, they often say to not take the pessimistic view because that’s not the spirit as they understand it.
    - growse 3y ago
      I think I'm with you on this in general > 1. If you’re not touching the core code, it’s not under the GPL. I try and get them to LGPL license the extension points but they don’t see the benefit in trying to relicense it with all their contributors. I sense this comes down to a really poor definition of "linking" (is that the word in the text? Can't remember and don't have it to hand). It's not at all obvious for each software/language ecosystem which specific act constitutes "linking". > 2. For your second point, the issue is that the GPL is intentionally vague as a deterrent for corporate abuse. The issue becomes that, as a corporate user: I have to take the most pessimistic view to protect myself. If I switch my hat to someone non corporate, then I take the most optimistic view. In those cases, they often say to not take the pessimistic view because that’s not the spirit as they understand it. 100%, and this is my gripe against things like the BSL too. It's disingenuous because the aim of the license is to create risk and uncertainty through poor definitions and vagueness.
- lmm 3y ago
  > But usually it’s a misunderstanding of what derivative works are. E.g building an extension to a GPL app. Many don’t believe that simply importing a GPL Python module is enough to make your extension have to comply to GPL. AIUI that's a far from settled question in copyright law (with e.g. Oracle vs Google being mostly reversed on appeal, and different courts applying different standards). For someone who's not in the business of copyright minutiae, it's not a completely unreasonable belief to have.
  - whatisyour 3y ago
    Not really. Including code in your code would always be a copyright violation. The Oracle vs Google case is very different. The OP is talking about copying implementations while Oracle vs Google is about copying APIs. The equivalent of Oracle vs Google here would be if you rewrote the exact same python module with exact same API names, but all your implementation was clean-room implementation. Here the question is, if the APIs themselves are copyrightable.
    - toyg 3y ago
      > Including code in your code would always be a copyright violation. Well, not quite - shipping code with your code would be, because that is direct distributing. But if I ship a script to download your GPL library from PYPI and just use it as it comes, the argument on whether my application is a "derivative" of yours, is not an easy one.
      - regularfry 3y ago
        It's potentially not an easy one in law, but it is one that the GPL is explicitly intended to capture. The only question is whether it has successfully done so (and that actually depends on the specifics of the usage, as I understand it).
    - lmm 3y ago
      > Including code in your code would always be a copyright violation. The Oracle vs Google case is very different. The OP is talking about copying implementations while Oracle vs Google is about copying APIs. Importing a module doesn't generally mean you include that module in your code. It only means you made use of that module's API. So whether that API was copyrightable is very much relevant.
- alentred 3y ago
  > Many don’t believe that simply importing a GPL Python module is enough to make your extension have to comply to GPL. I can almost hear the chairs squeaking under the many SaaS devs reading this. IANAL, but as far I know the debate is not settled on whether this clause applies to SaaS, that is when you do not distribute the software per se, and the general consensus so far is that it does not. This is the "raison d'etre" for the AGPL license, which covers the SaaS use case.
- maccard 3y ago
  > very few people take software licenses as seriously as they should. Isnt the fact that it has taken this long and required a straight up violation of the direct terms of the licence proof that people were probably justified in not caring until now?
- sakjur 3y ago
  The European Commission have published an interesting article disputing the possible viral effect of linking in EU law: https://joinup.ec.europa.eu/collection/eupl/news/why-viral-licensing-ghost https://joinup.ec.europa.eu/collection/eupl/news/why-viral-l... It doesn’t practically change much for most developers, but imo it underlines a bit of the challenge of misunderstandings and the complexity around the sharp corners of open source, in particular outside of the US as most licenses were designed in the US by Americans.
  - account42 3y ago
    Interesting opinion but even if the courts will agree it is not relevant because most software is intended to be distributed globally (including at the very least the US market) and will have to comply with most restrictive interpretation of the license.
    - hnfong 3y ago
      1. Google has taken the headers from OpenJDK (GPL licensed) into Android ( https://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/ https://arstechnica.com/tech-policy/2016/01/android-n-switch... ) 2. USSC claims Google's copying Java headers is fair use. 3. Many jurisdictions does not have a fair use doctrine. So the question is, do you think Google is infringing the GPL by copying headers into Android, according to the most restrictive interpretation or the most restrictive copyright regime? I think the unfortunate truth is that, for some reason, only US copyright law seems to matter.
  - drdebug 3y ago
    The conclusion of the article says "[...] so far linking (even statically) is done for interoperability, does not [...]". IANAL but it could mean that linking against a GPL library for interoperability is OK in EU, but it does not mean it's true for general case of linking with GPL libraries.
- peppermint_gum 3y ago
  >But usually it’s a misunderstanding of what derivative works are. E.g building an extension to a GPL app. Many don’t believe that simply importing a GPL Python module is enough to make your extension have to comply to GPL. The GPL doesn't explicitly define the concept of derivative work. The FSF's interpretation is that linking creates a derivative work, but there's no universal consensus among lawyers on this issue. LWN has an article that presents a few different views on this topic: https://lwn.net/Articles/548216/ https://lwn.net/Articles/548216/
  - JW_00000 3y ago
    The term "derivative work" (or similar) is sometimes defined in law, but of course very abstractly (i.e. not specific to software) and differently depending on jurisdiction. (See https://en.wikipedia.org/wiki/Derivative_work https://en.wikipedia.org/wiki/Derivative_work) IMO it's exactly because of this ambiguity that many developers' understanding of the term is likely to be incorrect, and that most of us don't really understand what our license choice entails.
    - pc86 3y ago
      I think a better way to say this is that every developer's understanding is absolutely incorrect in some jurisdictions. Maybe they're correct in their jurisdiction, but once you start talking about this online, as with every discussion of legalities on HN, people start talking past each other forgetting that many European countries will disagree with each other, and especially forgetting that the US may have several dozen wildly different interpretations.
  - dagmx 3y ago
    Yes , exactly my point. The vagueness is intentional to cause this level of confusion.
- Moru 3y ago
  One argument for you could be that if there is no problem, why aren't they using MIT instead that works the way they want it? No need to use the wrong license if they mean something else.
  - dagmx 3y ago
    It always comes down to “of course a corporate dev would suggest that so you can steal our work ” We (corporate contributors) are simultaneously big contributors to OSS and seen as an enemy. I can’t blame them, especially with cases like this French one. But it does mire a lot of discussion.
- rapnie 3y ago
  Extensions, importing, linking? If your (A)GPL licensed app has a plugin framework, does that 'infect' all the plugins to be similarly licensed? There's likely different situations here, or no? Like e.g. Hashicorp go-plugin where separately compiled plugins are dropped into a directory and communicated to via gRPC cross-process. Or WebAssembly Components being composed together.
- hnfong 3y ago
  I'll tell you a fact that isn't popular or commonly known. At some point Google just took the headers of OpenJDK (GPL licensed) and used it in Android, without relicensing Android to GPL. ( https://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/ https://arstechnica.com/tech-policy/2016/01/android-n-switch... ) Apparently this is fair use according to the US Supreme Court. Technically speaking the case that went to the USSC concerned some prior closed source version of Java, but Oracle doesn't to think there's a material difference since they're not suing Google again for that, and neither do I. The FSF's argument that linking to GPL libraries require you to relicense the code to GPL rests on the legal argument that APIs, headers, etc. are copyrightable. USSC decided that, well, for only for Google's case, sure, fair use, whatever. IMHO the GPL was drafted and marketed specifically to make its legal position seem uncertain, and the outcome of the Oracle v Google case doesn't make things clear. I'm not sure whether you'd actually see a court make a decision on the "GPL" given that the case would almost certainly be a matter of copyright infringement, not a matter of license interpretation, so the license text does not matter. If I were a lawyer I'd advice corporate clients to steer waaay clear of anything GPL.
  - simiones 3y ago
    I don't think this is how these rulings worked. Most importantly, the only reason the courts decided Google wasn't in violation was that Google's purpose, providing a compatible re-implementation of Java for Android, constituted fair use of the interface definition, so Google didn't need a license to use the OpenJDK headers. If Google had copied the OpenJDK headers in order to implement an entirely different system that used the OpenJDK code in a different way, the case would have gone in a fundamentally different direction. Secondly, the legal reasoning for the GPL goes like this: by default, you don't have any right to re-distribute anyone's code (unless some fair use exception applies). The copyright holder can give you certain limited rights through a license - in our case, the GPL. The GPL can essentially impose any conditions, and if you think they are too onerous, then you just don't redistribute the code, period. If the GPL says "you can't re-distribute my code if you link your program with it unless you also distribute the sources of your program, including all precise compilation and installation instructions, and give your users the same rights and obligations", then there is nothing to dispute. The GPL could have also said "you can't redistribute my code unless you throw a penny in a prominent wishing well and light a candle in 3 different churches", and that would have been binding as well, if you wanted to re-distribute their code. The subtleties come when you don't actually want to re-distribute GPL code, but would like to interface with it. Say you want to distribute a program that only works if dynamically linked with GCC. If you publish a bundle on your site with your proprietary program + gcc, you are clearly under the incidence of the GPL, since you are distributing GCC and are dynamically linking with it. However, what if you don't distribute GCC at all, and just tell your users "download my program, and then install GCC under /opt/propritary/utils/gcc"? In this case, is your program bound by the GPL or not? This is a much more complex question, and it is here where you get in the nitty-gritty of what constitutes a derivative work in software. If your program is considered a derivative work of GCC, then you are distributing a derivative of GCC and so you need to respect the terms of the GPL. However, if your program is not a derivative of GCC, then you can entirely ignore the GPL, since you are not stepping on anyone's copyright and so don't need a license. I believe this question is entirely unsettled, and there are plausible arguments (to a layman like myself, at least) both for and against it.
- BobbyTables2 3y ago
  I also hate when projects take BSD/Apache licensed code and change it to GPL. While it seems technically permissible, to me it also muddies the original code’s licensing as well, especially if not well known. It is also bizarre that someone could take BSD code, make trivial modifications, and now such cannot be sent upstream or used under the original license. I happily call out a surprisingly under-appreciated case of this… We only have KVM virtualization on x86 today because Citrix meticulously developed an x86 instruction emulator (many thousand lines of dense code). The Linux kernel took that BSD code and relicensed it as GPL. Sure, at some point one might argue that later modifications by the Linux developers are significant contribution that makes are unique… If I observe a good change Linux made, it is perhaps now questionable that as a 3rd party I create a PR to push the same change upstream… This is an accidentally evil side of GPL that isn’t talked about. But at least in the early days, it also means one cannot freely use Linux’s copy but can do so from Xen —- even though it is the exact same code!! Licensing also invites a trap where careless developers relicense GPL as BSD, and then a conscientious party unknowingly uses the BSD implementation in a closed source product. The only saving grace is most code is horrible for reuse purposes and it is often easier to either reimplement it (from scratch) or use a well known BSD-licensed gem.
  - persnickety 3y ago
    I don't think you can change the license of existing code at all, unless you're the copyright holder. Best you can do is release someone's code as part of a work under another license. Anyway, > It is also bizarre that someone could take BSD code, make trivial modifications, and now such cannot be sent upstream or used under the original license. That's the case for anyone taking BSD sources and turning it into a closed product, isn't it? Even if you get the BSD-licensed sources, the trivial modification will not be upstreamable. That's kind of the entire point of permissive licenses, as opposed to copyleft, isn't it?
  - brlewis 3y ago
    >It is also bizarre that someone could take BSD code, make trivial modifications, and now such cannot be sent upstream or used under the original license. No it is not bizarre. That is precisely how the BSD license is intended to work. If you want to ensure that changes fall under the original license, then you want GPL.
flanked-evergl 3y ago
What constitutes linking, dynamic linking, and static linking, if you use python and plugins? Can the rights holder of proprietary software contribute to or distribute a GPL or LGPL plugin for that software?
- dagmx 3y ago
  You don’t have to distribute the plugin as xGPL but you do need to make it compliant. The L/GPL would widely consider Python imports as dynamic linking. Many companies will instead do shim/bridges that aren’t GPL themselves but something like MIT. The bridge talks to proprietary code and the GPL but doesn’t bridge the license over as a result. This too is somewhat of a grey area though that the GPL is vague on.
  - flanked-evergl 3y ago
    > You don’t have to distribute the plugin as xGPL but you do need to make it compliant. My reading of the GPL is that if you are the rights holder of some software, and there is a xGPL licensed plugin to said software, you can only distribute changes to the plugin if you also distribute your software as xGPL. In other words it is impractical for you to make changes to xGPL licensed plugins to your software. > Many companies will instead do shim/bridges that aren’t GPL themselves but something like MIT. The bridge talks to proprietary code and the GPL but doesn’t bridge the license over as a result. I'm fairly sure this is not legal, see https://www.gnu.org/licenses/gpl-faq.en.html#GPLWrapper https://www.gnu.org/licenses/gpl-faq.en.html#GPLWrapper The point is there is too much in the GPL that is open ended and can only be known for sure after litigation.
    - toyg 3y ago
      > this is not legal Unless the GPL was enshrined in some law I'm not aware of, it's likely to be a a breach of contract, not necessarily "illegal". If a court rules against you, in most cases the worst that can happen is having to pay some redress to the developer and stopping what you were doing.
Culonavirus 3y ago
FFMPEG. Look at the amount of legal horse fertilizer here: https://www.ffmpeg.org/legal.html https://www.ffmpeg.org/legal.html ... and every time I've seen people asking what they can and can't do, someone from the ffmpeg devs (once in a couple of years when they actually respond to someone) just says "talk to your lawyer". I mean, flip a few switches and suddenly you're under a different licence ... and all this you have to look up yourself. Many (especially smaller) devs just don't care and distribute ffmpeg together with their (often non-oss) tools. Given the amount of these in the wild, if someone really had an axe to grind, they could sue hundreds, maybe thousands of devs of all sizes. It's a total minefield. And one of the most popular (L)GPL packages in existence.
- adev_ 3y ago
  It is currently pretty clearly describe. Compile it in LGPL mode and you are good for propriétaire use cases. There is nothing fundamentally dangerous with the LGPLv2.1. It is mainly annoying in case of static linking due to the obligation of providing object files but will not contaminate your codebase like the GPL does.
- Semaphor 3y ago
  My experience with FFMPEG is that it’s usually not directly distributed for probably those reasons. The only times I remember getting it directly with software, was for GPL software.
  - Culonavirus 3y ago
    Eh, I'm just gonna point out that you can find ffmpeg code (proprietary decoders even) distributed with Electron. I'm not even going to think about how many proprietary apps built on top of Electron have no idea about that. Look at the answer here: https://stackoverflow.com/questions/67799370/legal-issues-in-shipping-apps-based-on-electron-framework-libffmpeg https://stackoverflow.com/questions/67799370/legal-issues-in...
Thorrez 3y ago
The Python websocket-client library switched from LGPL to BSD without realizing you need to get all contributors to sign off on that. https://github.com/websocket-client/websocket-client/issues/526 https://github.com/websocket-client/websocket-client/issues/... It looks like that did get rectified a few years later: https://github.com/websocket-client/websocket-client/issues/697 https://github.com/websocket-client/websocket-client/issues/...

dagmx 3y ago

I can’t give specific examples without calling out some projects. But usually it’s a misunderstanding of what derivative works are. E.g building an extension to a GPL app. Many don’t believe that simply importing a GPL Python module is enough to make your extension have to comply to GPL. Or things like what constitutes distribution. E.g employees vs contractors vs third party collaborators etc… But when I have to deal with said project owners, they bring up that the GPL is about the spirit of the license, not the exact words. They often say not to worry about litigation. This case doesn’t specifically clarify those terms but it does highlight that GPL violation is a serious issue that can’t just be treated as a suggestion. That any lawsuit has taken place and won means that 1. I can point to cases where the license choice is impactful when working with existing projects or when setting up new OSS projects in my industry 2. It also means that the license proponents may feel more empowered (as they should) to take action against infringement. Basically, very few people take software licenses as seriously as they should. Cases like these help make them a more serious matter. The more seriously people take it, the easier my job gets for multiple reasons. And since someone might ask, the license I advocate for the most is Apache 2.0. It covers the most ground, with the most clarity and the most protections for all parties involved.

pooper 3y ago
On the other hand, some people freak out too much. All I did was use a ghostscript dll, which is LGPL if I recall correctly. :/
consp 3y ago
> Many don’t believe that simply importing a GPL Python module is enough to make your extension have to comply to GPL Wasn't this the, "if the source is in your tree everything is GPL" and otherwise "if it's downloaded module as a package it is not"? Or was that LGPL? Asking to show clarification for everyone. edit: the question was stated as ignorant to get a few decent explanations. Thank you for the effort!
- juliusdavies 3y ago
  Pipe/exec into GPL generally considered okay (not a derivative work) What you described only okay with LGPL
  - actionfromafar 3y ago
    And pipe/exec not because it's a magic boundary, but because that kind of interface is often so generic and simple it's not constituting a derivate work to use that boundary. But one could easily come up with an example where it is.
    - mytailorisrich 3y ago
      It is a "magic" boundary in that it is an interface to another process, i.e. effectively another program altogether.
      - lupusreal 3y ago
        Another process is not necessarily "another program altogether". What presents as "a program" to the user may be a collection of several processes using a variety of IPC methods to interface with each other. "Process" has a fairly concrete technical meaning but "program" is more loosely goosey. A shell script could be called "a program" even though it's executed by a shell process and invokes dozens of other processes, without which it is nothing.
        mytailorisrich 3y ago
        That's a nitpick. Within this discussion if you take a GPL'd piece of software, a "program", and interface to it via pipe/exec you're just using an external program, you're not linking to it and are 'immune' from GPL 'contamination'. If not it would effectively not be possible, or very difficult, to run commercial license programs on Linux, for instance.
        3y ago
Semaphor 3y ago
Interesting examples. Also, a weird take for them to think that’s not triggering the virality, if not that, what then? Directly using the source code only? > the GPL is about the spirit of the license, not the exact words. They often say not to worry about litigation. Even weirder. Especially since then, why pick the GPL at all? The only reasons I can see is that you care about free software, and want virality for that reason, and/or you want companies to pick a commercial license.
- dagmx 3y ago
  Usually, the developers (and this is over multiple different GPL projects with different leads) have the following thought: 1. If you’re not touching the core code, it’s not under the GPL. I try and get them to LGPL license the extension points but they don’t see the benefit in trying to relicense it with all their contributors. 2. For your second point, the issue is that the GPL is intentionally vague as a deterrent for corporate abuse. The issue becomes that, as a corporate user: I have to take the most pessimistic view to protect myself. If I switch my hat to someone non corporate, then I take the most optimistic view. In those cases, they often say to not take the pessimistic view because that’s not the spirit as they understand it.
  - growse 3y ago
    I think I'm with you on this in general > 1. If you’re not touching the core code, it’s not under the GPL. I try and get them to LGPL license the extension points but they don’t see the benefit in trying to relicense it with all their contributors. I sense this comes down to a really poor definition of "linking" (is that the word in the text? Can't remember and don't have it to hand). It's not at all obvious for each software/language ecosystem which specific act constitutes "linking". > 2. For your second point, the issue is that the GPL is intentionally vague as a deterrent for corporate abuse. The issue becomes that, as a corporate user: I have to take the most pessimistic view to protect myself. If I switch my hat to someone non corporate, then I take the most optimistic view. In those cases, they often say to not take the pessimistic view because that’s not the spirit as they understand it. 100%, and this is my gripe against things like the BSL too. It's disingenuous because the aim of the license is to create risk and uncertainty through poor definitions and vagueness.
lmm 3y ago
> But usually it’s a misunderstanding of what derivative works are. E.g building an extension to a GPL app. Many don’t believe that simply importing a GPL Python module is enough to make your extension have to comply to GPL. AIUI that's a far from settled question in copyright law (with e.g. Oracle vs Google being mostly reversed on appeal, and different courts applying different standards). For someone who's not in the business of copyright minutiae, it's not a completely unreasonable belief to have.
- whatisyour 3y ago
  Not really. Including code in your code would always be a copyright violation. The Oracle vs Google case is very different. The OP is talking about copying implementations while Oracle vs Google is about copying APIs. The equivalent of Oracle vs Google here would be if you rewrote the exact same python module with exact same API names, but all your implementation was clean-room implementation. Here the question is, if the APIs themselves are copyrightable.
  - toyg 3y ago
    > Including code in your code would always be a copyright violation. Well, not quite - shipping code with your code would be, because that is direct distributing. But if I ship a script to download your GPL library from PYPI and just use it as it comes, the argument on whether my application is a "derivative" of yours, is not an easy one.
    - regularfry 3y ago
      It's potentially not an easy one in law, but it is one that the GPL is explicitly intended to capture. The only question is whether it has successfully done so (and that actually depends on the specifics of the usage, as I understand it).
  - lmm 3y ago
    > Including code in your code would always be a copyright violation. The Oracle vs Google case is very different. The OP is talking about copying implementations while Oracle vs Google is about copying APIs. Importing a module doesn't generally mean you include that module in your code. It only means you made use of that module's API. So whether that API was copyrightable is very much relevant.
alentred 3y ago
> Many don’t believe that simply importing a GPL Python module is enough to make your extension have to comply to GPL. I can almost hear the chairs squeaking under the many SaaS devs reading this. IANAL, but as far I know the debate is not settled on whether this clause applies to SaaS, that is when you do not distribute the software per se, and the general consensus so far is that it does not. This is the "raison d'etre" for the AGPL license, which covers the SaaS use case.
maccard 3y ago
> very few people take software licenses as seriously as they should. Isnt the fact that it has taken this long and required a straight up violation of the direct terms of the licence proof that people were probably justified in not caring until now?
sakjur 3y ago
The European Commission have published an interesting article disputing the possible viral effect of linking in EU law: https://joinup.ec.europa.eu/collection/eupl/news/why-viral-licensing-ghost https://joinup.ec.europa.eu/collection/eupl/news/why-viral-l... It doesn’t practically change much for most developers, but imo it underlines a bit of the challenge of misunderstandings and the complexity around the sharp corners of open source, in particular outside of the US as most licenses were designed in the US by Americans.
- account42 3y ago
  Interesting opinion but even if the courts will agree it is not relevant because most software is intended to be distributed globally (including at the very least the US market) and will have to comply with most restrictive interpretation of the license.
  - hnfong 3y ago
    1. Google has taken the headers from OpenJDK (GPL licensed) into Android ( https://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/ https://arstechnica.com/tech-policy/2016/01/android-n-switch... ) 2. USSC claims Google's copying Java headers is fair use. 3. Many jurisdictions does not have a fair use doctrine. So the question is, do you think Google is infringing the GPL by copying headers into Android, according to the most restrictive interpretation or the most restrictive copyright regime? I think the unfortunate truth is that, for some reason, only US copyright law seems to matter.
- drdebug 3y ago
  The conclusion of the article says "[...] so far linking (even statically) is done for interoperability, does not [...]". IANAL but it could mean that linking against a GPL library for interoperability is OK in EU, but it does not mean it's true for general case of linking with GPL libraries.
peppermint_gum 3y ago
>But usually it’s a misunderstanding of what derivative works are. E.g building an extension to a GPL app. Many don’t believe that simply importing a GPL Python module is enough to make your extension have to comply to GPL. The GPL doesn't explicitly define the concept of derivative work. The FSF's interpretation is that linking creates a derivative work, but there's no universal consensus among lawyers on this issue. LWN has an article that presents a few different views on this topic: https://lwn.net/Articles/548216/ https://lwn.net/Articles/548216/
- JW_00000 3y ago
  The term "derivative work" (or similar) is sometimes defined in law, but of course very abstractly (i.e. not specific to software) and differently depending on jurisdiction. (See https://en.wikipedia.org/wiki/Derivative_work https://en.wikipedia.org/wiki/Derivative_work) IMO it's exactly because of this ambiguity that many developers' understanding of the term is likely to be incorrect, and that most of us don't really understand what our license choice entails.
  - pc86 3y ago
    I think a better way to say this is that every developer's understanding is absolutely incorrect in some jurisdictions. Maybe they're correct in their jurisdiction, but once you start talking about this online, as with every discussion of legalities on HN, people start talking past each other forgetting that many European countries will disagree with each other, and especially forgetting that the US may have several dozen wildly different interpretations.
- dagmx 3y ago
  Yes , exactly my point. The vagueness is intentional to cause this level of confusion.
Moru 3y ago
One argument for you could be that if there is no problem, why aren't they using MIT instead that works the way they want it? No need to use the wrong license if they mean something else.
- dagmx 3y ago
  It always comes down to “of course a corporate dev would suggest that so you can steal our work ” We (corporate contributors) are simultaneously big contributors to OSS and seen as an enemy. I can’t blame them, especially with cases like this French one. But it does mire a lot of discussion.
rapnie 3y ago
Extensions, importing, linking? If your (A)GPL licensed app has a plugin framework, does that 'infect' all the plugins to be similarly licensed? There's likely different situations here, or no? Like e.g. Hashicorp go-plugin where separately compiled plugins are dropped into a directory and communicated to via gRPC cross-process. Or WebAssembly Components being composed together.
hnfong 3y ago
I'll tell you a fact that isn't popular or commonly known. At some point Google just took the headers of OpenJDK (GPL licensed) and used it in Android, without relicensing Android to GPL. ( https://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/ https://arstechnica.com/tech-policy/2016/01/android-n-switch... ) Apparently this is fair use according to the US Supreme Court. Technically speaking the case that went to the USSC concerned some prior closed source version of Java, but Oracle doesn't to think there's a material difference since they're not suing Google again for that, and neither do I. The FSF's argument that linking to GPL libraries require you to relicense the code to GPL rests on the legal argument that APIs, headers, etc. are copyrightable. USSC decided that, well, for only for Google's case, sure, fair use, whatever. IMHO the GPL was drafted and marketed specifically to make its legal position seem uncertain, and the outcome of the Oracle v Google case doesn't make things clear. I'm not sure whether you'd actually see a court make a decision on the "GPL" given that the case would almost certainly be a matter of copyright infringement, not a matter of license interpretation, so the license text does not matter. If I were a lawyer I'd advice corporate clients to steer waaay clear of anything GPL.
- simiones 3y ago
  I don't think this is how these rulings worked. Most importantly, the only reason the courts decided Google wasn't in violation was that Google's purpose, providing a compatible re-implementation of Java for Android, constituted fair use of the interface definition, so Google didn't need a license to use the OpenJDK headers. If Google had copied the OpenJDK headers in order to implement an entirely different system that used the OpenJDK code in a different way, the case would have gone in a fundamentally different direction. Secondly, the legal reasoning for the GPL goes like this: by default, you don't have any right to re-distribute anyone's code (unless some fair use exception applies). The copyright holder can give you certain limited rights through a license - in our case, the GPL. The GPL can essentially impose any conditions, and if you think they are too onerous, then you just don't redistribute the code, period. If the GPL says "you can't re-distribute my code if you link your program with it unless you also distribute the sources of your program, including all precise compilation and installation instructions, and give your users the same rights and obligations", then there is nothing to dispute. The GPL could have also said "you can't redistribute my code unless you throw a penny in a prominent wishing well and light a candle in 3 different churches", and that would have been binding as well, if you wanted to re-distribute their code. The subtleties come when you don't actually want to re-distribute GPL code, but would like to interface with it. Say you want to distribute a program that only works if dynamically linked with GCC. If you publish a bundle on your site with your proprietary program + gcc, you are clearly under the incidence of the GPL, since you are distributing GCC and are dynamically linking with it. However, what if you don't distribute GCC at all, and just tell your users "download my program, and then install GCC under /opt/propritary/utils/gcc"? In this case, is your program bound by the GPL or not? This is a much more complex question, and it is here where you get in the nitty-gritty of what constitutes a derivative work in software. If your program is considered a derivative work of GCC, then you are distributing a derivative of GCC and so you need to respect the terms of the GPL. However, if your program is not a derivative of GCC, then you can entirely ignore the GPL, since you are not stepping on anyone's copyright and so don't need a license. I believe this question is entirely unsettled, and there are plausible arguments (to a layman like myself, at least) both for and against it.
BobbyTables2 3y ago
I also hate when projects take BSD/Apache licensed code and change it to GPL. While it seems technically permissible, to me it also muddies the original code’s licensing as well, especially if not well known. It is also bizarre that someone could take BSD code, make trivial modifications, and now such cannot be sent upstream or used under the original license. I happily call out a surprisingly under-appreciated case of this… We only have KVM virtualization on x86 today because Citrix meticulously developed an x86 instruction emulator (many thousand lines of dense code). The Linux kernel took that BSD code and relicensed it as GPL. Sure, at some point one might argue that later modifications by the Linux developers are significant contribution that makes are unique… If I observe a good change Linux made, it is perhaps now questionable that as a 3rd party I create a PR to push the same change upstream… This is an accidentally evil side of GPL that isn’t talked about. But at least in the early days, it also means one cannot freely use Linux’s copy but can do so from Xen —- even though it is the exact same code!! Licensing also invites a trap where careless developers relicense GPL as BSD, and then a conscientious party unknowingly uses the BSD implementation in a closed source product. The only saving grace is most code is horrible for reuse purposes and it is often easier to either reimplement it (from scratch) or use a well known BSD-licensed gem.
- persnickety 3y ago
  I don't think you can change the license of existing code at all, unless you're the copyright holder. Best you can do is release someone's code as part of a work under another license. Anyway, > It is also bizarre that someone could take BSD code, make trivial modifications, and now such cannot be sent upstream or used under the original license. That's the case for anyone taking BSD sources and turning it into a closed product, isn't it? Even if you get the BSD-licensed sources, the trivial modification will not be upstreamable. That's kind of the entire point of permissive licenses, as opposed to copyleft, isn't it?
- brlewis 3y ago
  >It is also bizarre that someone could take BSD code, make trivial modifications, and now such cannot be sent upstream or used under the original license. No it is not bizarre. That is precisely how the BSD license is intended to work. If you want to ensure that changes fall under the original license, then you want GPL.

flanked-evergl 3y ago

What constitutes linking, dynamic linking, and static linking, if you use python and plugins? Can the rights holder of proprietary software contribute to or distribute a GPL or LGPL plugin for that software?

dagmx 3y ago
You don’t have to distribute the plugin as xGPL but you do need to make it compliant. The L/GPL would widely consider Python imports as dynamic linking. Many companies will instead do shim/bridges that aren’t GPL themselves but something like MIT. The bridge talks to proprietary code and the GPL but doesn’t bridge the license over as a result. This too is somewhat of a grey area though that the GPL is vague on.
- flanked-evergl 3y ago
  > You don’t have to distribute the plugin as xGPL but you do need to make it compliant. My reading of the GPL is that if you are the rights holder of some software, and there is a xGPL licensed plugin to said software, you can only distribute changes to the plugin if you also distribute your software as xGPL. In other words it is impractical for you to make changes to xGPL licensed plugins to your software. > Many companies will instead do shim/bridges that aren’t GPL themselves but something like MIT. The bridge talks to proprietary code and the GPL but doesn’t bridge the license over as a result. I'm fairly sure this is not legal, see https://www.gnu.org/licenses/gpl-faq.en.html#GPLWrapper https://www.gnu.org/licenses/gpl-faq.en.html#GPLWrapper The point is there is too much in the GPL that is open ended and can only be known for sure after litigation.
  - toyg 3y ago
    > this is not legal Unless the GPL was enshrined in some law I'm not aware of, it's likely to be a a breach of contract, not necessarily "illegal". If a court rules against you, in most cases the worst that can happen is having to pay some redress to the developer and stopping what you were doing.

Culonavirus 3y ago

FFMPEG. Look at the amount of legal horse fertilizer here: https://www.ffmpeg.org/legal.html https://www.ffmpeg.org/legal.html ... and every time I've seen people asking what they can and can't do, someone from the ffmpeg devs (once in a couple of years when they actually respond to someone) just says "talk to your lawyer". I mean, flip a few switches and suddenly you're under a different licence ... and all this you have to look up yourself. Many (especially smaller) devs just don't care and distribute ffmpeg together with their (often non-oss) tools. Given the amount of these in the wild, if someone really had an axe to grind, they could sue hundreds, maybe thousands of devs of all sizes. It's a total minefield. And one of the most popular (L)GPL packages in existence.

adev_ 3y ago
It is currently pretty clearly describe. Compile it in LGPL mode and you are good for propriétaire use cases. There is nothing fundamentally dangerous with the LGPLv2.1. It is mainly annoying in case of static linking due to the obligation of providing object files but will not contaminate your codebase like the GPL does.
Semaphor 3y ago
My experience with FFMPEG is that it’s usually not directly distributed for probably those reasons. The only times I remember getting it directly with software, was for GPL software.
- Culonavirus 3y ago
  Eh, I'm just gonna point out that you can find ffmpeg code (proprietary decoders even) distributed with Electron. I'm not even going to think about how many proprietary apps built on top of Electron have no idea about that. Look at the answer here: https://stackoverflow.com/questions/67799370/legal-issues-in-shipping-apps-based-on-electron-framework-libffmpeg https://stackoverflow.com/questions/67799370/legal-issues-in...

Thorrez 3y ago

The Python websocket-client library switched from LGPL to BSD without realizing you need to get all contributors to sign off on that. https://github.com/websocket-client/websocket-client/issues/526 https://github.com/websocket-client/websocket-client/issues/... It looks like that did get rectified a few years later: https://github.com/websocket-client/websocket-client/issues/697 https://github.com/websocket-client/websocket-client/issues/...