5 ms·

> 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 you

by 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.
        Nursie 3y ago
        I think that's probably an interesting case, and whether it's a valid defence is going to depend on what you're doing. If you are (for example) shipping a product which is effectively a thin wrapper around a GPL 'd component, but instead of linking to a GPL'd library you've written and dutifully GPL'd a small shim program that turns the library into an executable and reads function arguments over a pipe, then you call that from your 'non-GPL' code... I don't think you'll find the process boundary is some sort of absolute defence in law. In fact you may be looked upon unkindly in court for having knowingly attempted a license circumvention mechanism. The law is not necessarily sensitive to the exact inner workings of a turing machine, and the definition of a derivative work may or may not be affected by such shenanigans.
        EnigmaFlare 3y ago
        If the whole product you're selling is just a thin wrapper around GPL code, why not simply sell the GPL code or GPL the wrapper? Surely the wrapper would be trivial for a competitor to replicate so the reason you're able to make money from it must be something else like other services you provide with it, or just the value of you having chosen and distributed that particular GPL program.
        Nursie 3y ago
        It was more of a thought experiment to show that a process boundary isn’t likely to be some sort of perfect defence, than a real example of how someone might operate.
        3y ago
  - hnfong 3y ago
    It's extremely entertaining to see people here arguing that programming and software interfaces should be copyrightable and therefore protected by the GPL. Pretty sure the prevalent opinion was that it was going to be the end of the world if the US Supreme Court ruled that APIs were copyrightable in the Oracle v Google case. Just say'n.
    - juliusdavies 3y ago
      I think there is a way to make APIs copyrightable: 1.) Hire a bonafide poet (e.g., someone with an MFA degree in Creative Writing). 2.) Have them write Haikus on salary for your company ("work made for hire" under copyright law). 3.) Use the Haikus in your API names. e.g. for a sqrt() function in Java: public double sqrt___an_ancient_pond_$_a_frog_jumps_in_$_the_splash_of_water(double number);
dagmx 3y ago
I’m trivializing here but for sake of brevity: LGPL allows dynamic linkage without open sourcing your components. GPL requires any linkage to open source your parts, but allows for process boundary to not be viral. AGPL is the nuclear don’t touch because it is vital to all possible usage types. Again, that’s trivializing because there’s many subtle details that in many cases are intentionally not clarified in the licenses themselves
- tsimionescu 3y ago
  There is no difference whatsoever between the GPL and the AGPL for software you distribute. The only difference between the AGPL and the GPL relates to software you don't distribute, but that you make available over a network, such as hosting an AGPL web server. The AGPL says that as long as public users interact with this web server, they have the right to get the code and deployment instructions and AGPL rights to be able to run the exact same service themselves, just as if they had downloaded the software. The FSF's (very reasonable) position is that linking to a piece of software makes your software a derivative work, but that launching it as a separate process or accessing it over a network generally doesn't. However, if you exchange very complex internal data structures with this GPL software running in a separate process, whether you do it over a network or through pipes or command line arguments or whatever, then your program is still a derivative work, in their opinion. That is, if you run gcc in a separate process but then mmap() it's memory and search for its entry points and jump to the memory locations of GCC functions in order to generate optimized code for a piece of GCC AST you provide, then your program is a derivative of GCC (according to the FSF, at least) even though GCC is running in a separate process.
  - jasonjayr 3y ago
    A few articles I've read suggest that the AGPL terms trigger if you MODIFY AGPL covered code. So if you (1) setup an AGPL service over the network "as-is" with no changes, (2) use the AGPL-covered service from your proprietary code over the network (ie, across a process boundary), then you are in the clear, and your proprietary code can remain closed. If you instead, modify/customize the source of the AGPL-covered service, then you are required to make available your changes to AGPL-covered product under a AGPL license. Is this a correct understanding of the situation? If the product implements a publicly documented protocol to communicate over the network (ie, not "complex internal structures", and/or replaceable with another product), is that permitted?
bnprks 3y ago
Looking closer at the GPL, it seems like most requirements only kick in once you "convey" GPL-covered code. If you make your users get the GPL component themselves from a 3rd party (e.g. PyPI or other package repository), then you might be okay. I'd be curious for input from others, but it seems like the following flow avoids GPL virality by avoiding "conveying" the GPL-covered code to the end-user: 1. You give your user a non-GPL python package with requirements.txt file (no bundled dependencies) 2. Your user pip-installs the dependencies (including some GPL-licensed ones) 3. Your user runs the application As long as your country doesn't consider use of an API prohibited under the copyright of the implementing code, I think steps 1-3 would be fine (though not very practical for a product). I'd be curious for others input, though, as this has bugged be for a while in the R community where several core libraries (like the Matrix package) are GPL licensed but many packages that depend on GPL packages claim to be licensed under MIT or some other license.
- missjellyfish 3y ago
  The end result will most probably violate the GPL. However, this is only realized by each user; you could probably argue that you never test your software and only look at API documentation. And then it becomes a problem of proving your users violating the GPL. So you'd have to go after each one of them, which will be incredibly difficult, and proving damages would be even more difficult. It's an asshole way of exploiting "Wo kein Kläger, da kein Richter" (where's no plaintiff, there's no judge) since actually proving that the developers violated the GPL will be difficult, unless they have a CI system that readily documents this.
  - account42 3y ago
    As a pure copyright license the GPL concerns itself with distribution only. You cannot violate the GPL as an end user without distributing something.
    - missjellyfish 3y ago
      Yes, all of the above is on the condition that some distribution happened (and you can prove that). However, distribution also happens in places you might not expect. As a business, I'd stray far away from such constructs even if I only use this construct internally. However, this is purely based on the wording of the GPL. For example, the EUPL explicitly covers the creation of derivative works - and I'd argue that the proposed circumvention would create a derivative work.

by consp 3y ago

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.
      - Nursie 3y ago
        I think that's probably an interesting case, and whether it's a valid defence is going to depend on what you're doing. If you are (for example) shipping a product which is effectively a thin wrapper around a GPL 'd component, but instead of linking to a GPL'd library you've written and dutifully GPL'd a small shim program that turns the library into an executable and reads function arguments over a pipe, then you call that from your 'non-GPL' code... I don't think you'll find the process boundary is some sort of absolute defence in law. In fact you may be looked upon unkindly in court for having knowingly attempted a license circumvention mechanism. The law is not necessarily sensitive to the exact inner workings of a turing machine, and the definition of a derivative work may or may not be affected by such shenanigans.
        EnigmaFlare 3y ago
        If the whole product you're selling is just a thin wrapper around GPL code, why not simply sell the GPL code or GPL the wrapper? Surely the wrapper would be trivial for a competitor to replicate so the reason you're able to make money from it must be something else like other services you provide with it, or just the value of you having chosen and distributed that particular GPL program.
        Nursie 3y ago
        It was more of a thought experiment to show that a process boundary isn’t likely to be some sort of perfect defence, than a real example of how someone might operate.
      - 3y ago
- hnfong 3y ago
  It's extremely entertaining to see people here arguing that programming and software interfaces should be copyrightable and therefore protected by the GPL. Pretty sure the prevalent opinion was that it was going to be the end of the world if the US Supreme Court ruled that APIs were copyrightable in the Oracle v Google case. Just say'n.
  - juliusdavies 3y ago
    I think there is a way to make APIs copyrightable: 1.) Hire a bonafide poet (e.g., someone with an MFA degree in Creative Writing). 2.) Have them write Haikus on salary for your company ("work made for hire" under copyright law). 3.) Use the Haikus in your API names. e.g. for a sqrt() function in Java: public double sqrt___an_ancient_pond_$_a_frog_jumps_in_$_the_splash_of_water(double number);

dagmx 3y ago

I’m trivializing here but for sake of brevity: LGPL allows dynamic linkage without open sourcing your components. GPL requires any linkage to open source your parts, but allows for process boundary to not be viral. AGPL is the nuclear don’t touch because it is vital to all possible usage types. Again, that’s trivializing because there’s many subtle details that in many cases are intentionally not clarified in the licenses themselves

tsimionescu 3y ago
There is no difference whatsoever between the GPL and the AGPL for software you distribute. The only difference between the AGPL and the GPL relates to software you don't distribute, but that you make available over a network, such as hosting an AGPL web server. The AGPL says that as long as public users interact with this web server, they have the right to get the code and deployment instructions and AGPL rights to be able to run the exact same service themselves, just as if they had downloaded the software. The FSF's (very reasonable) position is that linking to a piece of software makes your software a derivative work, but that launching it as a separate process or accessing it over a network generally doesn't. However, if you exchange very complex internal data structures with this GPL software running in a separate process, whether you do it over a network or through pipes or command line arguments or whatever, then your program is still a derivative work, in their opinion. That is, if you run gcc in a separate process but then mmap() it's memory and search for its entry points and jump to the memory locations of GCC functions in order to generate optimized code for a piece of GCC AST you provide, then your program is a derivative of GCC (according to the FSF, at least) even though GCC is running in a separate process.
- jasonjayr 3y ago
  A few articles I've read suggest that the AGPL terms trigger if you MODIFY AGPL covered code. So if you (1) setup an AGPL service over the network "as-is" with no changes, (2) use the AGPL-covered service from your proprietary code over the network (ie, across a process boundary), then you are in the clear, and your proprietary code can remain closed. If you instead, modify/customize the source of the AGPL-covered service, then you are required to make available your changes to AGPL-covered product under a AGPL license. Is this a correct understanding of the situation? If the product implements a publicly documented protocol to communicate over the network (ie, not "complex internal structures", and/or replaceable with another product), is that permitted?

bnprks 3y ago

Looking closer at the GPL, it seems like most requirements only kick in once you "convey" GPL-covered code. If you make your users get the GPL component themselves from a 3rd party (e.g. PyPI or other package repository), then you might be okay. I'd be curious for input from others, but it seems like the following flow avoids GPL virality by avoiding "conveying" the GPL-covered code to the end-user: 1. You give your user a non-GPL python package with requirements.txt file (no bundled dependencies) 2. Your user pip-installs the dependencies (including some GPL-licensed ones) 3. Your user runs the application As long as your country doesn't consider use of an API prohibited under the copyright of the implementing code, I think steps 1-3 would be fine (though not very practical for a product). I'd be curious for others input, though, as this has bugged be for a while in the R community where several core libraries (like the Matrix package) are GPL licensed but many packages that depend on GPL packages claim to be licensed under MIT or some other license.

missjellyfish 3y ago
The end result will most probably violate the GPL. However, this is only realized by each user; you could probably argue that you never test your software and only look at API documentation. And then it becomes a problem of proving your users violating the GPL. So you'd have to go after each one of them, which will be incredibly difficult, and proving damages would be even more difficult. It's an asshole way of exploiting "Wo kein Kläger, da kein Richter" (where's no plaintiff, there's no judge) since actually proving that the developers violated the GPL will be difficult, unless they have a CI system that readily documents this.
- account42 3y ago
  As a pure copyright license the GPL concerns itself with distribution only. You cannot violate the GPL as an end user without distributing something.
  - missjellyfish 3y ago
    Yes, all of the above is on the condition that some distribution happened (and you can prove that). However, distribution also happens in places you might not expect. As a business, I'd stray far away from such constructs even if I only use this construct internally. However, this is purely based on the wording of the GPL. For example, the EUPL explicitly covers the creation of derivative works - and I'd argue that the proposed circumvention would create a derivative work.