Rick's b.log - 2015/09/02
It is the 24th of November 2024 You are 3.135.184.195, pleased to meet you!

What exactly is the GPL linkage requirement?

This question has arisen because Jess Hampshire on the ROOL forums asks if it is valid for GPL software to exist within ResourceFS in a RISC OS ROM image.

Before we start (and there may be people who only read as far as "ROM image"), I should explain. RISC OS has a concept of "image" filing systems. These look and feel like real filing systems, but can be completely fake. For example, the popular SparkFS software presents zip files as if they were regular directories in the filesystem. DOSFS does the same thing with files containing FAT volumes (indeed, the Pi's FAT boot "partition" appears within the directory $.!Boot.Loader). The RAMdisc is a more complete virtual filing system in that it appears as a separate device instead of a directory within an existing filesystem. It does, however, look and feel exactly like a real filing system. This behaviour is analogous to A:, C:, and E: in DOS - where the devices are floppy, harddisc, and CD-ROM.
Which brings us to ResourceFS. It is a prebuilt filing system containing "resources" (internationalised messages, templates (form definitions) for the standard UI elements, the default fonts, etc etc. All of the files within ResourceFS are assembled as the ROM is built (though modules can also add to ResourceFS as they are initialised). The programs within ResourceFS (basic network diagnostics may be found if you look) are not statically linked to CLib or anything like that as they are regular "files". But all of this is wrapped up in a big wodge of binary that is the RISC OS ROM image.

Would it be acceptable for a GPL program to reside within ResourceFS?

Unfortunately the text of the GPL itself is not particularly clear on this point. The crux of the matter is section five of the GPL(v3) which says the following:
Note that people are supposed to reproduce entire unmodified copies of the text of the GPL, but it is hard to critique specific parts if it would require presenting twelve screenfuls of text in order to do so. As I am making reference to the GPL itself instead of giving it as the licence for something else, I am going to quote only the pertinent part. You can read the entire text yourself if you feel so inclined.

5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

• a) The work must carry prominent notices stating that you modified it, and giving a relevant date.
• b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”.
• c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
• d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

Things look like they will be okay, if you read the final part of section five. The example GPL program is on a storage/distribution medium ("medium" here is not described, so one could assume that being a part of a filesystem would count) so surely the inclusion of it within RISC OS would be acceptable?

Ah, but wait. There's this: You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.

Excuse me... aren't these two clauses contradictory? On one side the GPL is saying that "if it is a file on a storage medium then it is okay" and on the other side it is saying that the GPL applies to the entire work and its parts regardless of how they are packaged. Well? Can't you argue that an ISO image is a way of packaging a filesystem? Can't you argue that those firmware updates that routers [sometimes|rarely] receive are just a way of packaging the software? Aren't these clauses contradictory?

I raise this point on various fora when there is an argument discussion about the greatness lunacy of the GPL, and I am told that either I am misinterpreting it and don't know what I'm talking about, or the following discussion omits any mention whatsoever of the issue. I challenged David Feugey to provide an authoritative reply as to whether or not it would be acceptable to place a GPL program within ResourceFS in a non-GPL ROM image. Predictably enough, he never replied to that. I won't hold it against him, nobody else would be willing to state an opinion and take responsibility for it. Because when you get down to it, the whole issue is FUD, hype, and gibberish.

Let's look at it another way. I am a programmer, not a lawyer. If I am going to pick a licence, I don't want to know it is a good licence because Richard Stallman says so. I want to read and understand it and for every part to be clear. The GPL is anything but clear on this point.
Thankfully I live in a part of the world where the accepted terms of the licence are exactly that which is stated in the licence. I feel sorry for Americans as a judge can choose to refer to the numerous examples that are the GNU GPL FAQ in order to determine the "intent" of the licence. In other words, all that stuff may influence the decision. Over here in Europe, if it isn't specified in the licence, it doesn't fly. You simply can't be held to terms (explicit or inferred) that are from elsewhere.

While the GPL started out with laudable aims, I find it amusing that a licence that is supposed to promote "freedom" and open source and the ability of us all to hack at it is now one of the more restricted (so-called) "open" licences around. Not only is the GPL incompatible with almost every other licence^(note), it is incompatible with itself - you can't mix GPLv2 only code with GPLv3 code. But not only that, the licence is now encumbered with a wish for the user to be provided with encryption keys for installers and encoded materials if necessary for the recompilation/reuse of the source code (re. Canonical/UEFI), plus more - the anti-TIVOization, and some guff about patents (irrelevant in Europe...for now...). It isn't a licence so much as a manifesto masquerading as a licence.

All the way through this, and having read the entire GPLv3 several times and the FAQ, the only thing that I can come up with is that any GPL program running on RISC OS that uses a third-party (not built into RISC OS's ROM) module may need to include specific permission for the software to be used with non GPL library code. But, again, it is very unclear as RISC OS neither looks nor feels like Linux. Is a module a library? Is a SWI call akin to calling a library function?
At any rate, I am no closer to answering this riddle than I was when I began. My personal advice would be either to use a different licence (if it is Jess' code) or to look for a non-GPL alternative (if he wants to port something). So far the entirety of RISC OS (OS source) is a GPL free zone. There's a reason for that.

Note - the FSF's list of "compatible" licences really means those that support the code being relicenced as GPL - and it is worth noting the two-step route that GNU suggests that you should take in order to make EUPL licenced code compatible with GPLv3 (as v3 is not a defined 'compatible' licence in the EUPL). This, more than anything else, hints at the morality of the GPL crowd. To take something released under a free and multiply-compatible licence and assimilate it as part of the GPL collective where it will become GPL-only. This is technically permitted, as the licence allows it. But the software afterwards? It isn't free. It is GPL. There's a world of difference.

Your comments:

The Revelator, 3rd September 2015, 12:33

Just like you said. You aren't a lawyer, you don't understand what the free software movement is about. You're just spreading rubbish and lies like all the rest.

Rick, 3rd September 2015, 21:42

Thank you Revaltor for pointing out the obvious. You might be taken with your Messianic Leader, but the basic fact of the matter is that I shouldn't NEED to be a lawyer in order to understand the nuances of a licence. What is, and is not, acceptable should be clearly written. I'm not going to repeat myself, my argument is as written above.  Actually, yes, I do understand what free software is about. I'm just having trouble understanding FSF's narrow definition of it; the definition where numerous licences are compatible with the GPL but the GPL is compatible with ONLY ONE (and it's another FSF licence); not to mention that GPL is incompatible with itself between versions. Is this REALLY your preferred definition of "free"?