Drobe logo

Castle denies GPL code in RISC OS 5


Published on 10th Feb 2003, 20:12:43, source is drobe.co.uk
By Chris Williams

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

Related articles
Castle reveal shared source licence
Castle and ROS Open reveal plans for 2007
Castle directors patch up 'disagreement'

This article has been linked to, or is available in the following formats:  
 
 
 
 
 
[Printable] [Digg this] [Blog search]


Design and concept (c) Fudgecake Design, 1999 - 2001. Content (c) The Drobe Team, 1999 - 2006. See www.drobe.co.uk for more information. For non-commercial personal use only.