Castle deliver RISC OS 5 HAL 0.10 - RISC OS News, Software and Information

Castle deliver RISC OS 5 HAL 0.10

Published: 20th Feb 2003, 22:24:16GMT Source: drobe.co.uk
By Chris Williams

Page 1 of 1

And there's a copy mirrored online, here.

We've been delivered a copy of the RISC OS 5 HAL, a fundamental operating system component released following Castle's statement on allegations that RISC OS 5 contained GPLed PCI code, used by the Linux operating system. The archive of source is distributed under version 2 of the General Public Licence, which is why we can also re-distribute the source archive for anyone who wants a copy. If you posted Castle a disc and asked for a copy, you were also sent an interesting flyer on future Iyonix motherboard and Oregano prices but we're waiting on an official PR for that. You'll get no teasing from us. Well maybe some.

"These hardware abstraction layer (aka the 'BIOS') sources correspond to the latest public release from 24th January 2003", explains the note with the sources. "This version is released here under the terms of version 2 of the GNU Public License - a copy of which is included in this archive - for others to make use of when working with the 80321." The 80321 being the Intel Xscale processor used in the Castle Iyonix and the hardware abstraction layer being the HAL.

The source archive contains C code for controlling PCI and USB hardware and numerous low level assembler sources. It's like Castle have wrapped up all the Linux based sources in RISC OS 5 into a little tidy box labeled "HAL" and jettisoned it off under the GPL 2. We'll leave a critical breakdown of the sources until we've had time to go through them and consult other knowledgable people. Either way, Castle have delivered the source as they promised and in our eyes, that's a result. How about a nice Sourceforge.net project called "RISC OS HAL"?

Links
HAL 0.10 source code to RISC OS 5
Castle Technology

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

mrchocky 20/2/03 10:29PM	"RISC OS HAL"? You can't do that, Dave. It had to be done. -- Peter, drobe.co.uk
ksattic 20/2/03 11:15PM	Heh! The Iyonix will need a bright red light on the front now. -- Simon Wilson, Boulder, Colorado
danielbarron 20/2/03 11:38PM	And some plastic transparent blocks you can eject so it can sing "Daisy" slowly.
knutson 21/2/03 3:26AM	Quite a smart idea really. Rather than developing USB and PCI drivers from scratch, Castle can port drivers from Linux (releasing any code of course). -- Steve Knutson
SparkY 21/2/03 10:00AM	So does this mean, frankly, that Castle did use GPL'd code and they're now trying to do the right thing by releasing it? If that's the case, I'm happy enough, as long as they behave in the future! -- Gavin Smith, Carrickfergus
El Capitano 21/2/03 11:32AM	While I'm glad Castle are abiding by the GPL somewhat, I'm still somewhat sceptical about this. After all, RISC OS 5 requires the HAL to function, and under the GPL, that would require the GPLing of RISC OS 5 itself. Linux software does not have to be GPL or compatible since the decision that linking with the kernel counts as using, rather than deriving from the kernel. However, the RISC OS 5 kernel still operates at the same layer as the HAL, kernel level and it is dependent on the HAL. Most Linux software runs on platforms other than Linux, and there are alternative implementations of the Linux user-mode interfaces. However, there are no other implementations of the HAL. Ultimately, I'd say it's a bit of a grey area and I would be unable to say one way or the other whether Castle are still in breach. I guess it would take a Linux developer who does not like the outcome enough to file a suit to find out. Either way, I don't like how Castle side-stepped the GPL, if Chris' interpretation is accurate. I would also like to say that this does confirm Castle were in breach of the GPL any way, and that they would still be in breach if nobody had caught them out. They aren't exactly the good guys in this.
SparkY 21/2/03 12:25PM	Indeed they aren't the good guys in this. Maybe they misunderstood this whole "free" software lark. Maybe they didn't realise it would cause this much trouble. I know a lack of knowledge is no excuse, but it still might have been the reason. -- Gavin Smith, Carrickfergus
El Capitano 21/2/03 1:21PM	Are you suggesting a professional company that has been around for years, has developed both hardware and software and has been in licensing negotiations several times in previous years would not bother to find out about the license of some open source code? It's not like the GPL is obscure either, most people on Slashdot understand the GPL better than Castle would if what you were suggesting is true. Are you seriously trying to suggest Castle are incompetent?
SparkY 21/2/03 3:15PM	Yes, I thought we had agreed that they were incompetent for what they've done. I'm suggesting their use of the GPL code under improper conditions might have been done out of ignorance rather than trying to be sneaky. Hey, I was trying to be positive. They've released it properly now and I really don't think anything more is going to come of this, whatever your interpretation of how much HAL is or isn't part of RISC OS. -- Gavin Smith, Carrickfergus
Nodoid 21/2/03 11:44PM	Not wishing to add fuel to the fire here, but has anyone checked Justin's Diary for the 14th Feb? It looks like the whole of the "borrowing" of code has been going on for way longer than suspected...
Gerph 22/2/03 2:47AM	Hey, the whole video thing was just meant in good humour... I'm not in any way suggesting that WB (it is WB who produce it, isn't it?) nicked the joke; I just thought it was amusing
ralph 22/2/03 7:24PM	SparkY says "they've released it properly now". Have they? Has anyone got an Iyonix recently and found it accompanied by a written offer of the HAL source? Castle need to comply with one of 3a, 3b, or 3c. The HAL010/Notes file I downloaded from Drobe says "sources correspond to the latest public release from 24th January 2003." Has anyone requested the source to match the version of the HAL they were shipped? Let's not forget that Castle have to continue to make source releases as they ship later binaries. I'm not trying to victimize Castle here. They violated the GPL license and now wish to conform. It's up to us to politely ensure they realise their responsibilities. Cheers, Ralph. P.S. Anyone made the HAL from their Iyonix ROM, not one built from the released sources, available for download on the web yet, as is their right?
moss 25/2/03 5:26PM	Interesting that Slashdot haven't covered this...
ksattic 26/2/03 7:04PM	That's because "Castle break GPL" is a much more interesting headline than "Castle comply with GPL". Very unbiased news reporting, y'see. -- Simon Wilson, Boulder, Colorado
moss 26/2/03 7:08PM	Yes. Interesting that as soon as the power is taken away from big corporations, people don't grasp the opportunity to give fair, unbiased news, but simply twist it to their own ends. It makes me despair.
El Capitano 27/2/03 10:57PM	Have you not considered that maybe nobody submitted it to Slashdot? If you want Slashdot to carry it, submit the story. If it gets rejected, then you may have a case. There is also the problem that Castle may still be not complying with the GPL.
moss 28/2/03 1:02PM	Well, I did consider that - but seeing as I rarely read Slashdot, I didn't think it was really my place. Anyway, it's not whether Castle have or haven't complied with the GPL that I'm complaining about (the news story could be sceptical and I wouldn't complain) - more that the recent news hasn't been discussed at all. The people who originally submitted it to Slashdot don't think this is news - which strikes me as rather suspicious.
El Capitano 28/2/03 1:27PM	Fair point Moss. Unfortuanately, Slashdot is full of trolls who love nothing better than starting a good flame war. However, it is possible the original submitter is wanting to see how this plays out before submitting another story. Perhaps he wants to confirm whether or not the code is pretty much lifted from Linux and whether people are going to push Castle to GPL the rest of RISC OS (Which the language of the GPL suggests is the correct course of action since the HAL is not distributed separately).
moss 28/2/03 2:11PM	Yes; that's a good point - waiting a while for further info is probably a good idea. I'll get off my high horse for now
ralph 1/3/03 1:55PM	Hi El Capitano, > Which the language of the GPL suggests is the correct course of action since the HAL is not distributed separately It's isn't relevant that it isn't distributed separately. The GPL says "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." It's whether it's a derived work that matters. And from what I can see it isn't. But that still means Castle have to ensure they comply with the GPL for the HAL, i.e. release the source to all the HAL versions they've shipped. Comply with one of 3a, 3b, or 3c, etc. Cheers, Ralph.
El Capitano 1/3/03 2:17PM	Also from the GPL: "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, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it." "For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." Seeing as you cannot consider RISC OS 5 independent from the HAL (It won't work without it), then you could consider the HAL part of RISC OS 5. I do, however, concede my original argument.
mavhc 1/3/03 6:52PM	You could replace the HAL with other code without changing RISC OS, so it's not linked. If that were true then if you sold an OS with a GPL BIOS in a PC you'd have to GPL the OS. The whole point of the HAL is its independance from RISC OS
El Capitano 2/3/03 6:41PM	"You could replace the HAL with other code without changing RISC OS, so it's not linked." You could replace Qt with a BSD licensed version if one existed. It doesn't mean you can suddenly make non-free programs with the GPL Qt. "If that were true then if you sold an OS with a GPL BIOS in a PC you'd have to GPL the OS." And? "The whole point of the HAL is its independance from RISC OS" But RISC OS isn't independent of the HAL.
mavhc 2/3/03 8:11PM	Of course it's independent, they're not statically linked. They only interact via known APIs, you can replace one without touching the other. This is of course the most waffley part of the GPL: "What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide" ie they haven't properly decided, maybe they have lawyers in the family who want to earn some cash.
El Capitano 2/3/03 8:50PM	Err...dynamic linking is something that's been going on for years. However, it doesn't negate my Qt argument. The fact is, there is no non-GPL version of the HAL, and until there is, you can't consider RISC OS 5 independent of the GPL HAL.
ralph 4/3/03 4:18PM	Hi El Capitano, > there is no non-GPL version of the HAL Sure there is. Pace have several. Do you mean the Iyonix HAL? Having chased people for definitions quite hard, I've come to the conclusion that the Iyonix RO 5 isn't 'linked' to the Iyonix HAL in GNU GPL terms. But that still means Castle have to comply with their GPL obligations WRT the HAL. I politely emailed Castle before the recent show pointing some of these obligations out. Haven't had a reply yet.
El Capitano 7/3/03 12:34AM	There is no non-GPL version of the HAL that will work on the Iyonix. The Iyonix RISC OS 5 will not function at all without the GPL HAL. Therefore, it's not simple aggregation. Of course, if you don't believe dynamic linking constitutes a GPL violation, there are a number of FSF lawyers who would disagree.
ralph 15/4/03 10:22PM	I do believe dynamic linking constitutes a GPL violation. But the RO 5 doesn't do that to the HAL it uses. That's like saying that an application is linking to the OS by using the SWI instruction causing the processor to jump to a known location in memory containing the SWI handler.