1

Suppose a developer receives software from XX with a license permitting unlimited modification and redistribution as well as full ownership of any original content. The only restriction being no selling/monetizing anything which packages XX's code.

So that other developers could build off of the functionality of XX’s code without packaging it and becoming limited in their commercial usage, this developer creates a wrapper for indirectly interfacing with XX's software and distributes it with a GNU GPLv3 license.

Downstream users now have GPL licensed software containing XX’s code. If they fork it, the GPL which comes with the software would indicate that they could sell their fork for a price. However, XX’s software license (while not requiring that the license itself it be transmitted with the software) still asserts that selling content containing their code is forbidden.

My understanding is that this is effectively an "inferred" dual license, since the developer of the interface cannot simply re-license XX’s code under the GPL which permits commercial usage.

Since the GPL allows commercial usage and XX’s code does not, and since the GPL forbids "further restrictions" not permitted by section 7’s a—f, I believe the two licenses are incompatible, and thus downstream conveyers of the software must choose one license or the other to adopt for their derivatives.

Is this correct?

If my understanding of dual licensing is correct; then if they choose to create and distribute a derivative containing XX’s code, they MUST adopt XX’s license and not the GPL. However, if they choose to create and distribute a derivative not containing XX’s code, they have the option of adopting either the GPL or XX’s license.

Have I erred in this conclusion?

  • 2
    What you describe is not dual licensing. Dual licensing is when a developer owns some software and makes the same software available alternatively under different models. A common combination is GPL and so-called "commercial" (i.e. you need to pay for the "commercial" license if you don't want to abide by the GPL requirements). – Brandin Feb 1 at 11:27
  • In this case, the developer owns the wrapper that they’re adding to XX’s code. Could it not be argued that they’re making that software available under XX’s license or the GPL, where XX’s license is required if the derivative also contains XX’s code? – justis Feb 2 at 0:25
  • It's impossible to say with the information. Maybe XX gave the developer of the GPL component permission to distribute that portion of XX software under the GPL. – Brandin Feb 2 at 6:54
5

The problem is in the line

this developer creates a wrapper for indirectly interfacing with XX's software and distributes it with a GNU GPLv3 license

You gloss over the details of this wrapper, which hides the problem. Either this wrapper is tightly-linked to the XX software, or it isn't.

If it's loosely-linked, the two works are "merely aggregated" within the meaning of the GPL. XX remains under its non-free licence, the wrapper under GPLv3. The works can be distributed together, there is no contradiction.

If the wrapper is tightly-linked to the XX software, then the result is a derivative work of both. GPLv3 requires the work to be under GPLv3, the XX licence (if I understand you correctly) requires the work to be under the XX licence. It is not possible to distribute this work without violating at least one of these terms, and as a result, the work may not be distributed. Still no contradiction, since nobody else will ever see a copy of this chimera.

| improve this answer | |
  • Hey again. It’s definitely a tightly linked chimera. However, it is nonetheless being distributed by the developer under the GPL and both the developer and XX seem to see no problem with that. All to my frustration, because as long as they remain apathetic, the problem will stay unresolved. This is besides the point though. – justis Feb 1 at 3:45
  • More importantly you state "then the result is a derivative work of both". However, this language strikes false to me. The result is only a derivative of XX, the wrapper isn’t "a derivative" of itself. The result is effectively a fork of XX that has been offered up with a GPL. Wouldn’t that be considered a duel license? Not all downstream works will contain XX’s code, so providing the GPL as a licensing option for derivative works not needing to contain XX’s code isn’t unreasonable. – justis Feb 1 at 3:56
  • 1
    @justis no, the resulting work is a derivative of both XX and the newly-written wrapper code. Both parties have a copyright interest in it. – MadHatter Feb 1 at 7:27
  • 2
    You didn't say the wrapper was original code. You are right that the author of the wrapper can distribute it under any terms (s)he chooses. Nevertheless, if that author says "I am distributing this combined work under GPLv3" they are simply mistaken, because they have no permission to do that (similar to if (s)he said "anyone who gets this code gets £10 from the Bank of England" - they can say it all they like, but that doesn't make it true). Most sensible people, seeing this, would conclude that the rights position of the combined work was unclear, and not touch it with a barge pole. – MadHatter Feb 1 at 7:45
  • 1
    "both the developer and XX seem to see no problem with [a possible GPL violation]" - It's also possible that the developer and XX have a separate agreement as to whether this combination counts as a derivative work. Without it going to court, there's probably no way to tell, and if the developer is happy with things as they are, it won't go to court. – Brandin Feb 1 at 11:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.