5

From Octave's FAQ,

Code written using Octave's native plug-in interface (also known as a .oct file) necessarily links with Octave internals and is considered a derivative work of Octave and therefore must be released under terms that are compatible with the GPL.

...

A program that embeds the Octave interpreter (e.g., by calling the "octave_main" function), or that calls functions from Octave's libraries (e.g., liboctinterp, liboctave, or libcruft) is considered a derivative work of Octave and therefore must be released under terms that are compatible with the GPL.

Here, 'terms that are compatible with the GPL' appears repeatedly.

At first, I thought that it can be any license in the list of GPL-compatible licenses. However, the part of "... is considered a derivative work of Octave and therefore must be released under terms that are compatible with the GPL" confuses me.

As far as I know, derivative work of GPLed one should follow GPL itself, not compatible one.

What are 'terms that are compatible with the GPL'?

4

This advice from the Octave project is in line with the GNU project's own FAQ:

You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program?

Not exactly. It means you must release your program under a license compatible with the GPL (more precisely, compatible with one or more GPL versions accepted by all the rest of the code in the combination that you link). The combination itself is then available under those GPL versions.

This FAQ item directly applies to your case, but doesn't fully answer your question by itself, so I'll explain further.

The GPL imposes a particular set of requirements on the distribution of derivative works. Importantly, a few of those requirements include:

  • downstream derivatives must, as a whole, be licensed under the GPL

  • the licensing terms of downstream derivatives may not impose any additional requirements beyond what is required by the GPL

So, your own creative work may be licensed under any terms that do not cause issue when they are "upgraded" to the terms of the GPL as part of the combined work (original GPL work + your work) that you distribute. In other words, you may license your work with terms that are a subset of the GPL terms.

Visually, we can show how the terms of your work (left) combine with the GPL terms of the original work (middle) to create the combined terms (right):

permissive subset fits inside GPL requirements, proprietary terms do not

In the case where your works is licensed under a subset of GPL terms, there is no issue complying with the requirement that the combined work be licensed under GPL terms. Your work's terms are GPL-compatible. In the second case, where your work is licensed under terms that are not a subset of GPL terms, some rogue term(s) will exist in conflict with the GPL's requirement that the combined work be licensed under the GPL, which cannot include any additional non-GPL terms.

5

There is a genuinely subtle point here. It's easy to misunderstand - I am on record myself around these parts misunderstanding it.

When you combine work of your own with an existing, copyrighted work, you create a new, combined thing: a derivative work. There are at least three licences involved in this: the licence on the original work, the licence on your work, and the licence on the derivative work. The derivative work must be seen through all three licences, and if any of them requires something that another forbids, you have a licence incompatibility.

In this case, one source work is Octave, which is under GPLv3. As you point out, this requires that the licence on any derivative work is GPLv3 (or, optionally, a later GPL). The derivative work must therefore be under GPLv3 or later.

But your work may be under any licence you like, as long as it doesn't conflict with the requirements of GPLv3 including the requirement that the licence covering the derivative work be GPLv3 (or later). That is what is meant by a licence's being compatible with GPLv3.

If your work is simply a set of changes to Octave, it won't make any sense for you to distribute them separately. But if your work were (say) a plugin "written using Octave's native plug-in interface", then it might stand as a work in its own right, and you could choose to distribute it on its own under eg Apache 2.0. Someone who received a copy of your work under those terms and re-combined it with Octave would still, of course, have to release that derivative work under GPLv3, as would you if you were to redistribute the derivative work. But someone who, say, received a copy of your work under Apache 2.0 and used it to create a standalone work in C would not be so obliged, and could release their combined work, including their changes, under eg Apache 2.0, if they so chose.

2

License compatibility means that code licensed under one license can also be used under another license. This is a bit confusing because this compatibility usually only goes in one direction: if A is compatible with B, that doesn't imply that B is compatible with A.

The GPL compatibility list you mentioned mostly discusses which licenses can can be changed to GPL, not which licenses the GPL can be changed to. The text and not the colour coding is relevant, in particular since the colour coding does not distinguish between different versions of the GPL (e.g. GPLv2 is not compatible with the GPLv3).

Licenses can be implicitly compatible. I can take software licensed under A and use it under the terms of license B if B doesn't given me any additional permissions that A doesn't include, and if by complying with the B license I also satisfy all requirements of the A license.

E.g. we can relicense software under the MIT license to the GPLv3. This is possible because the MIT license explicitly allows sublicensing, as long as the copyright+license notice is kept in tact. The GPLv3 allows you to require such notices to be kept intact by adding additional terms under 7.b), so this license transition is compatible.

The reverse is not true: you can't move from the GPL to the MIT license because the MIT license supports none of the terms of the GPL.

Licenses can also be made compatible explicitly by mentioning this in the source license. E.g. the GPLv3 explicitly allows software under the GPLv3 to be combined with AGPLv3 software. The GPLv3 is also compatible with later versions of the GPL iff the copyright holder “activates” this feature. This is the case for GNU Octave:

GNU Octave is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.

(from the GNU Octave README)

While the GPL does state that modified versions must be licensed under the GPL, we can use the GPL-licensed software under the terms of a compatible license and are then bound by that license instead.

So it seems there are three kinds of possible licenses for GNU Octave plugins or programs embedding GNU Octave:

  • keeping he GPLv3, which is the current license of GNU Octave.
  • using a later version of the GPL. As of 2017, no later version exists.
  • using the AGPLv3, though I don't think this is possible for plugins, only for programs embedding GNU Octave.

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.