3 ms·
> The typical understanding of the industry is essentially a process boundary, I agree that this is the typical thinking but I've always found it a little sill
by radarsat1 6y ago
> The typical understanding of the industry is essentially a process boundary,
I agree that this is the typical thinking but I've always found it a little silly and arbitrary. It implies that if I write a GPL-licensed library and release it along with a thin wrapper program that gives it a command-line interface, say it does something like a complicated calculation which reads some data and outputs a single number; then someone could come along and write a program that would not work without it, say something that transforms another input format and then passes it to my calculation. As long as that program calls my "library" as a "program" (using "system()" for example) then they are not bound by the GPL, but if they link to my library and call the calculation directly, then all of a sudden they are?
This linking vs. process boundary thing always seemed like the wrong way to determine if a program is a derivative work of another. If someone writes a program that does not work without the GPL code, they should be bound by the GPL, regardless of whether it's linked, loaded into the same process, called through the command line, or over the wire.
This last one would obviously be controversial, but frankly a lot of companies do hide their use of open source code behind a REST API, and avoid adhering to any particular licenses that way, since they are not "distributing" the software.
- spijdar 6y agoThat goes beyond what most people consider the GPL to cover. There are other licenses with stronger copylefts specifically to cover that last case -- notably, the AGPL. I suspect trying to make the case that GPL's viral copyleft isn't limited to strictly linking but potentially any interaction with it would probably have a chilling effect on the use of GPL code, and this reinterpretation would only reinforce some people's prejudice against the GPL, a la Ballmer's "Linux is cancer" line. Maybe it's the pragmatism in me, but I think it would have a net negative effect long term, unless it managed to flip all of the tables and convince everyone to use all GPL code, instead of making people reject copyleft wholesale.
- radarsat1 6y ago> potentially any interaction with it But that's not what I said. I said programs that do not work without some other program, is, in my opinion, a derivative work. I just don't see how the calling mechanism even plays into that judgement. I do agree that there are other licenses such as the AGPL that try to cover these cases. And arguably the online thing is a whole different ball of wax, because you can talk about software using a service, etc. It really is tricky in that case. But I don't see the reason to distinguish between calling a function via the C stdcall mechanism, vs. "popen" and capturing stdout. It's exactly the same, logically, the only difference are details that imho should not matter for the legal case. Right now, if I release a GPL library, what stops someone from coming along and writing a CLI program that just wraps every function with some textual interface, and including that with their closed-source program? The GPL becomes pretty toothless if it's bypassed so easily.
- qchris 6y agoI'm under the impression that's what the Remote Network Interaction clause of the the Affero GPL license is supposed to do. The "boundary" is then if someone is interacting with the AGPL code at all, so when you use the AGPL-licensed code behind a REST API, even if that's on someone else's server, the use of that code in producing any response to the API request requires publishing the AGPL'ed code/modifications.
- Dylan16807 6y ago> If someone writes a program that does not work without the GPL code, they should be bound by the GPL, regardless of whether it's linked, loaded into the same process, called through the command line, or over the wire. Let's say I'm writing a refinery simulator to sell to people, and I use a GPL command line utility to do some particular calculation about flow rates. Now I'm GPL just for outsourcing a single equation. But only because that's the only program around for doing that calculation. As soon as someone else reads a paper on the subject and makes an alternate program for that math, my program is no longer GPL? Those consequences sound like a mess I don't want to deal with.
- radarsat1 6y ago> Now I'm GPL just for outsourcing a single equation. But only because that's the only program around for doing that calculation. As soon as someone else reads a paper on the subject and makes an alternate program for that math, my program is no longer GPL? I don't really see the problem. You are saying that if you change your dependency to a non-GPL program, then you are no longer GPL. The answer to your question is simply "yes". We are not talking about patents here, but copyright. If someone comes up with an alternative implementation with a different license, you are perfectly free to start using it instead, what's the issue?
- Dylan16807 6y ago> if you change your dependency Depends on what you mean by changing the dependency. Let me lay out the scenario in more detail. The program is still exactly the same. It asks to be pointed at a fluid sim program, and then uses that for some of the math it needs. When it was coded, the only dependency it could use was GPL. Now there's a new non-GPL dependency it could be pointed at, with the same API. Now it's possible to run the program without using any GPL code. Does that make the program no longer GPL, even though it didn't change?
- radarsat1 6y agoI see your point now. I'll answer with my own hypothetical. If I write a program that dynamically links a library performing the same GPL'd fluid sim calculations, it is presumably forced to be GPL, because it links to it. What if someone comes along and runs the program but at runtime uses LD_PRELOAD to override the dynamic linker, linking it to an alternative library that presents the same interface. Is the program still required to be GPL? I don't really have an answer to your specific proposed loophole, it's pretty clever and is a very good question; but I don't think the calling mechanism is part of the issue. You could make the same argument whether you are talking about a "program" or a library. The calling convention is a meaningless detail imho. I think you are specifically responding to my "does not work without" interpretation overly literally. Clearly if the program is written for and tested against a specific interface of a GPL'd program, it is intended to work with that program. On the other hand if it's written to call into some kind of standard interface, it no longer requires that GPL program specifically, but could work with any program implementing that interface. And I will admit that whether a program is written only to work with a GPL program/library/whatever, or is more general, may be up to interpretation, what is considered "standard", etc., but that is exactly my point -- law is nuanced. If it were possible to codify laws perfectly with overly simple rules like "the copyright applies because it's a DLL and not a program", then we wouldn't need lawyers. In law, intent is important. If I write a non-GPL program that depends on the functionality of a GPL library, I can go find all sorts of ways to not "link" to it but still use it, e.g., as a program, a service, etc. -- and it happens -- but the intent, which was to find a way to use GPL software without adhering to its license, is still quite clear.