Hacker News new | ask | show | jobs
by bnprks 834 days 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.

2 comments

Yeah for interpreted languages this may be OK. For compiled languages it becomes harder to not "convey" anything derived from GPL code you linked against. The GPL even explicitly exempts system components for this reason.
Even for compiled languages, you can get around this with a properly architected plugin architecture. Your core project (non-GPL) exposes a runtime plugin interface. It has no clue what plugins will be used, but provides all the operations needed for the plugin to do what it needs. Create a plugin which links to the GPL code. GPL the plugin itself. The user can then be directed to install the GPL plugin. I can’t see how this would be a violation (by the core developer) of the GPL, as the core doesn’t have the first clue what license its plugins are using, and indeed, multiple plugins could be used that have contradictory licenses.
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.

As a pure copyright license the GPL concerns itself with distribution only. You cannot violate the GPL as an end user without distributing something.
To be pedantic, you can't actually violate the GPL. You infringe on the owner's copyrights if your actions don't fall in the GPL's allowed actions.
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.

Yeah, the crux of the issue would definitely be whether use of an API is prohibited by default under copyright law for a country (i.e. does using a library make something a derivative work of the library). In the US, at least, the Google v Oracle case makes me think this is worst case fair use (for many contexts) and best case too functional to be covered by copyright in the first place.

Though I can certainly imagine that a multinational company might not be confident of the copyright status of API usage in all countries they operate in.

I'd further argue that it would be important if your program does anything useful without the GPL parts; if so, you can probably argue that it is not a derivative work. If you however only build an extension to some GPL'ed software that fundamentally needs the GPL'ed code to properly function and cannot (easily) be used by any other software, then you probably will create a derivative work.