Post by Arne VajhøjPost by Simon ClubleyPost by Arne VajhøjInteresting question.
I hope VSI thought about that.
I've had another look at this and I don't immediately see how the options
below are viable ways to get GPL code into the VMS kernel without causing
at least some of the existing VMS kernel code to now fall until the GPL.
Post by Arne VajhøjI believe they can use two different approaches to work
* put in a layer between VMS and GFS2 - the "NVidia model"
The problem with this one is that the situation is reversed from the
Nvidia case. In the Nvidia case, Nvidia themselves own the code that
they want to stop from becoming GPL when it is inserted into a GPL kernel.
In the GFS2 case, VSI want to use pure GPL V2 code that they do not own
within a non-GPL kernel (the VMS kernel). This needs to happen in a way
that does not make the rest of the VMS kernel now fall until the GPL as
a result.
GPL does not operate with a caller/called concept - only on a
combined concept, so it should not matter for GPL.
Post by Simon ClubleyIf VSI are going down this path, they also need to get the owners of the
GFS2 code to agree that this is an acceptable use that is compatible with
the GPL.
Not necessarily.
If usage is good according to GPL the the authors permission is
not needed.
It is extremely unclear whether this use could ever be allowed under
the GPL, even with an interface, without requiring at least some of the
VMS code to be opened up under a GPL-compatible licence.
As such, it's not what the GPL says; it's what the owners of the GFS2
code _believe_ the GPL says that matters when they decide whether what
VSI are doing is acceptable.
Post by Arne VajhøjThere are obviously benefits from getting the permission though. If
FSF sue them and GFS2 people say they do not consider it a violation,
then the case would be a lot easier.
It would be a lot better however if VSI simply state upfront why they
believe they can integrate pure GPL code into the VMS kernel without
a problem. They might be planning something that makes the problem go
away or there might simply be an angle which has been missed so far.
Post by Arne VajhøjPost by Simon ClubleyPost by Arne Vajhøj* claim it is program and whatever parts of VMS it needs
fall under the system library exception in GPL
However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on) of
the operating system on which the executable runs, unless that component
itself accompanies the executable.
This one doesn't work because of the last bit. The VMS kernel will
accompany the GFS2 executables as part of the installation media
and GFS2 will be tied into the VMS kernel itself.
VSI-GFS2.PCSI
:-)
Not that simple. Have you looked at the VMS kernel internals ?
I've never seen the VMS source code, but it's clear from the I&DS
that the VMS kernel is a monolithic mass of closely bound code, at
least when compared to the clean interfaces and plug-in modules
that Linux has.
That approach also doesn't work if you ship VSI-GFS2.PCSI in the same
installation kit as the VMS installation kit even if VSI add a public
filesystem interface similar to that which Linux has.
There's also the very open question about what happens when a vendor
loads a GPL filesystem module into the VMS kernel using this new interface
when the same vendor supplies the operating system. Would this be seen
as a deliberate attempt to circumvent the requirements of the GPL ?
Post by Arne VajhøjPost by Simon ClubleyThe example I keep coming back to is that GNU Readline (which is pure GPL
and not LGPL) makes any program which uses it fall under a GPL-compatible
licence.
That is a very traditional library with no shim and no system
library exception and a general understanding in the industry that
linking with such a library is combining.
And that's why it's such a good example. For example (and I honestly
don't know the answer to this question) could you get around the
GNU Readline GPL requirements by placing all the GNU Readline code
into a .so module and then using dlopen() at runtime to map it into
the already running program ?
My feeling is to say I don't think so as that should be treated as a
deliberate attempt to get around the GPL requirements and the author
of the program would have written code to deliberately load GPL code
into their non-GPL program via dlopen().
That would appear to be similar to the same vendor supplying both the
operating system and the plug-in modules when the operating system is
designed to take advantage of the plug-in modules.
I would really like to see VSI's take on this. They may have a simple
and/or clever answer that allows them to do this without forcing at
least some of the VMS kernel code to go under a GPL-compatible licence.
Actually, after I wrote the above, I decided to have a look at the GPL
FAQ before posting and came across this:
https://www.gnu.org/licenses/gpl-faq.en.html#NFUseGPLPlugins
That would seem to support what I am saying in the above Readline example.
It would also seem to indirectly imply that parts of the VMS kernel
would become covered by the GPL when the same vendor provides the
operating system and the plug-in because VSI would be distributing
both the main program (the VMS kernel) and the plug-in (the GFS2
filesystem).
If you read the linked question here:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins
then I would argue that the VMS kernel and the GFS2 filesystem would
become a single combined program under that definition, especially when
you consider that the primary use for GFS2 is with VMS clustering,
which is tightly integrated into the VMS kernel.
It would be nice to hear from VSI about how they plan to integrate
GFS2 into VMS because they may have a plan that addresses all of the
above issues.
Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.