GPL in ROM

Just to clarify for Simon, I would love if the GPL was not a problem to RISC OS and the ROM image. It would be one headache we don’t need to worry about.
The problem is not whether or not we can supply source to fulfil the GPL conditions – provision of source is not a problem. The problem is what is rightfully nothing to do with the GPL that the GPL tries to lay a claim to…

Ok, you got me; I have to reply to this one:

And, frankly I am surprised at your assertion that a ROM is the same as a CD-ROM.

One distribution medium for the OS is the same as another; Frankly I’m quite surprised that you think that the physical storage medium does make a difference from the perspective of a license agreement. If I print the source code on the back of a zebra and mail it to you via motorcycle courier (who would be dressed as a clown of course), will it mean I can reinterpret the Castle not-so-shared source license or GPL?

Ok, I kid. How about I convince ROOL to only supply the ROM as writeable EEPROM image in an ISO 9660 CD-ROM image on a DAT tape? License problem solved or altered in any way?

The physical ROM is not a special case, no way, no how.

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

You’re right

Item 1: “The argument Castle offered was that of semantics – that the code was in the section of the OS called the HAL” para 10 of the section headed “Castle GPL violation”

Item 2: All Iyonix owners were sent a CD with the source – I have the CD somewhere.

Castle rewrote the HAL to remove the need to distribute the source and quieten the grumbling.

As Steve said, it is GPL that is out of step with the other licences that comprise the RISC OS source code.

and

The problem is what is rightfully nothing to do with the GPL that the GPL tries to lay a claim to…

There’s this picture in my mind of a GPL labelled humanoid figure goose-stepping through the source tree while his minions stuff code into metal-strapped chests labelled “ship to sudetenland”.¹ :)

¹ It’s exaggerated for humour

How dare those nasty GNU people write a license that attempts to give everyone as much free access to as much source code as possible! Despicable behaviour! What will they want next? Freedom of speech? Boy-o-boy. Bring back the good ol’ days eh? – This forum post is shareware; if you read it more than once, please send me 5 quid.

(also exaggerated for humour :o)

How dare those nasty GNU people write a license that attempts to give everyone as much free access to as much source code as possible!

Can I come round and help myself to all serviceable white goods you have?
It’s OK, I’ve got a note from my mum and signed by friends that says I can.

This forum post is shareware; if you read it more than once, please send me 5 quid.

Comment acquired under permission in me mums note. :o)

Can I come round and help myself to all serviceable white goods you have?

Nope, that would be theft: I had it, you took it, now I don’t have it. My GPL source code you are welcome to copy though: I have it, you copied it, now we both have it.

If you (or your mum) really need a washing machine though, you are welcome to knock on the door and collect one in person. I’m at home – in Sweden ;)

Zyxt

A gift.

I have it, you copied it, now we both have it.

I think Simon’s offering his credit cards.

Let me break it down for you into musical fun:

https://www.youtube.com/watch?v=IeTybKL1pM4

:)

https://www.youtube.com/watch?v=IeTybKL1pM4

Ah, so I can copy your credit cards :o)

I thought it was a washing machine you wanted. A copy of my credit card won’t get you far… not unless you can duplicate someone else’s credit on it ;)

“How dare those nasty GNU people write a license that attempts to give everyone as much free access to as much source code as possible, including source code that wasn’t necessarily intended to be free, has nothing to do with the GPL code other than proximity, and goes by an ethically dubious reinterpretation of “derivative” that (contrary to all copyright laws known to man) can apply “derivative” to code that was neither derived from nor directly related to the GPL code."

There. FTFY.

Simon, please understand something extremely important.

In a “free”¹ world with “free” source code where everything is “free”, the GPL works well. GPL code happily co-exists with other GPL code, and the evidence is a complete and fairly feature-laden operating system. I would hazard a guess that an Ubuntu or Mint (pick distro of choice) system can do pretty much everything that an average Windows system can do. You may not (yet?) have software for specialist purposes or systems, but from the point of view of a reasonably smart home user or a small office, what I have seen of various types of Linux has compared to Windows.
In fact, I’m not so keen on Windows 7 and I absolutely detest the way Windows 8 behaves (playing with it in a shop). Given that I am currently running XP and given that my hardware (TV tuner, etc) is unlikely to be supported under 7 or 8, the basic truth is that unless Windows 10 manages to be something special, there will not be anything specific that ties me to using Windows. I could make the move to Linux. When I have some desk space to get that P4 machine running, I will try a few distros to see what they are like.
There is no doubt that in the right sorts of ways, GPL is useful and has served a purpose.

The problem is, some of the more dubious parts of the GPL are irrelevant when you are co-existing GPL code with other GPL code. Unfortunately, these things become exceedingly important when dealing with the world outside of the GPL “free” world. In these situations, the complexities and the vagueness coupled with the implicit threat of “contamination” of non-GPL code² (or just the potential for legal hassles trying to sort it out) … it does not play well with commercial code³, does not play well with proprietary systems^{4 5}, does not play well with those trying to make money from their software⁶, does not play well with App Stores⁷, and does not play well with other software released under most of the other open source (as in the OSI definition) licences⁸. Goodness, GPL (v3) is not even compatible with GPL (v2). It is possible that, technically, it is a violation of using/linking any GPLv3 code with the Linux kernel (which intentionally remains GPLv2).⁹

This is the potential problem for RISC OS. The OS, theoretically, being GPL is not a problem if we only look at it from a GPL perspective. If we consider embedded devices which may want to use RISC OS but keep some things “secret”, then it is more attractive if this is a possibility rather than “oh God more obscure compliance issues”.

Here follow a billion footnotes:

¹ Free here is in scare quotes because I believe that the GPL is fairly restrictive for a licence purporting to support code sharing, reuse, and freedom.

² I’m just reading some of Linus’ posts and replies, and he seems pretty certain that in most cases the creation of a Linux kernel module means that it is a derived work even if by virtue of using GPL header files….yet using those same header files to build a user space program does not necessarily imply that it is derived or needs to be GPL. So what is this, contamination by virtue of the API used? Seriously?
The GPL has not yet gone to law on this point, which is probably just as well considering the, shall we say, interesting decisions in favour of the RIAA (proof that you get the best law money can buy, no?), plus I really wouldn’t want to be the one to try to explain to a judge the difference between static linking, dynamic linking, plugins, kernel space, user space…moreso if we are talking about a non-Linux system. You do realise, don’t you, that all relocatable modules run in SVC mode? One could argue that you are in kernel space, given that you can write a replacement of core functionality and RISC OS will accept and use it over what it had built in. Look at how FAT32FS replaces DOSFS.

³ It is well documented that RMS has a dim view of non-free software, evidence of this mindset can be seen all over the GPL.

⁴ I have previously explained why those selling a device with smart software may want to keep their software closed in order to give them an edge over competitors products. If the software was open, it can become a race to see who can make the cheapest hardware, by companies that did none of the software design or R&D.

⁵ There is also the question of public infrastructure security. You can get open source GSM software, but you’ll have a difficult job getting FCC (ETSI, Ofcom, etc) type approval. In numerous cases, the way around this and how to permit phones running non-proprietary software to work is to make the GSM device smarter, to the extent where it contains its own processor and its own closed source firmware. You talk to it through some sort of API and it is completely distinct from and unaffected by issues regarding the user-side operating system.

⁶ http://en.wikipedia.org/wiki/Usage_share_of_operating_systems – Windows market share (all versions added) is 90%. Linux? 1.64%. Don’t bother arguing if this is biased, inaccurate, or there are other problems with the figures. Windows has a heck of a large market share, Linux does not. So some people somewhere are still making money selling software. I understand that selling is against the OSS ethos (why buy what can be downloaded?) but the point stands. People sell software. Even these days. :-)

⁷ VLC was pulled from Apple’s iOS app store because the terms of distribution of apps (remember, iOS is a walled garden) were incompatible with the GPL. As a forum post on GitHub explains: VideoLAN, after a port of their VLC player was removed from the App Store, worked around the issue by performing an almost complete rewrite of the application and by obtaining permission to implement a dual-licensing scheme from some of their existing copyright holders. VLC for iOS is now licensed under both the GPLv2 and MPLv2 licenses ⁹, which allows it to comfortably remain in the App Store. This process was painful and it took a long time to complete. The pure-GPLv2 version of VLC was pulled from the App Store in January of 2011, and the new version was not released until July 19, 2013.
Thankfully. I use VLC on my iPad all the time. It’s the only thing I have that works well with the Livebox’s DNLA server and doesn’t wet itself when given “odd” file formats like MKV. I have not found anything on Android that can do this without pasting big adverts all over the screen. Some people diss VLC (apparently the colour handling of 10 bit H.264 is questionable, but I don’t have a computer powerful enough to see for myself) but, on my iPad at least, it just works. No fuss.

⁸ Hence the on-going discussions here. ;-)

⁹ Quote: The next possibility is that the kernel remains GPLv2 only, but the GNU packages update to GPLv3 “or any later version”. This would be a significant problem for Linux distributors. They can’t distribute the kernel as GPLv3, and they can’t distribute new releases of the GNU packages as GPLv2, because the GPLv3 places additional restrictions on the distribution of code—such as the user products restriction and the patent deals restriction—and the GPLv2 explicitly doesn’t allow “further restrictions”. So what license do the Linux distributors use? http://radar.oreilly.com/2007/04/gplv3-linux-and-gplv2-compatib.html

Totally off topic from the OP, but ok:

Again Rick, I get it; you don’t like GPL. It does seem strange though that the only people who seem to be commercially involved in RISC OS (the one’s I guess you are seeking to protect) are basically selling to each other i.e. the small community of hobbyists. Want to have an archiver? 5.99 from D. Pilling. Need to make a useful SD image? 15GBP to Piccolo. Want to compile the ROM? 40UKP to ROOL. Need network printing? 15UKP to MW Software (or 40UKP to RComp). Need email? 40UKP to RComp. etc, etc, etc, etc.

Want to do it all for free? Either write code and hand the IPR to Castle or write code closed source and make a buck from your fellow enthusiast.

By keeping RISC OS as closed as possible who are you benefiting? Certainly not the user base. I don’t imagine you get paid to code for it either (so not yourself), but somewhere you think there is a billion dollar industry that you might damage which you seem to care so much about, over and above the actual users?

If you spent half as much time and effort trying to open up RISC OS and encouraging others to do the same as you do writing diatribes about GPL, we might actually have a useful OS. Just sayin’

Simon:

A forum comment from http://radar.oreilly.com/2007/04/gplv3-linux-and-gplv2-compatib.html that might be useful to explain ROMs vs CD-ROMs.

“An aggregate is a simple collection of software. It has no license and no copyright separate from the copyright of individual pieces. That’s why the GPL makes an exception for it, to clearly mark that it isn’t a derivative work. Once you add any functionality to a distributed “blob” of software it’s no longer clear that it’s an aggregate. A lot depends on how much functionality was added and the purpose of that functionality (and which particular set of lawyers and judges are examining the case). The distinction between licensable work and aggregate is open to interpretation in this context.”

A CD-ROM is a collection of software. It may have the functionality of being bootable, but it is not, entirely in itself, capable of booting a computer. There is no functionality without accessing something on the filesystem, loading it, and then executing it. Additionally, while there may be inter-relations between files on a filing system (support files for an application, for instance), each of the pieces exist as a separate entity.

A ROM, on the other hand, does have built-in functionality. It begins by bringing up the machine. Granted, the issue is a mess (modern ARM SoCs load the ROM image off of a FAT filesystem so is it a really complicated application executable or is it a ROM in the traditional sense?). If burnt into a piece of silicon, as ROOL has done for the RiscPC, the ROM is what boots the machine. It is also the kernel. It is also a hundred services and pieces of UI. It isn’t a filesystem so much as a chain of modules that are initialised in turn, all operating in SVC mode side by side with the kernel and using kernel APIs. It is kind of hard to deal with RISC OS without using any APIs. Furthermore, what do you consider the kernel to be? The low-level (hidden) RISC OS module? UtilityModule? The Wimp? All of them together? Plus more?

I disagree entirely with the your assessment and don’t really see what relevance the quote has on it. Both a ROM and a CD-ROM are storage mediums. Go grab a ROM and hold it over your head – did it boot itself? No, I didn’t think so. Now try the same with a CD-ROM; notice the difference? Nothing. Both are just different ways of storing data and, here’s the important bit – no really read this → They can both store exactly the same data – I could build some electronics to replace the IOMD ROM directly with a CD-ROM; really, honestly I could. Ok, so the boot strap would be a little more involved, but perhaps you are starting to see my point?

I have a lot of experience in electronics and I promise you there is a part of every motherboard which is responsible for making the initial boot happen. Sometimes it’s called a BIOS, some times its a little bootstrap code, no more than a few jump commands. If you read the code from a CD-ROM and execute it, or execute it from ROM, there is no difference. Looking at a RISC PC 600 schematic it seems that the IOMD chip performs the boot strap (disclaimer: this was a 30 sec. look at the diagram) – if this wasn’t the case the ROM (held over you head in the previous example) would have booted itself. If you look in a modern PC you will see that the BIOS does this – even from a CD-ROM. Go grab a liveCD version of Ubuntu. Just to be sure remove your harddrive before you boot it. Once you’ve done this please let me know what your point was.

If you spent half as much time and effort trying to open up RISC OS

You seem to keep missing the part where I perceive the GPL as restrictive.

as you do writing diatribes about GPL,

Oh look, another handwave…

No, I totally get the point that you don’t like the GPL. Actually I think I mentioned that above. It’s just that the reasons why you think it is ‘restrictive’ seem to be fairly unfounded with regards to RISC OS. I argued that a more open OS would be beneficial (which your last post ignored), I mentioned that the argument about ROM vs. CDROM was moot (which your last post also ignored).

It seems the repeating pattern here is that you make a point of view, I counter it and instead of defending your own point of view you resort to petty comments like ‘oh look another handwave’ or a complete change of argument (or your other favourite which is applying your point to the software industry as a whole rather than RISC OS). I’m sure it makes you feel better about it, but you have still not actually defended any point except you don’t like the GPL.

Once again, a rom is a single piece of software, as a statically linked program. So GPL will apply the the whole package. A CD-Rom is a set of different packages, each with their own license.

GPL v2 is absolutely clear on this point:

‘These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License’.

Nota: sometimes, developers apply ‘static exception’, to avoid contamination of non open source code.

you think it is ‘restrictive’

Because it is… From GPL v2 : ‘You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that [long list of conditions]’

It’s free software, not public domain. GPL means rights for users, and obligations for developers.

I argued that a more open OS would be beneficial

Two things:

1. I agree a more open OS would probably be beneficial.¹
2. I think your main point all through is that you believe GPL is the way to achieve this. Everyone else would appear to disagree. Your secondary point is that GPL is the only way to achieve this. Again you’re on your own.

¹ I’m pretty sure everyone would agree

I repeat (since you ignored my post too): the only way to put GPL code in a ROM would be to provid a ROM filesystem that prove that this code is (or can be) separated from the other. Then the ROM file could be considered as an archive, and not as a single resource.

Same problem for Android device makers…

It does seem strange though that the only people who seem to be commercially involved in RISC OS (the one’s I guess you are seeking to protect) are basically selling to each other i.e. the small community of hobbyists.

And this is a bad thing because…? People write software and sell it. Oh the horror!

Want to have an archiver? 5.99 from D. Pilling.

Or use the free InfoZip. But obviously, SparkFS is a lot cooler. And costs 25 UKP by the way. But why not buy the NutPi package? 35 UKP for SparkFS and a lot more.

Need to make a useful SD image? 15GBP to Piccolo.

Alternatively, use the free SDCreate tool and live with the minor inconvenience of not being able to upgrade the ROM image directly.

Want to compile the ROM? 40UKP to ROOL.

Or make an effort to be able to use GCCto build the ROM. Which would help a lot of people, especially those die-hard GPL fanatics.

Need network printing? 15UKP to MW Software

MW Software sell network printing tools? I don’t think so. But it explains a lot wrt your understanding of simple written things. Like the GPL FAQ and the countless postings of knowledgeable people trying to explain the complexities of copyright and licencing.

Want to do it all for free? Either write code and hand the IPR to Castle or write code closed source and make a buck from your fellow enthusiast.

Or write Open Source code. And distribute it freely. It is possible, you know. See the countless examples in RISC OS world. NetSurf has been mentioned before. You can even use the GPL if you like. It is called freedom.

Once again, a rom is a single piece of software, as a statically linked program. So GPL will apply the the whole package. A CD-Rom is a set of different packages, each with their own license.

Not really, the RISC OS ‘ROM’ is the RISC OS ‘ROM’; if you deliver it on a ROM or via a download on this site, it’s the same thing. That was my point. There have been many mentions that the IOMD ROM is an exception… it’s not. If it does or does not apply to the IOMD image then the same is true for any other way of distributing and storing the ROM (such as a Raspi image for example). I can give it to you on a CD or on a Floppy; the ‘thing’ I give you is the same in all cases. A ROM could also contain just music data just like an audio CD. The ‘trick’ here is not to be holistic, but focus on the actual subject: the RISC OS image.

2. I think your main point all through is that you believe GPL is the way to achieve this. Everyone else would appear to disagree. Your secondary point is that GPL is the only way to achieve this. Again you’re on your own.

This is true, I think it is. I’ve not denied that point or wavered from it. Vocal contributors to this forum seem to disagree; but that’s not ‘everyone’. Not by a long shot.

Overall the present conversation is a leap from my OP. I was trying to work out the best way to contribute whilst using the GPL; the libraries, RMs and other RISC OS specific issues affect that. Hence my need to understand the issues. Having said that, if challenged, I will defend my view point.

Even if you think that GPL is not the answer it’s hard to see why you would defend the current state of RISC OS from a licensing perspective. It is possible to do something about it. The first step is admitting that there is a problem.

This was my point in my previous thread though, not this one. If you’d like to carry on the conversation so be it. Any more than 3-4 pages of thread and I get labelled ‘a troll’ though; so I will step out of this thread now (you are all welcome to start a new, more specific thread – I’ll happily join in). I think my point was made a while ago anyway.

I dunno where the heck this is going, but okay…

I could build some electronics to replace the IOMD ROM directly with a CD-ROM; really, honestly I could.

…aaaaand what boots from CD? You would need something akin to a BIOS as it would have to be a helluva complicated pile of electronics to talk ATAPI, understand CD-ROM data, and return the correct data from the disc. In which, no, the CD-ROM is not the same as a ROM then. It would depend upon something else to get it going. Whether a really clever twenty kilograms of wire-wrapped logic gates, or a few PICs, it is still something acting as a translation layer between the physical ROM and the disc-based data.

I have a lot of experience in electronics and I promise you there is a part of every motherboard which is responsible for making the initial boot happen.

Of course, otherwise when you prod the power switch, nothing would happen.

On most PCs, it is a BIOS. Once upon a time this was a little AMI EPROM. These days it is Flash and a lot larger, for multiple device booting, for fancy boot-up logos, for UEFI, for a load of reasons. But the BIOS is what has the smarts to originally get the machine running.

On the RiscPC, as with the Archimedes range, it works just like the BBC Micro. The processor, when it comes out of a RESET condition (most power-ups assert !RESET for this reason) will branch to a specific place. The first thing that the ARM processor sees, as the MMU is not yet enabled, is this https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/HAL/IOMD/s/Top?rev=1.12#l74
On a RiscPC, the ROM is what brings up the system. By itself. With no electronics other than being wired into the machine. The IOMD handles device arbitration, VRAM, DRAM, ROM, I/O… If you look at the physical memory map in the RiscPC TRM p12, you will see that the main ROM is physically mapped in from address &0. It is the MMU and RISC OS that pushes the ROM elsewhere, but by then you’re looking at virtual addresses.

Sometimes it’s called a BIOS, some times its a little bootstrap code, no more than a few jump commands. If you read the code from a CD-ROM and execute it, or execute it from ROM, there is no difference.

From the point of view of getting the OS running, no, there isn’t much between the two. Both provide data in some form.

The difference could, however, be important for a licence that states: 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.

or otherwise:

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.

I’m not going to waste time stating the obvious question…

I will, for the sake of clarity, correct a small error that I did come across, reviewing this thread:

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”.

That is not what I said. I said “Can you explain, then, why the FAQ says you cannot legitimately install VB’s runtime DLLs with a GPL VB app?”. I am talking about an installer. You know, like SETUP.EXE. If it is not possible to include non-GPL language-dependency libraries within the installer of a GPL application, how come it is possible (according to you) to include GPL and non-GPL in a ROM?

Finally, this bit tickled me:

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).

SharedCLib is not closed. It is just not as open as you would like. It is certainly not open in a GPL compliant way.

Since I did not see you replying to this specific point (please correct me if I missed it): Using your definition of GPL here, I interpret your words above to mean in your interpretation, it is perfectly acceptable to have GPL modules within the RISC OS ROM so long as these GPL modules do not make use of a non-GPL library? Is this correct?
If so, however exactly would you define “library”? Could it not be argued that most modules provide library functions?

For example, how is calling fgetc() different to calling OS_GBPB?
Except for the layers of complexity, they are similar. OS_GBPB handles retrieving data from disc(/device), while fgetc() works at a slightly higher level to support buffering and such.
Here’s what it does: fgetc() [c.stdio] calls getc() [stdio.h macro] which may call __filbuf() [c.stdio] which may call various functions to handle having the data available, one of which is _sys_read() [c.armsys] which calls _kernel_osgbpb() [s.k_body] which then calls SWI OS_GBPB.
I write all of this to then ask: What constitutes a “library”? If a GPL module cannot call non-GPL library code, well, that does restrict it somewhat…

It is possible to do something about it. The first step is admitting that there is a problem.

Okay. Show of hands.

Who here, other than Simon obviously, is unhappy with the current licencing of RISC OS, and why?

People write software and sell it. Oh the horror!

It is. It is absolutely horrible. Software should be free. Completely free. FREE, I tell you, FREE.
Music too.
And movies. Unless directed by Michael Bay, then you should pay me to watch it.
And…
…everything. Totally free. Should be totally free. We should live and let live. And all live our dreams. I’m going to turn this world inside out. I’m going to turn suburbia upside down.

35 UKP for SparkFS and a lot more.

This bit.
Bad.
Like Beer Bad. Buffy said so.

use the free SDCreate tool

Quicker to download the image and use Win32DiskImager (or something like that)…

Or make an effort to be able to use GCCto build the ROM.

Provided, please, that it remains compatible with the official DDE. If this is possible, if GCC can be coaxed into building from the same source as the DDE, this could open up some additional avenues for development of RISC OS.

Or write Open Source code. And distribute it freely. It is possible, you know.

Well, we first need to convince him that there are other perfectly viable options that are not GPL that interact with RISC OS quite happily. Try this: https://www.riscosopen.org/viewer/view/cddl/RiscOS/Sources/FileSys/SDFS/SDFS/LICENCE?rev=1.1.1.1;content-type=text%2Fplain
Note specifically section 3.6.

That’s it. I’ve been up, like, nineteen hours (early start at work, busy period so we do alternate Saturdays), so I’m going into standby mode. Good night everybody.