GPL in ROM

At the risk of finding myself in the midst of any other flame-driven thread(!), I have a couple of questions to ask about the ROM images:

It was implied in a previous thread that GPL code could not be included in the IOMD ROM for RISC OS due to the issue of linking GPL with non-GPL code. Thinking about this for a bit, MAC OSX (which contains lots of GPL code) is distributed in ROM form (CD-ROM to be exact). Is there something specific about RISC OS that means it falls under different GPL clauses?

I’m guessing this has nothing to do with whether or not a ROM is used as the distribution medium, but more to do with the issue of relocatable modules which can be viewed as ‘linked’. Perhaps this means that GPL relocatable modules cannot be included in the ROM (but other unlinked sources are fine (such as a standalone application))? Although, isn’t this a moot-point since the shared C library is not open source and therefore it’s not possible to make a GPL’d relocatable module anyway?

is distributed in ROM form (CD-ROM to be exact)

<facepalm> CD-ROM != ROM. CD-ROM gets by on the “it is a filesystem” clause. Sure, you could burn a filesystem into a ROM and load from that, but that’s a mighty peculiar way to use a ROM. Especially since most would need some static code at the start to even get the system running, so is it really a filesystem?

Perhaps this means that GPL relocatable modules cannot be included in the ROM

No “perhaps” about it. A quarter century on and still the issue of what is and isn’t “linked” is unclear.

That said, a German court (IIRC) recently slapped this down saying that simply linking one piece of code to another did not create a “derivative work”. By virtue of the actual definition under copyright law, a derivative had to be derived from and contain a portion of (or what was a portion of) the original work. If it contained nothing of the original, then by definition it was not a derivative work.

but other unlinked sources are fine (such as a standalone application))?

Yes. A standalone application on a filesystem is acceptable. This is why the full SD image can contain NetSurf, StrongEd, and other GPL stuff; but the linked ROM image cannot contain any GPL.

Although, isn’t this a moot-point since the shared C library is not open source

The source is open and available, but it is not “open source” in the strict OSI definition.

and therefore it’s not possible to make a GPL’d relocatable module anyway?

What do you think UnixLib is?

You can make a GPL module. Users can load a GPL module. You just can’t have it built into the OS.

CD-ROM != ROM. CD-ROM gets by on the “it is a filesystem” clause.

I don’t see the distinction. Both can be used to boot a system, both are a BLOB of stuff which can be read and executed. How is a silicon ROM different from a CD-ROM apart from the access method to get at the information? If one is a filesystem then by definition so is the other?

What do you think UnixLib is?

Here I must be mistaken then; I read that you have to use the shared C library to make an RM. I must have found something outdated. If you can do it with UnixLib and GCC (make an RM that is) then my second question is answered (thanks!).

In terms of the differences between the structure of a ROM image and a filing system:

1. At its heart a ROM image is a very simple filing system – it’s just a list of modules, one after another. It’s trivial to write tools to split a ROM up into its constituent modules and put it back together again.
2. However, not all modules within the ROM image will have been built as position-independent code. Assembler modules generally are, but C modules are generally built for use at a fixed base address (mainly due to compiler limitations – for position-independent C code the binary needs to be modifiable so that the special “__RelocCode” function can fix up any absolute addresses that were emitted as part of the image). Although this places a practical barrier on what you can do with a ROM image filesystem-wise, I don’t think it actually has any great bearing on it in terms of GPL compatibility (after all, applications are linked against a fixed base address of &8000, and nobody’s complaining about that).
3. The one thing that might cause GPL issues is that the convention for C modules is for them to be staticly linked to the copy of the C library that’s held in ROM. This is only a one-way linkage (the C library doesn’t have a clue about the module that it’s linked to), but it’ll be enough to fall foul of the ‘no linking with non-GPL code’ rule.

So the different ways around that could be:

1. Don’t use the shared C library. I.e. use a different C library, or don’t use one at all.
2. If you are using the shared C library, use runtime linking and GPL-friendly stubs.

Exactly where the code is in the ROM image (e.g. as part of the module chain or as a file in ResourceFS) doesn’t really matter. You could even make a ROM which contains a GPL HAL, as the two aren’t really linked to each other (they just typically assume that the OS image comes straight after the HAL, much like how a PC BIOS assumes it can find a bootloader in the first sector of the hard disc).

Re the GPL HAL idea, read this then scratch your head in amazement: http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL

Hmm. Their definition of “system library” is confusing me:

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

In our case it’s pretty clear that most of the ROM modules are “major components”. The shared C library may or may not count as a “system library”:

• For requirement (a):
  • It is included in the normal form of packaging a major component (if you consider the ROM image to be the “package”)
  • But is the shared C library itself a major component? Many important ROM modules are dependent on it, but it is possible to produce a functional ROM without it, so it all depends on how major you consider major to be.
• For requirement (b):
  • The shared C library doesn’t “serve only to enable use of the work with that major component”, as it also has various utility functions (strlen, qsort, etc.)
  • However it does implement a fairly standard interface, and “an implementation” of that interface is available to the public in source form (all the CLib sources are available)

So depending on whether you consider the ROM to be a “package”, the shared C library may or may not be a system component, and therefore may or may not be inelligible for the requirement that the source be distributed. But if it is classed as a system component then we wouldn’t be able to use it anyway because we can’t provide system components alongside the programs that rely on them.

So the only way to include a GPL component in the ROM would be to only allow it to be linked to other GPL components.

I think the ‘system library’ part may not really be an issue… let me try to explain:

I don’t see any practical difference between the IOMD ROM and say, the OMAP4 image or (for arguments sake) a CD-ROM of RISC OS 5. They all contain the same(ish) thing but on different storage medium. The ability to just read or read/write doesn’t really count; the image is always static until it changes (either by re-writing an EPROM, or changing the contents of a hard-drive) – you can boot and boot even a harddrive without modifying the contents (servers do this all the time by booting from USB sticks and then mounting HDDs as R/W leaving the USB stick R/O). I also don’t think you can look at the ‘thickness’ or complexity of the boot-loader as an issue. On this point I’m pretty certain there is not barrier to including things in a physical ROM over any other bootable medium based on the license covering the source code. Just doesn’t make sense otherwise, Apple, Microsoft and others (including Ubuntu with it’s non-GPL code on the installation media (which you can run as a liveCD)) would all be breaking the GPL; which I don’t believe they are.

On the separate question of RMs, there I can see more of a complex issue. However, if you can create RMs using UnixLib and GCC you are only enforcing the fact that such RMs can only be used by other GPL’d code (which is good for the application I’m working on as that is exactly the case). To make this clear (and to help others avoid any licensing issues, perhaps there should be some form of suffix or prefix applied to the name of GPL RMs?). However there is no barrier to including GPL code (static or relocatable) in the IOMD ROM either.

I’ve looked at the text of the GPL and it seems pretty clear to me that GPL applications cannot use non-GPL RMs (the hard-coded SWIs which cause the library to accept parameters, process and return parameters is pretty clearly linking as far as I can see). However that only applies to the individual RMs. It has no overall effect on the legality of the ROM image IMHO.

(edit: In case it isn’t obvious… I think we (Jeffrey) are largely agreeing here; which is good)

I’ve looked at the text of the GPL and it seems pretty clear to me that GPL applications cannot use non-GPL RMs (the hard-coded SWIs which cause the library to accept parameters, process and return parameters is pretty clearly linking as far as I can see).

You consider a system call interface to be linking? If GPL code can’t syscall to non-GPL code, then how is it possible to run GPL code on any closed-source OS?

then how is it possible to run GPL code on any closed-source OS?

That’s the point. Closed source is supposed to be “unethical”, hence the GPL would rather you just…didn’t.

Just doesn’t make sense otherwise,

Can you explain, then, why the FAQ says you cannot legitimately install VB’s runtime DLLs with a GPL VB app? Surely the necessary runtime libraries are a major component of the language (won’t work without them, period) and wouldn’t an installer be counted as an aggragate anyway? The whole linking thing doesn’t make sense.

You consider a system call interface to be linking? If GPL code can’t syscall to non-GPL code, then how is it possible to run GPL code on any closed-source OS?

Ok, that’s a really good point and something I didn’t consider.

Can you explain, then, why the FAQ says you cannot legitimately install VB’s runtime DLLs with a GPL VB app? Surely the necessary runtime libraries are a major component of the language (won’t work without them, period) and wouldn’t an installer be counted as an aggragate anyway? The whole linking thing doesn’t make sense

Also a good point; so I went back and read the part of the GPL FAQ (at least I’m assuming this is what Rick is pointing to):

FAQ> You may link your program to these libraries, and distribute the compiled program to others. When you do this, the runtime libraries are “System Libraries” as GPLv3 defines them. That means that you don’t need to worry about including their source code with the program’s Corresponding Source. GPLv2 provides a similar exception in section 3.
You may not distribute these libraries in compiled DLL form with the program. To prevent unscrupulous distributors from trying to use the System Library exception as a loophole, the GPL says that libraries can only qualify as System Libraries as long as they’re not distributed with the program itself. If you distribute the DLLs with the program, they won’t be eligible for this exception anymore; then the only way to comply with the GPL would be to provide their source code, which you are unable to do.

I don’t read this quite the same way as you seem to Rick. This says that you can’t distribute non-GPL DLLs with GPL code… not “You can’t use non-GPL DLLs”. This is actually a blessing and a curse. It means that my GPL application can use any GPL’d RM and (even ‘better’) my GPL’d application can use any non-GPL’d RM which is part of the ROM image (since that is clearly the ‘system libraries’ in this case).

What I can’t do is distribute an non-GPL RM with my GPL application itself (which may be part of the ROM (the RM that is; not my application); but I could include my application in the HardDisc4 image (the HardDisc4 image isn’t required to run RISC OS (which is distributed as the ROM) so it isn’t covered by ‘system library’).

This, of course, requires you to equate RM = DLL, which, as they are equal in purpose, doesn’t seem like a dangerous assumption to me.

I would agree with Rick that the distinction between a ‘system’ and any other bit of code is a vague one… I argued that above myself; but, based on precedence (such as, say, the Windows .Net DLLs, it seems to me we are on safe ground writing GPL code and dynamically linking to the Shared C Library (for example).

So this is a much better situation than I initially thought.

That’s the point. Closed source is supposed to be “unethical”, hence the GPL would rather you just…didn’t.

Again, this is an interested interpretation of the GPL FAQ:

FAQ> It is possible to write free programs that only run on Windows, but it is not a good idea. These programs would be “trapped” by Windows, and therefore contribute zero to the Free World.

To me what they are saying is “if you write GPL code for a closed source OS you have less assurance that others will have the right to use it as the GPL intends since the license to the OS can be changed/removed which, in turn, will prevent useful access to your application and it’s code (which is also tied (via DLLs) to access to the OS)” – it’s not really a direct question of ethics, but pretty good advice imho.

but pretty good advice imho.

You know, the more I read, the more I’m convinced about the GPL.

Best avoided and use a different Open Source licence. One with less “attitude”

You know, the more I read, the more I’m convinced about the GPL. Best avoided and use a different Open Source licence. One with less “attitude”

That’s a matter of personal preference and you’re welcome to your opinion; but that isn’t the point of my OP. I wanted to better understand how to contribute to RISC OS whist using a GPL license (my code – my preference).

My take-aways/conclusions for this discussion are a few points:

1) The RISC OS ‘ROM’ can contain GPL code both in form of applications (provided they don’t use any non-GPL RM in the ROM) and in the form of RMs (provided they do not use a closed library which is included in the ROM such as the Shared C library).

2) It’s more useful to think of the ‘ROM’ as a distribution, since it really isn’t limited to a physical medium – this helps a lot with the interpretation of the GPL (the same goes for the HardDisc4 image).

3) A GPL application can make use of both GPL RMs and non-GPL RMs. The proviso is that the application and any non-GPL RM are not in the same distribution. You have to get them separately.

4)The ‘HardDisc4’ image and the ROM image are separate distributions. Therefore it is better to put general purpose RMs (both GPL and non-GPL) in the ROM and applications in the HardDisc4 image – this makes sense anyway from a structural point-of-view.

This is a much better view than I had of the situation to begin with :)

The RISC OS ‘ROM’ can contain GPL code […] in the form of RMs […]

No, I pretty much think that GPL code actually in the ROM image itself is going to be a problem.
Sorry, we’re not touching that with a barge pole…

http://gerph.org/riscos/ramble/32bit.html#Background_CastleGPLviolation

The RISC OS ‘ROM’ can contain GPL code both in form of applications (provided they don’t use any non-GPL RM in the ROM)

There’s your biggest hurdle. Check what the system does, if anything, without using one or more of the many (all non-GPL) modules.

Working with the interpretation of GPL you’ve given you would need to distribute your code separate from the ROM. Probably separate from the HardDisc distribution too.

Rick> That link points to a specific violation where GPL code was integrated and the resulting code not supplied back (He even says in the article “They denied that there was any such source there”); I’m not sure what relevance it has to my conclusions. I’m not talking about kernel or core things specifically. Just the fact that you can put GPL RMs and GPL applications in the ROM and still be in line with the GPL. I’m not sure who is the royal “we” in your reply. You don’t like GPL – I get it! But that doesn’t mean you get to be the single point of decision making does it?

Steve> At the very least there is no good reason why GPL RMs cannot be included in the ROM distribution image. I can see that one could argue that applications are more tricky (and I think they are better suited to the HardDisc4 distribution anyway).

Overall I would state that you have to remember that the GPL is designed to prevent closed-source authors from misusing open-source code – not the other way around. I’d agree some clauses make it tricky for open-source authors (as is probably necessary) but that’s about it. No one in their right mind is going to legally hunt-down an open source author for providing code (who would fund it?)… Closed source authors misusing open-source is another matter altogether.

Yes you can try use a very negative interpretation of GPL to create FUD about what GPL authors can do (which seems to be Rick’s aim) but in reality the situation isn’t as dire for me as a GPL author nor does it hinder contributions to the ROM or Harddisc4 image in any significant manner (since a GPL author will always use other GPL libraries if available).

I’m not talking about kernel or core things specifically.

Well that’s pretty much all of the ROM content eliminated from the discussion.

Steve> At the very least there is no good reason why GPL RMs cannot be included in the ROM distribution image.

If it isn’t linking to the modules in the ROM (because the GPL seems to forbid that) the point of squeezing it into the limited space is just what exactly?

Isn’t it a better idea to licence the code with a compatible licence and use the facilities in those existing modules rather than re-inventing the wheel?¹²
Various people have pointed at suitable items. A quick scan of the source tree will show you two such sitting alongside the castle elements.

¹ This is the core philosophy of RISC OS – shared facilities in modules that are the OS and further modules to extend it.

² Of course should you re-invent and produce a better wheel then you need to make sure the use terms remain the same as before so that the new version can sit in the same place as the old.

Well that’s pretty much all of the ROM content eliminated from the discussion.

So, you consider the ROM as kernel/core rather than a distribution? It might not have more general RMs in it at the moment (I can’t believe this is true though), but there is no rule stating that it shouldn’t have?

If it isn’t linking to the modules in the ROM (because the GPL seems to forbid that) the point of squeezing it into the limited space is just what exactly?

Ok, ignoring the ‘answer a question with a question’ we can agree that there is no reason (because of the GPL license) why GPL RMs cannot be included in the ROM distribution?

Isn’t it a better idea to licence the code with a compatible licence

Yes I agree, but the suggestion to license RISC OS as GPL was met with a flat rejection :)

Of course should you re-invent and produce a better wheel then you need to make sure the use terms remain the same as before so that the new version can sit in the same place as the old.

Why? If it’s better – it’s better. There is no golden rule stating that something not backwardly compatible with an older version of RISC OS is not ‘better’. Otherwise why can’t I run RISC OS 5 on my A440/1?

I’m really just trying to find ways GPL authors can contribute without breaking GPL. But the attitude seems to be to find reasons why they can’t. I’m puzzled, but I still think my 4 conclusions are valid.

But that doesn’t mean you get to be the single point of decision making does it?

No. And right back at you. ;-)

“They denied that there was any such source there”

Interesting you quote that part when he goes on to demonstrate that there probably was.

Here, I’ll help you. It’s this part: so I went and asked Castle for a copy of the source to RISC OS under the terms of the GPL

Note that he didn’t ask for the HAL source, he asked for the source to RISC OS.
Note that this situation has arisen because GNU, FSF, and RMS all fail to clearly specify the exact terms, preferring to leave it to judges to make the decisions. This is fine for people that totally buy in to the GPL ethos, but it is a nightmare for people working with non-GPL code.

Also while you can choose to dismiss my (legitimate) concerns as mere FUD, you can’t handwave the concerns themselves.

Also while you can choose to dismiss my (legitimate) concerns as mere FUD, you can’t handwave the concerns themselves.

Hence my OP. This is me, taking the time, to check what is and isn’t possible.

Here, I’ll help you. It’s this part: so I went and asked Castle for a copy of the source to RISC OS under the terms of the GPL

But the RISC OS source is now available; so I can go and look at it now. Source code is already available = your point is moot?

That was then, this is now. Since you can access the source and verify if the terms of the GPL are violated (which you couldn’t before) I still see no reason why my conclusions aren’t valid. How does this put the ROM at risk?

If I (or others) would like to contribute GPL code to RISC OS (core/kernel/app/whatever), why do you reject even the idea of such contribution?

Obviously your are too overwhelmed with contributions to have the time or?

“Isn’t it a better idea to licence the code with a compatible licence”

Yes I agree, but the suggestion to license RISC OS as GPL was met with a flat rejection :)

That was almost witty. :)
However, most schemes are compatible with each other and a mix of closed and open source. GPL seems to be the one out of step. From some of the FAQ answers deliberately so.

“Of course should you re-invent and produce a better wheel then you need to make sure the use terms remain the same as before so that the new version can sit in the same place as the old.”

Why? If it’s better – it’s better. There is no golden rule stating that something not backwardly compatible with an older version of RISC OS is not ‘better’.

That seems to be something of a non-sequitur. We were talking about adding alongside existing or replacing existing sub-items in existing major items.

Of course, if you believe that a component like for example the HAL could be re-written better and more able to adapt to multiple hardware platform variants you could have a go.
It’s not like anyone did that in GPL form before.

Otherwise why can’t I run RISC OS 5 on my A440/1?

Apart from a the hardware not handling the firmware?
I’ve been trying to figure out why my old portable TV can’t receive TV these days.
Someone said maybe a upgrade of the flash via the USB port but apart from the coax and digital RGB input socket I can’t find any sockets. :)

If I (or others) would like to contribute GPL code to RISC OS (core/kernel/app/whatever), why do you reject even the idea of such contribution?

All contributions are welcome provided the source can be licenced in a way that is compatible with the existing source, while noting that the existing source has multiple copyright owners. The existence of those rights and elements of closed source is just a simple fact, it isn’t an argument it just is.
It exists, the elephant sits in the room, ignore it if you wish but everyone else can see it.

That was almost witty. :)

Thanks, I do try!

Anyway, I think I have my answers here and I guess I just have to accept (again) that GPL is disliked for a few tangible reasons and many more reasons which are difficult to quantify within this forum (with the notable exception of Jeffery, who seems to be more open-minded on the subject).

From my application’s point of view; I really wanted to use an RM as part of it. Now, I’m satisfied that I can since both the application and the RM can be GPL’d. I’d still like to do some USB work though; but, given the overall ethos, it’s more trouble than it’s worth since the GPL code would be treated as the RISC OS equivalent of Ebola :)

Thanks all for the replies!

It’s easy:
1/ ROM is seen as a single file: you can’t put GPL code inside it.
2/ ROM is seen as an archive, with its own fileystem: you can put GPL code inside it.

From my application’s point of view; I really wanted to use an RM as part of it. Now, I’m satisfied that I can since both the application and the RM can be GPL’d.

NetSurf.
Proves that a GPL application with modules (distributed with it) can be written for RISC OS.
Chance of adding it to the ROM = extremely close to zero.

Now find someone who uses RO5.2x that doesn’t use NetSurf as a browser (they exist but in fewer numbers than those that do)

In short, you have looked at things from the wrong angle. Not everything has to be in the ROM or HardDisc distributions, which is sort of where the GPL hints is OK.

Hence my OP. This is me, taking the time, to check what is and isn’t possible.

Can we construe that this is you offering legal advice – that you are stating that including GPL code within the ROM is not a GPL violation?
Here’s a thought – why don’t you point FSF at this thread and see if they have any input on this situation?

That was then, this is now. Since you can access the source and verify if the terms of the GPL are violated (which you couldn’t before) I still see no reason why my conclusions aren’t valid.

I repeat again – he asked for a copy of the RISC OS sourcecode. Not a part. Justin is an extremely talented person. Not only did he recognise likely GPL code by looking at the disassembly (I doubt many people would be capable of that), he would also have known which parts of the system were affected.
I believe, but may be wrong, that it was part of the HAL.

How does this put the ROM at risk?

Because including GPL code in the ROM may be an infringement. It is fine if you wish to build a ROM with GPL code within, as the fallout would be your problem. For the people related to the company holding partial rights over the source, such a thing could be catastrophic.

If I (or others) would like to contribute GPL code to RISC OS (core/kernel/app/whatever), why do you reject even the idea of such contribution?

I would like to think of more contributions to RISC OS. For starters, our video media capabilities suck, which is depressing on a platform as media-agile as the Pi is.
It isn’t because we don’t want contributions. It is because we don’t want RISC OS to end up in the middle of a war over whether or not including something GPL “requires” it to be GPL. We’ve been there before.
And, frankly I am surprised at your assertion that a ROM is the same as a CD-ROM. If that’s the logic we are using to determine whether or not GPL within the ROM image is acceptable, you’ll have to excuse me if I am not convinced.

Yes, there was more “royal we” there. If you like, replace “we” with “I” and I invite any of ROOL’s members to correct me if they feel that I have spoken out of turn – the platform needs contributions, it doesn’t need something that could damage it.

Someone said maybe a upgrade of the flash via the USB port but apart from the coax and digital RGB input socket I can’t find any sockets. :)

ROTFL!

Your TV is newer than mine. I needed to use the VCR to convert RGB and CVBS into UHF.

From my application’s point of view; I really wanted to use an RM as part of it. Now, I’m satisfied that I can since both the application and the RM can be GPL’d.

Yes. How many times have we pointed you to NetSurf already? It is GPL. I would assume the helper modules are GPL. I’m going by what it says on the website as – so far – I have found no indication in the installation or the on-screen information that suggests that it is GPL (which is weird, but there you go…).

given the overall ethos, it’s more trouble than it’s worth since the GPL code would be treated as the RISC OS equivalent of Ebola :)

As Steve said, it is GPL that is out of step with the other licences that comprise the RISC OS source code. If you wanted to do some USB work and it was original code, you could consider something like CDDL which is nicely open source (in the OSI fashion) without the hangups that cause us problems?