Castle reveal shared source licence - RISC OS News, Software and Information

Castle reveal shared source licence

Published: 18th May 2007, 22:49:17GMT Source: drobe.co.uk
By the Drobe news desk

Page 1 of 1

Source code to be released tomorrow

Castle and RISC OS Open will tomorrow launch the first stage of their shared source project - by publishing their licence and portions of the RISC OS 5 source code. According to documents seen by drobe.co.uk this evening, the blueprints for a number of components are set to appear on the ROOL website in time for this weekend's Wakefield show. And copies of the licence were tonight uploaded to the CTL website ahead of Saturday's unveiling.

The basis of Castle's legal agreement is to allow people to download, modify and redistribute the source code provided it is not sold as part of a hardware product. It must also target ARM-powered architectures, according to the paperwork. Developers contacted by drobe.co.uk tonight feared the wording of the licence was "vague and obnoxious" and that loopholes may be found.

Coders will from tomorrow be able to fetch the blueprints and tools to build the operating system software, and are encouraged to feed any changes they make back to CTL. ROOL are said to be running the project on a not-for-profit basis after announcing their intention to manage the 'shared source code' around a year ago.

A ROOL insider said tonight: "This is a big day in the history of RISC OS. For the first time, ordinary developers and users will not only be able to look at the source code for their favourite OS, but they will be able to add to it in ways that have until now been impossible."

Links
Castle source licence text
RISC OS Open website
Software in first RISC OS 5 source code release

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

[Printable] [Digg this] [Blog search]

rjek (+0.5) 18/5/07 11:02PM	"intended for commercial sale" is the funniest bit.
hubersn (+2.0) 18/5/07 11:34PM	Generally (if I have understood the legalese correctly) I think that the licence is a lot more liberal than expected by many of us. The problems will start as soon as someone is trying to misunderstand the part "reasonably be considered an independent and separate work". At first sight, I'm quite happy with it. Only the "ARM clause" seems to be a bit strange. I'm not sure what the legal status of e.g. an ARM JIT would be.
nevali 19/5/07 12:30AM	In terms of open source (of any variant) licenses, the RISC OS Shared Source license is absolutely abysmal. It actually makes the Microsoft Shared Source license used for Windows CE look generous. In terms of RISC OS, it's a major leap forward.
gdshaw (+1.1) 19/5/07 5:53AM	I have mixed feelings about this. On the one hand, installing a complete disc image using a package manager has just become a realistic proposition. This had always been one of my objectives - you can just about boot a system using my half-finished !Boot and !System applications - and whatever you think about the licence, it is something we can live with in this context. There will also be benefits to developments such as my threading module - it is much easier to fix bugs if you can see what you are trying to interact with. OTOH, this makes it rather less likely that we will ever have a usable version of RISC OS under a real Open Source licence, or which targets other processors. (I've been preparing another small contribution to the above - it's a free implementation of the filer module and is in the RiscPkg source repository.) On balance though, a welcome development and one that will benefit my work significantly.
gdshaw (+1.0) 19/5/07 6:08AM	One further point that occurs to me: I am very pleased to see that the term 'Shared Source' is being used now rather than 'Open Source'. Whether previous comments in this forum have had any influence here I do not know, but if they have, thank you for listening.
lym (+1.0) 19/5/07 10:56AM	*In reply to GDShaw:* I'm quite happy to be corrected by those (like yourself) who know much more about these things, but I'm actually quite pleased that we have a shared-source, rather than open-source, licence. One of the reasons that I, as a non-programmer, like RISC OS (and fear Linux) is that it has been designed along commercial lines for non-technical people, and comes from one source (OK, two now that the split has happened). If RISC OS splintered into many different distros, I would worry about it becoming more confusing to install, update and use. So Castle keeping control seems to me to be a good thing (for people like me). I can see, however, that for proper developers the restrictions may be annoying. And I agree that the ARM-only clause is disappointing. I hope that no-one, however tempting it may be, goes ahead and abuses the terms of the licence, though: a new legal battle is the last thing the platform needs. Although I suspect this is a pipedream, a new, faster Iyonix would allay some of the qualms about ARM-only - I wonder if Castle think there's any mileage in an Iyonix II?
AMS (+1.0) 19/5/07 12:58PM	Nice to see something progressing on this. Interestingly the license says (and this caused must dispertion of dandruff as I scratched my head - I quote "PROVIDED THAT such work is only intended to be used in conjunction with an embodiment (whether physical or emulated) of one or more versions of the ARM processor architecture" Does that cover JIT or not? If it does not (and though I am not a lawyer this is only a surmise on my part) then it may be possible to "emulate" an ARM processor but not translate the ARM code into x86/PowerPC etc as these would not be an imbodiment of an ARM. A very wierd and frankly ambiguous turn of phrase. I'd have preferred something unambiguous (one way or another). For the moment, and unless someone can clarify this, it would mean that someone could produce an emulator that does not translate (JIT) the ARM code instructions (so you'd be able to run RISC OS albeit slowly) but could not translate the code (making a speed gain) as would be the case with VARPC. So "old" Red Squirrel (sans JIT) would be legit - but VARPC (in part based on Red Squirrel - but using JIT) would not. If the intent is to prevent emulation from displacing actual ARM based RISC OS Hardware (a strategy I'd agree with) I think it doesn't quite close things down enough. Other than that I am happy enough.
lproven (+1.0) 19/5/07 2:29PM	It's not open source and it's not Free, and that is a great shame. Shared source is a con, really: commercial companies (such as Micros~1) are asking for you to donate your time, your effort, your help, to their profit-making enterprises, and in return, you get nothing except the right to play with their product. If you're lucky, you might even get a free copy. With Free software, you own your own work; you can do with it what you will, subject to the restriction that you must set your work Free as well. (I capitalise "Free" to emphasize it. We're talking "libre", at liberty, here, not "gratuit", "for-no-cost". Alas, English has only one over loaded word "free" which means 2 different things. French and most other European languages are better off and distinguish between "gratuitous, not for money" and "at liberty, unconstrained".) There is really no gain for Castle or anyone else in trying to keep control of RISC OS by not making it Free. So what if someone did make an x86 port? Firstly, there are already hundreds of x86 OSs out there. There are even dozens of lightweight Free graphical desktop OSs: AROS, Syllable, SkyOS, Haiku, Menuet, BlueEyedOS, CosmoE, Atheos, VisOpSys, ReactOS, etc. etc. RISC OS wouldn't even make a ripple. It is, I'm afraid, old-fashioned, idiosyncratic and limited. Secondly, Castle doesn't make x86 hardware so would not be in competition with any putative x86 RISC OS vendor. If someone enhanced RISC OS on ARM and sold that, Castle still doesn't lose: if the OS was Free, Castle could sell it too. If it believes it can't make competitive products, restrictive licensing won't help it. What if someone wanted to port RISC OS to PowerPC to run on the Efika? (Google it.) That would be a rival. Would Castle allow that? Shared Source is as it always has been, a timorous toe in the water for companies too scared to take the plunge and go Free. But sticking your toe in the water isn't swimming. It doesn't even get you wet. Going Free can have benefits, but you don't get those benefits from being less than Free.
AMS (+1.0) 19/5/07 5:52PM	lproven wrote>"It's not open source and it's not Free, and that is a great shame. " Not quite free might be enough though in this instance. I am not going to get into the "ideological" discussion of open source/versus closed commercial other than to say if whatever is done helps RISC OS continue and flourish on native hardware then I am all for it. lproven wrote>"Secondly, Castle doesn't make x86 hardware so would not be in competition with any putative x86 RISC OS vendor. " Let's think about that shall we. What if someone has a limited budget can afford one machine - one from Castle (ARM Based) and the other from an x86 box shifter that happens to supply "RISC OS on x86" what then? Nope you'll have competition - this already happens between them and VARPC - allowing people to simply compile to native x86 much of your OS would tilt the performance away from native towards x86 (to Castle's disadvantage and ours too IMHO). Remember the point of doing anything to liberalise the licensing is not to help OSS, nor to help x86 box shifters and it's not some ideological stunt. It has to benefit the RISC OS hardware and software platform - that's the measure against which I suggest it should be judged. If it doesn't do that then it IMHO shouldn't be done.
nevali (-1.0) 19/5/07 7:26PM	Not quite; it's to help the RISC OS software platform <strong>provided</strong> it helps the RISC OS hardware platforms. If Castle, et al, go out of business in a couple of years (which is a very real possibility given the state of the RISC OS marketplace), this license pretty much means that RISC OS would die with them.
AMS (+1.0) 19/5/07 7:48PM	*In reply to nevali:* That's a tad negative though isn't it? If the hardware vendors go "kaput" there would be little point in keeping RISC OS going would there? I can rattle off a few "emulated" systems such as CBM64 or Sinclair Spectrum - but really you can't exactly describe them as "alive" when they're just curios to show off to people in order to prove "look how fast my PC is it can emulate xxx" I also note you say "hardware platforms" - why the plural? I don't distinguish between any specific make of RISC OS hardware. The availability of a "native" platform (whoever makes it) is what counts. That having been said Open Sourcing RO5.xx probably benefits - in the short to mid term - Iyonix users more than A9 ones - simply because it's the OS Iyonix uses. Over time though there is no reason (other than time, effort and man/woman power) to see RO 5.xx appear on the A9 (or on other ARM platform). The RISC OS (IMHO) only has value while it's a real OS running on real hardware - the moment it becomes an "emulated environment" on some Windows based platform it would probably become time to pull the plug... no doubt others will disagree with that (as is their right).
nevali (+1.1) 19/5/07 8:29PM	No, it's not negative per se, it's merely realistic. This license specifically prevents any kind of porting effort, which means that an emulated environment is the only way you could ever see RISC OS on mainstream hardware (technical hurdles notwithstanding). With this license, if the hardware vendors go “kaput” there is absolutely no point in keeping RISC OS going—which would unquestionably be a great loss—whereas a more permissive license wouldn't close that avenue before it's ever become an issue. RISC OS advocacy isn't generally about a piece of hardware that the OS runs on (although the OS being blown into ROM is obviously a factor), it's about the OS itself and the applications that run atop. If you ignore—for the moment—the technical difficulties that would be involved in porting RISC OS to a different architecture, it really boils down to an opinion on the potential future of the RISC OS software platform. Legally, the shared source RISC OS is tied to ARM—not because of technical reasons that could hypothetically (given sufficient time and effort on the part of interested parties) be worked around, but because the people responsible for the OS have a vested interest in hardware sales of a platform that happens to be built around the ARM architecture. ARM doesn't make RISC OS particularly special, it's just what happens to be inside the machines that are built to run it. The use of plural was simply because I (and I suspect a fair few others) would consider the Iyonix and, say, the older A9 machines to be quite different beasts, and not a lot beyond that.
jamesp (+1.0) 19/5/07 8:52PM	*In reply to nevali:* who in their right mind is going to port RISC OS to a non-ARM architecture? You would end up with something which wasn't really RISC OS with no applications. If you want to run it on non-ARM hardware, use an emulator.
nevali (+0.1) 19/5/07 9:00PM	Anybody who wants to see the operating system have a significantly longer lifespan than that of the companies responsible for producing the hardware it runs on. This is about the future of RISC OS, after all. Think longer term.
thegman (+2.0) 19/5/07 9:13PM	Personally, I don't think the limitation to ARM restricts the potential for the growth of RISC OS. ARM is after the most popular/numerous processor architecture in use today, x86 included. It's true, ARM does not make RISC OS special, and you couldn't find a processor less suitable for use in a desktop computer, but desktop computers are not the be all and end all. The fact is, RISC OS cannot compete in any way on the desktop, we should probably all just accept that, if we have not already. The competition is too strong, cost effective, and superior to RISC OS in every way that matters. However, and it's a big "however", what RISC OS can do is compete in different markets, markets in which RISC OS could actually grow and even prosper. There is no shortage of ARM hardware like this: http://www.dataevolution.com/clio%20info%203.htm [Link: www.dataevolution.com] which would suit RISC OS very well, and the only competition of any note is Windows CE, much weaker competition than what exists on the desktop. The fact is that if I could only have my Mac or RISC OS, I'd choose the Mac in a heartbeat, if offered the choice of Windows CE or RISC OS, I'd choose RISC OS in a heartbeat, because RISC OS is probably the stronger offering. If we can get people to choose RISC OS on merit, rather than on fanboy-ism, that's a huge achievement for the platform, but it's a task too great on the desktop, but not on these types of ARM devices aimed at other, more niche markets.
nevali (+1.0) 19/5/07 9:22PM	It's certainly true that RISC OS right now can't compete on the desktop, but the very fact that people run RISC OS on the desktop right now and advocate doing it t means that there are lots of people who want to do just that—and presumably want to continue doing it. I suspect (and of course, I could be wrong), that most RISC OS users on the likes of Drove and TIB could probably care less about RISC OS in embedded systems in much the same way that many Mac users won't really care that the Apple TV runs a modified version of OS X. Most of the stuff talked about in terms of how wonderful RISC OS is [at doing x, or y, or z] has little to do with RISC OS in embedded systems, after all. If you want to make money, then yes, you need to pitch RISC OS at something other than the desktop. If you want to continue using RISC OS the same way that many have for years—that is, on the desktop—then it being limited to ARM will only take you so far.
jamesp (+1.0) 19/5/07 9:28PM	*In reply to nevali:* RISC OS is utterly tied to the ARM architecture. So much of it would have to be rewritten, there probably wouldn't be much left and you would have a new OS anyway.
nevali (+1.0) 19/5/07 9:36PM	That may very well be true, but right now the only way to accomplish that would be to port it blind: no part of the shared source release can be released as part of—for example—a clone of RISC OS for another platform. In fact, developing such an OS after looking at the sources would leave you wide open to potential legal minefield (much as the ReactOS folks point-blank refused to look at the leaked Windows source code a couple of years ago). A port of RISC OS is, of course, entirely hypothetical, but technical hurdles have always been overcome in the past if there's strong enough will to do it, but with the license as it is it can only ever remain in the hypothetical, and I think that unless things change, it'll one day come back and bite people.
thegman (+1.0) 20/5/07 12:18AM	I think a port of RISC OS to a different processor would be fairly pointless in the long run, RISC OS is a very dated OS, porting it to another CPU architecture is comparable to porting Windows 3.1 to PowerPC, would there really be a point? If you're willing to dedicate that sort of effort, you'd be better off writing an OS from scratch or take a modern kernel and base your OS on that. I've often toyed with the idea of cloning the RISC OS desktop on some other system, but lack the motivation to actually do anything about it...
hzn 20/5/07 7:04AM	In reply to several: If you want RO feeling on x86 you might want to try the ROX desktop on Linux.
jb (+3.6) 20/5/07 11:26AM	several: What you have missed, perhaps, is that the licence that is 'out' refers to what is currently released/given away. It does NOT rule out further licences for whatever reason. It is just that use on non ARM processors is not at this time given away for free.
hubersn (+3.1) 20/5/07 12:42PM	I think that porting RISC OS to another platform is - in the forseeable future - a silly thing to do. It only solves one of the basic RISC OS problems (price and speed of the hardware platform), and creates a few new problems. Running RISC OS on another platform via emulation however is very sensible, since it is capable of solving every RISC OS problem without creating new ones. Maybe Castle and ROOL also see this and just want to make sure that no effort is wasted in such a direction - after all, they have explicitly mentioned "emulation" as being allowed. The picture I have in mind is a host OS as the "virtual machine" which provides the hardware abstraction, and RISC OS running on it. There is so much to do in every part of RISC OS - let's just start the work instead of endlessly discussing the fine details of the licence. We have now the chance to improve major components of RISC OS for the benefit of all users out there.
hEgelia (+1.1) 20/5/07 12:47PM	I'd say what makes RISC OS still interesting on the desktop is its GUI, which has features unlike anything else on the market. For me, Mac OS X is a close second, but where I really need to be swift and productive, I choose RISC OS. Yes, even though some apps are generally 5 years or so behind. This, for me, also ensures a possible future for it. I think it would be very interesting to have RISC OS run natively on a more common platform, such as a x86 PC. For one thing, it would make the hardware substantially cheaper. Seeing the lightweight of the OS, I think RISC OS could really fly on modern PC boxes. Some ported apps, which probably already were really well written, fly on the PC - think about Xara or Sibelius. Still, this doesn't take away RISC OS is unable to compete when pitted against contemporary OS's in a non-ARM domain, such as an x86 OS. What has been discussed in the past and now by thegman, is to rebuild the RISC OS GUI on top of a Linux or Unix core. Essentially what Apple has done with Mac OS X. This could 'instantly' provide a lot of the modern base functionality sorely missed in the OS. I wonder how feasible that is. For now, this remains largely academic, but could prove an interesting route in the future considering a more liberal license is released, as hinted by jb.
Stoppers (+1.0) 20/5/07 1:47PM	*In reply to hEgelia:* Actually, it's called ROLF, and coming along fairly well, if slowly. I've recently updated the API, which has broken the GDK compilation (it still doesn't work properly when it does compile), and for some reason MPlayer plays everything upside-down, I just have to find the place to change a + to a -. I do think that it might be worth a look to anyone who can cope with a bit of compilation, etc. on Linux. The sprites have mostly been provided by Chris Wraight. Currently, I'm using my Drobe webspace, I'll move it if someone suggests somewhere better (or if Drobe object). http://stoppers.drobe.co.uk/ Simon
druck (+1.6) 21/5/07 10:49AM	*In reply to lproven:* "It's not open source and it's not Free, and that is a great shame. Shared source is a con, really: commercial companies (such as Micros~1) are asking for you to donate your time, your effort, your help, to their profit-making enterprises, and in return, you get nothing except the right to play with their product. If you're lucky, you might even get a free copy. " But we aren't talking about a company that makes millions (or billions) in profits trying to get us to do the work for free. RISC OS is more of a community than a commercial enterprise these days, with several of the major projects being open source based. People are already willing to donate vast amounts of their time and energy in application development, and the Castle licence allows them to put some of that effort in to improving the OS. Its only fair that the owner of the licence can still peruse the limited commercial avenues that are open to the platform, and after all spinoffs such work continues to provide us with native hardware, so we gain as well. As many have mentioned in future we may well have to abandon native ARM hardware for the desktop, but as JB says the licence isn't set in stone. A migration to x86 hardware is possible, first by complete emulation running over a host OS as we have now, but then gradually moving parts of the code over to the native architecture, forming an abstracted virtual machine to allow it run along side other OSs, and eventually supporting x86 application binaries for currently developed code (legacy code remaining under emulation of course). It would be a lot of work, and we'd have to decide if it was worth it, largely determined on whether application development can fore fill users needs.
jamesp 21/5/07 12:03PM	*In reply to guestx:* So when will we start to see the owners of the code ( or part-owners, or whatever ) acting as members of a community, rather than treating everyone as punters or willing fanboys?
druck (+0.9) 21/5/07 12:17PM	*In reply to guestx:* isn't it time you found something else to do, RISC OS obviously isn't of any interest to you anymore.
jamesp (+1.1) 21/5/07 12:22PM	Sorry, I didn't mean to do that - it turns out that clicking on "Show help" in NetSurf submits the page *In reply to guestx:* "So when will we start to see the owners of the code ( or part-owners, or whatever ) acting as members of a community, rather than treating everyone as punters or willing fanboys?" Isn't that's what is happening? Quite a bit of the newly released stuff is new to the outside world as far as I know. I could really have done with the the Real time support module last year! Additionally, the URL fetchers would be useful for a little project I'm considering now and haven't been available for 32 bit machines. Additionally, it allows people to fix bugs or add features/APIs to do what they want, instead of reimplementing something or using nasty workarounds. Your saying that they didn't go far enough. As I see it they've take a huge, positive leap, from which the 'community' loses nothing and has the potential to gain a lot - let's just see where it goes. As JB said, they can always become more liberal later if it suits them
jess (+1.0) 21/5/07 3:41PM	"PROVIDED THAT such work is only intended to be used in conjunction with an embodiment (whether physical or emulated) of one or more versions of the ARM processor architecture." What does this actually mean? I read it as an x86 port would be fine as long as it contains an ARM emulator to run existing code and modules. It says "used in conjuction with" as opposed to run on. If this interpretation is correct, then the license is very sensible.
2 comment(s) are below your moderation threshold. Login to view them.
Use the forum for more comments on this article