log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- WROCC Newsletter Volume 41:11 reviewed (News:)
- WROCC March 2024 meeting o... Hughes and Peter Richmond (News:1)
- Rougol March 2024 meeting on monday with Bernard Boase (News:)
- Drag'n'Drop 13i2 edition reviewed (News:)
- South-West Show 2024 talks (News:4)
- February 2024 News Summary (News:1)
- Next developer fireside chat (News:)
- DDE31d released (News:)
- South-West Show 2024 Report (News:)
- South-West Show 2024 in pictures (News:)
Related articles
- Rounding Up February
- Iconbar in update shocker!
- Iyonix Linux, USB Printer Port, Hydra update
- Catch Up
- Podcast IV - coming soon!
- RISC OS Select on ROM [updated]
- News round-up [updated]
- Castle propose modifications to Iyonix motherboard [updated]
- The Iyonix experience
- Alpha benchmarks, Omega tittle tattle
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: News and features: Castle Technology deny GPL breach
 

Castle Technology deny GPL breach

Posted by Andrew Poole on 19:10, 10/2/2003 | , , , , ,
 
The Icon Bar has just recieved a press release from Mike Williams, on behalf of Castle Technology in response to the recent claims that they had used code which was protected by the General Public Licence.

In the Press Release, they state the following:

  • "The RISC OS 5.00 kernel did not contain work taken from or derived from the ARM-Linux or Linux kernel."
  • "The RISC OS 5.01 kernel did not contain work taken from or derived from the ARM-Linux or Linux kernel."
  • "The RISC OS 5.02 kernel does not contain work taken from or derived from the ARM-Linux or Linux kernel."
  • "There are no plans to use GPL derived code in any part of the RISC OS kernel in the future."
The press release goes on to state that "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:"
  • 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_resources
  • pci_do_scan_bus
  • pcibios_fixup_pbus_ranges
  • pci_assign_resource
  • pdev_sort_resources
  • pdev_enable_device
  • pbus_size_io
Castle state that "any company or individual wishing to recieve a copy of the source code to this component should apply in writing to:"
The Managing Director
Castle Technology Ltd
Ore Trading Estate
Woodbridge Road
Framlingham
Suffolk
IP13 9LL
You will also need to enclose a formatted 3.5" floppy diskette and return postage stamps (or international reply coupons if you are outside the UK)

"These sources will also form an integral part of a forthcoming Linux port to the IYONIX" they go on to state.

Finally, they close by saying "With the tough goal of fitting all of the supporting software and applications for the IYONIX computer into just 4Mbytes of ROM, later issues of the supporting software have had to have function names removed (along with a strategy of tokenising textual messages and compressing binaries) to make room for, in particular, the support for the 'boot keyboard' USB drivers."

Update: for further debate on this subject, head over to Slashdot.
 

  Castle Technology deny GPL breach
  This is a long thread. Click here to view the threaded list.
 
Simon Wilson Message #91789, posted by ksattic at 01:33, 12/2/2003, in reply to message #91788
ksattic
Finally, an avatar!

Posts: 1291
Again, your definition of "based on" is the problem. Castle did not say they had copied GPL'd code. They said it was "based in part on...Linux kernel sources". Until we see the source, we cannot determine for sure whether or not copying has taken place. "Based in part on" can indeed mean they have used ideas, algorithms and techniques from the Linux kernel code. *None* of this violates copyright (or the GPL) unless actual copying has occurred.
  ^[ Log in to reply ]
 
Simon Wilson Message #91790, posted by ksattic at 01:57, 12/2/2003, in reply to message #91789
ksattic
Finally, an avatar!

Posts: 1291
Sorry Darren, I do see that you also said that at the very least Castle have looked at the Linux code and based theirs on it.

You can't copyright an algorithm, only actual code (you might be able to patent an algorithm though).

  ^[ Log in to reply ]
 
Glitch Message #91791, posted at 03:08, 12/2/2003, in reply to message #91790
Unregistered user firstly i doubt the evidence supplied would be able to hold up in court, secondly the statement doesn't admit the copying or using of any GPL licensed code.

nobody has yet repeated or verified the findings.

  ^[ Log in to reply ]
 
Darren Winsper Message #91792, posted at 08:26, 12/2/2003, in reply to message #91791
Unregistered user First of all, looking at those functions, it's likely more than a single algorythm was copied, along with more than ideas. Why would they choose to have their PCI layer be somewhat different to the rest of their OS if they weren't effectively lifting code from elsewhere? Note that you can't just look at a substantial piece of code like that and then write something almost identical. Just because you typed it by hand doesn't mean you didn't violate copyright.

Glitch: That evidence is the sort of thing that would hold up in court. Justin has shown how you can make very simple changes to Linux to produce the code in RISC OS 5. It would at least put the onus on Castle to disprove they've lifted GPL code.

  ^[ Log in to reply ]
 
Simon Wilson Message #91793, posted by ksattic at 09:00, 12/2/2003, in reply to message #91792
ksattic
Finally, an avatar!

Posts: 1291
Darren: I don't understand what you mean by "Why would they choose to have their PCI layer be somewhat different to the rest of their OS". Noone has seen the source to the rest of the OS. I'm not sure how substantial the PCI code is. You're right that retyping doesn't side-step copyright. Let's see what Castle's sources look like.
  ^[ Log in to reply ]
 
Darren Winsper Message #91794, posted at 11:44, 12/2/2003, in reply to message #91793
Unregistered user Think of it this way, those functions stood out enough for them to get noticed in the first place. Then, they had the exact same names as functions in Linux and took nearly the exact same arguments. Presumably the rest of RISC OS and Castle's HAL don't have similar function names to Linux function names, or the ones that are wouldn't have stood out so much.
  ^[ Log in to reply ]
 
James Walkerdine Message #91795, posted by walkerdi at 13:46, 12/2/2003, in reply to message #91794
Member
Posts: 4
Admittedly Castles statement can be interpreted in numerous ways, however my interpretation of it is that they have used the Linux code just as a reference. i.e. They've examined it for ideas on how to do it and decided to do it in a similar way.

As long as they haven't just cut and pasted the code, then there is no problem, even if it involves deciding to structure the code in a similar way. Getting ideas on how to do stuff from other peoples code happens all the time.

Consequently the evidence against Castle isn't that strong. They have used the same method names. So what? When I am refering to code examples I have done the same many a time. If Castle decided to model their PCI code on that used in the Linux kernel, then it is not suprising the names are similar. Why come up with a different name, if you have a perfectly adequate one right in front of you. It would be ridiculous to start copywriting method names.

The second argument is that the compiled code is very similar. If Castle decided to use a similar approach/structure as the Linux code, then this is also not suprising.

What it comes down to is whether or not the actual code within the methods is identical. If it is then Castle are at fault, if it is not then they are innocent whether or not they have used the same method names, or the compiled code is similar

  ^[ Log in to reply ]
 
Darren Winsper Message #91796, posted at 17:40, 12/2/2003, in reply to message #91795
Unregistered user I don't think you realise how similar the code is. It's almost exactly the same. You'd have to have studied the reference code in depth, and then written something almost identical, down to the individual statements. Would you be happy with someone taking RISC OS, decompiling it and then using that decompiled source to produce something almost exactly the same?

And, for what it's worth, the dictionary definition of "based" means derived. At least, none of the other definitions make sense:
http://www.iconbar.com/comments/add.php?id=296&type=n

  ^[ Log in to reply ]
 
John Hoare Message #91797, posted by moss at 18:44, 12/2/2003, in reply to message #91796

Posts: 9348
We'll soon see...
  ^[ Log in to reply ]
 
Pages (3): |< < 3

The Icon Bar: News and features: Castle Technology deny GPL breach