Castle denies GPL code in RISC OS 5 - RISC OS News, Software and Information

Castle denies GPL code in RISC OS 5

Published: 10th Feb 2003, 20:12:43GMT Source: drobe.co.uk
By Chris Williams

Page 1 of 1

We got nuffink guv, honest

Every coin has two sides and it's only fair to look at each side at a time. On one side we have Russell King's claims that RISC OS 5 contains GPLed Linux PCI code. On the other side, we have Castle's response which just arrived at drobe.co.uk. It's what you've been waiting for, take a deep breath.

"Following discussions with Russell King and with this in mind, Castle should like to respond to claims originally proposed in Justin Fletcher's 'ReadMe.txt' file and Russell King's subsequent posting to the Linux Kernel Mailing List", starts the press released issued on behalf of Castle by their official PR person Mike Williams.

The statement goes on to categorically affirm that RISC OS 5.00, RISC OS 5.01 and RISC OS 5.02 do not "contain work taken from or derived from the ARM-Linux or Linux kernel". Castle assert that it's not their intention to employ GPL derived code in the RISC OS kernel. So, uh, why the Linux kernel function names?

"For the avoidance of doubt, the hardware abstraction layer (roughly analogous to a PC's BIOS) has it's PCI allocation and bridge setup based in part on the following functions from the Linux kernel sources", the statement continues listing the following functions:

pci_alloc_primary_bus, pbus_size_bridges, pbus_assign_resources_sorted, pci_setup_bridge, pci_bridge_check_ranges, pbus_size_mem, pbus_assign_resources, pci_assign_unassigned_resources, pci_scan_bus, pcibios_update_resource, pci_read_bases, pci_alloc_bus, pci_add_new_bus, pci_do_scan_bus, pci_scan_bridge, pci_setup_device, pci_scan_device, pci_scan_slot, pcibios_fixup_bus, pci_calc_resource_flags, pci_size, pdev_fixup_device_resources, pbus_assign_bus_resource, pci_do_scan_bus, pcibios_fixup_pbus_ranges, pci_assign_resource, pdev_sort_resources, pdev_enable_device, pbus_size_io

.

A slither of admittance detected there perhaps? The HAL in RISC OS 5 allows the OS kernel to communicate to all kinds of hardware - the HAL is like a stop gap in between devices so the RISC OS kernel need not concern itself with device specifics. So ok, the RISC OS PCI code is in the HAL and it's got nothing to do with GPL derived Linux source code, it's just "based in part" on the Linux source. Oh my.

And if you don't believe Castle, you can ask them for a copy of the sources to the HAL component of RISC OS 5, how generous and willing of them.

"Any company or individual wishing to receive a copy of the source code to this [HAL] component should apply in writing to:



The Managing Director
Castle Technology Ltd
Ore Trading Estate
Woodbridge Road
Framlingham
Suffolk
IP13 9LL

enclosing a formatted 3.5" floppy diskette and return postage stamps, or international reply coupons for those outside the United Kingdom."

Ok, why did Castle remove the function names from the ROM after Justin first spotted them in his private investigations last year? Castle's answer is that in order to slim down RISC OS 5 even further for it to fit inside a 4MB ROM the function name strings were stripped to make extra space.

The statement, as Castle's side of the story, aims to clear up all the queries raised about the origins of RISC OS 5's PCI code by addressing all the points made by Russell and Justin. In the run up to this statement being released, quite a few people were convinced by Justin's strong evidence and it appears Slashdot.org are remaining skeptical of Castle's response (curses iconbar.com, curse you and your quick cut'n'paste job). We'll leave it to you to decide who's closer to the truth and don't forget to post those discs to Castle tomorrow morning.

You can of course read the whole statement word for word here.

Links
Castle Technology

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

[Printable] [Digg this] [Blog search]

AMS 10/2/03 9:08PM	Well it'll be easy to check won't it ? You'd better get your disk FAST in the post Chris, someone on slashdot was suggesting that 50,000 be sent. Typical in isn't it, Castle may well prove they didn't do anything wrong but the next year of development will be held up having to do 50000 diskettes copies of the PCI source ! -- Annraoi McShane,
diomus 10/2/03 9:09PM	Welcome to Slashdot :/ Chris, drobe.co.uk
ksattic 10/2/03 9:11PM	How about this for a generalisation: Slashdot readers are armchair activists. Castle will be lucky to receive a single disk from a non-RISC OS-user Slashdot reader! -- Simon Wilson, Boulder, Colorado
SparkY 10/2/03 9:15PM	"Castle denies GPL code in RISC OS 5 Published: 10th Feb 2003, 20:12:43GMT Source: drobe.co.uk" 8.12pm?! No it wasn't! -- Gavin Smith, Carrickfergus
diomus 10/2/03 9:32PM	Pretty sure it was. I left my dinner to go cold while I was too busy faffing around with RISC OS stuff. WHo cares when it was published. Chris, drobe.co.uk
radiac 10/2/03 10:49PM	Most slashdot readers may be lazy, but remember the stuff about spammer Alan Ralsky? A few of them signed him up to every snail spam mailer they could find: [Link: www.freep.com] How come they are forcing people to send floppies rather than post the source code on the website? They dont want the code going round - doesnt sound likely... playing for time? Heh, wonder what license they're releasing it under
ksattic 10/2/03 10:58PM	I doubt Castle are playing for time by only sending out floppies. If they had said "email us if you want the source", they would have been inundated with requests. Someone would have to sort through all the email and send attachments to each one. You would get every wannabe lawyer and curious reader in the RISC OS world and from Slashdot emailing for the source because it's so simple to do so. At least with snail mail, you actually have to be bothered to write a letter, enclose an SAE and a floppy disk and wait for the reply. The effort on your part proves your intentions are serious. I think it's commendable that Castle are releasing this source code. If it does turn out to be their own work, they have effectively made that part of RISC OS open source. -- Simon Wilson, Boulder, Colorado
em2ac 10/2/03 11:13PM	not attempting to be too silly here, but basing code on already bug proved code isn't a bad idea. Perhapps you didn't want to use RISC OS on your IYONIX? you would have to re-write code to enable other OS's (like LINUX) to use the new computer and it's associated Hardwear, whereas code with names based on standard OS's would (if completely done) allow other OS's to use the Hardware. plus if this was done could porting software be made easier?
knutson 10/2/03 11:36PM	Great marketing ploy, make the disk readable only on RISC OS 5 -- Steve Knutson
NeilWB 11/2/03 9:22AM	I will repeat what I said on IconBar. It seems to me that Castle are making two statements: 1) The RISC OS 5 kernel does not contain work taken from or derived from the ARM-Linux or Linux kernel. Therefore the fact that this code is proprietary (copyright CTL or Pace or) does not create an issue in terms of GPL 2) The hardware abstraction layer DOES contain code based upon Linux kernel sources. They are, however, releasing the source code for the HAL, and in so doing, will not be in breach of GPL. Neil
Stoppers 11/2/03 9:31AM	*In reply to ksattic:* If they didn't want to be innundated with e-mails, why not put it on a website and post the URL? No e-mails, no physical floppy copying. -- Simon Willcocks,
takkaria 11/2/03 3:54PM	And then they'd have to pay large fees to the web hosters, no doubt, for stupidly large amounts of traffic. Also, Stoppers, you missed on the ksattic's other point - that sending for it via post proves the requester's intentions.
moss 11/2/03 4:34PM	Well, the point is - does the HAL contain any GPL code? If it does, then there's no need for the requester to "prove their intentions" - they have to do it anyway. If it doesn't contain GPL code, then fine; but I don't really see why anyone would have to prove their intentions anyway. Once it's out, it's out; Castle can't keep control of it. As for webhosting, well, I'm sure if slashdot people are that interested in seeing it, slashdot/someone else interested with a lot of bandwidth would put up a mirror of the download. Hell, it can't be that big; I'm sure 1.0 could cope...
piemmm 11/2/03 4:50PM	You mean 'AcornSearch/Drobe'
ksattic 11/2/03 4:56PM	*In reply to NeilWB:* With regard to your second point, Castle didn't actually say that they used any GPL code anywhere, but who knows if that's what they meant. I'm sure we'll find out when we see the source. *In reply to Stoppers:* Good point, but I'd say they're not happy about putting the source for their work on RISC OS on the web where even more people will have access to it and comment on their coding (plus it will be accessible from Google's cache till the end of time). -- Simon Wilson, Boulder, Colorado
moss 11/2/03 5:06PM	g0tai: Yes
Glitch 11/2/03 10:15PM	moss if castle is smart about this then, AND they havn't violated the GPL then in getting somebody send for the piece of code they will have a database of who they sent the code to, and this is the smart part, shuld have tagg every individaul copy, which is possible because they are doing it on a indiviual bases. They should be able to track, if its put on the internet, who put it on the internet, and procede with legal action for the publishing copyrighted code without the their permission.
El Capitano 11/2/03 10:26PM	Any source code released could easily have any identifying segments released, unless Castle put a lot of work into it. Besides, starting legal proceedings would be unwise since it'd probably trigger a counter-suit.
Glitch 12/2/03 3:01AM	well in the case of having thier work distributed as they say it is not under the GPL the copyright law would be on thier side. the people who then distributed the code on the internet of castle did sue, then the people being sued would actaully have to find a case to make a counter-suit. remember castle has still to have been proved of anything, so until there is evidence that castle has done wrong, a counter-suit couldn't happen.
NeilWB 12/2/03 6:48AM	*In reply to ksattic:* I think the key point is they plan to release the code - irrespective of whether or not the HAL contains Linux code, they will NOT be in breach of GPL. Neil
ksattic 12/2/03 8:55AM	*In reply to NeilWB:* I think you're right! -- Simon Wilson, Boulder, Colorado
ben 12/2/03 10:59AM	Surely if the HAL code is based in part on GPL'd code (as Castle say in their statement) they'll be distributing their HAL code under GPL (with a copy of the licence attached). It's not just that they must release the code, it's that they must release it under GPL.
El Capitano 12/2/03 11:54AM	Glitch: I think it could easily trigger a counter-suit. The code compiles into something very, very close to Justin's adjusted code. Thus, the source code must be pretty similar to the GPL code, otherwise it would compile into something really quite different. Thus, if Castle turned around and sued someone for posting the code, I'd put pretty good odds on a copyright holder to some Linux code to turn around and sue Castle for breach of the GPL.
Stoppers 12/2/03 12:56PM	*In reply to takkaria:* How much traffic would it really be, if it all fits on a floppy? OK, the requester must be willing to invest 50p or so to get the code, or be willing to wait quite some time, if they are overseas (like ksattic is). As it is, we can't even tell what licence the code is being released under until a floppy has been sent, updated and returned, which could take as long as Castle want to delay. This is why it feels like a delaying tactic. -- Simon Willcocks,
takkaria 12/2/03 4:50PM	There's no point in speculating about the licence until someone actually gets a copy of the code. However, it's possible (maybe even likely) that when they send the code to a given person, they tag the code with a unique tag of some sort, which is put in a database along with the person's details. If someone was to put this code on the internet, they can work out who it is from its tag and procede with legal action for the publishing copyrighted code without permission. (Glitch suggested this above).
El Capitano 12/2/03 5:30PM	Seeing as Castle have stated it'll become part of their port of Linux to the Iyonix, they'll have to GPL it at some point or another. Why not do it now?
Stoppers 12/2/03 5:40PM	OK, but tagging the code only makes sense if they're not releasing it under the GPL, otherwise the recipient is allowed to do with it whatever they want.
em2ac 12/2/03 9:02PM	I seem to see the senceless squabling that plagues our platform so going on here. has anybody thought about what this could mean to programmers?
moss 13/2/03 7:54PM	This thread doesn't seem like squabbling; more like discussion. I think people can be slightly over-sensitive about it. Not to say that it doesn't go on, of course, but being over-sensitive to squabbling often causes as much damage as squabbling itself.
Glitch 14/2/03 7:17PM	I agree with you moss, sometimes the most damaging thing isn't the statement somebody has made, but rather the reaction by people to it.
SparkY 18/2/03 12:51PM	Has anyone received the source code yet? I think a final report should be done on all this when the dust is settled so that it's not something that drags on for months. -- Gavin Smith, Carrickfergus
Stoppers 20/2/03 6:40PM	Apparently, yes. I guess you didn't read past the 85 pounds bit in the SW show entry! I wonder, is it GPL. or not? I wish I'd asked for a copy now, a floppy might have made the round trip since the 11th.
SparkY 21/2/03 3:22PM	My post was on the 18th, that show news was on the 19th And now your wish for the code has come true, Drobe have it online. -- Gavin Smith, Carrickfergus
Stoppers 24/2/03 1:29PM	So it was; my apologies! Browse doesn't seem to pick up the latest version of Drobe pages without a refresh (especially annoying when I log in and go back to the page I wanted to comment on only to find I have to refresh it to get the edit boxes), maybe I've configured something wrongly. Thanks, Drobe, for putting the code online.
Use the forum for more comments on this article