Should RISC OS be open sourced? - RISC OS News, Software and Information

Should RISC OS be open sourced?

Published: 15th Oct 2005, 13:20:18GMT Source: drobe.co.uk
By Chris Williams

Page 1 of 1

The big question the jury are still debating

Editorial The debate over whether or not RISC OS should be open sourced took another turn this week when Peter Naulls argued that "certain parts" of the OS could be released under an open source licence. The State-side coder behind various ports including Firefox said this would ideally include "crucial parts that affect all users, even if they don't realise it, parts that can be created from scratch and made much better than the Acorn original, and parts which can managed by specific developers who already understand them well."

Peter gave SharedCLibrary as an example. This is a critical component in the OS, as it provides basic, standard functionality to applications typically written in C, which is a popular language on RISC OS. RISCOS Ltd. and Castle ship different versions of the SCL module with their streams of the operating system, each with their own bugs and benefits. Application developers have to make a decision on which SCL version is required for their software, and political use of the SCL has irritated some. An open source version of the SCL could, Peter theorises, have alleviated these troubles. How an open source SCL is managed is an essential consideration though, as releases must be tested and tested again before software developers and users can rely on them.

His other suggestion that RISCOS Ltd. could open source parts of Select to assist in development and migration of RISC OS 4 to the Iyonix might cause others (particularly ROL management) to choke on their coffee. Although open source software projects have the potential to harness collaborative development and fault finding, there's still the psychological barrier that you're giving away work for free to overcome. There's no guarantee of profit or any sort of return on investment, despite the widely held belief that selling support is a good way to produce a cash turn over. Every so often we hear of companies who take the plunge and bravely commit to open sourcing their software, and it was Xara's turn this week. I'm personally sitting on the fence regarding the open source versus closed source debate, as it really depends on the circumstances of each individual project.

Paul Middleton, ROL MD, said, "It is one thing to release software as open source so that people can look at the source code and help sort out the troublesome problems that 'many hands can make light work of'. It is completely another to simply say that the source should be freely available to anyone to do with as they like."

He added: "It might be feasible to make Paint, Draw, etc open source but given the very limited amount of interest that the Printers+ release drew, I wouldn't make it a high priority, or put great expectations on it."

ROL released the source code to Printers+, the 'front end' of the RISC OS 4 printing system, in 2003, which was maintained by the late David Marston. During the legal stand off last summer, Castle made it clear that they preferred it if the Printers+ source code wasn't available. Paul also had reservations regarding the fragmentation seen in the open source world, such as the number of different Linux distributions and end user support nightmare entailed from that situation.

Whether or not a project is suitable for open sourcing could very well depend on whether or not the project can achieve a 'critical mass' of users. With suitable interest, it can be easier to entice programmers to contribute code and fix problems, which then attracts more interest. Minority, general purpose operating systems tend to be open source for various reasons, with perhaps the exception of SkyOS, and this includes BeOS influenced Haiku-OS which recently gained its first full-time employee.

When asked if small operating systems can only survive in the wide world by being open source, Haikunews.org editor Chris Simmons said, "I think making any project open source, including small OS's, lends itself well to development, so my first answer is a firm 'yes'.

"If Be Inc. had open sourced [BeOS] those many years ago there might have been a greater chance for success, only if they had truly focused on the desktop aspect and not ventured into the BeIA, focus-shift idea."

Of course, the debate on open sourcing RISC OS will continue to wage between free software idealists and old school developers. Meanwhile, the OS continues to be enhanced by a one way tide of open source code, from USB and graphics drivers to Internet accessibility.

Links
Comments?

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

[Printable] [Digg this] [Blog search]

md0u80c9 (+1.1) 15/10/05 1:55PM	Whilst I think this is an issue which will continue to rear its head, RISC OS's design means it is in a fortunate position of being able to travel 'the third way', without ROL or Castle having to do anything. The whole purpose of design of the modular system of RISC OS was so that components could be replaced easily. There is nothing stopping a developer or team of developers creating a clean-room implementation of a module which is technically superior to an existing component. In the past, we've seen a number of Pinboard replacements for example.
datawave (+0.9) 15/10/05 4:52PM	I totally agree with Paul and Peter about RISC OS being a open source, but NOT everything should be revealed as open source. Take for instance the Relocatable Modules, most of them should actually be a open source and some utilities as well, such like !ATAForm, because there is no support anymore for it, making it F+ compatible, that one for instance should be a open source, so that all RISC OS users, who use RAPIDE32 can benefit of this application and NOT some users.
steelpillow (+2.3) 15/10/05 5:40PM	One has to be careful in weighing the benefits against the risks, both for the wider RISC OS community and for the current owners of RISC OS and associated rights. The more code one opens up, the less Castle and ROL can justify the prices they charge. For them, opening up could destroy the way their businesses work. They would have to become more like service providers - but what services, and who to? By way of illustration, Haiku's first full-time codie will lose his job when the cash runs out at the end of November... Much as I believe that the long-term viability of RISC OS rests in engaging the open source community, it is difficult to see how we can get from here to there. Peter's suggestions are a good starting point, even if only for discussion. Paul Middleton need not release code for anyone to "do with as they like" BSD style. He could for example stipulate that they may not resell copies (as per the GPL), or that if they resell copies they owe him a license fee (as per the LGPL). A little creativity in licensing might even open up new revenue streams. Meanwhile, given the increasing influence of the Linux Standards Base and similar initiatives, I find it, uh.. let's say cute, that the RISC OS establishment should lecture the Open Source community on fragmentation and code forks.
guestx (+0.5) 15/10/05 7:19PM	*In reply to steelpillow:* "He could for example stipulate that they may not resell copies (as per the GPL), or that if they resell copies they owe him a license fee (as per the LGPL)." These are nonsense interpretations of those licences - it's perfectly acceptable to sell GPL-licensed software, and there's no payment obligation when distributing software licensed under the LGPL. Since those licences mostly address source code availability - the "free as in speech" factor - I suggest you read the explanatory materials on the GNU Web site instead of perpetuating unhelpful myths on the subject.
joty (+1.0) 15/10/05 9:25PM	It is pity that based on the experience of open sourcing Printers+, open sourcing other components like e.g. Paint and Draw are put on a low priority. The possible benefits (and challenges) of enhancing Printers+ (only the printing frontend, not the real drivers) is way less than final applications like Paint and Draw. And I'm always been very disappointed that only the printer frontend src code was available while we're in a desparate need (for >10 years) for enhancements e.g. in the PostScript driver. There is lots of possible and needed enhancements to be made there.
steelpillow 15/10/05 10:24PM	*In reply to guestx:* Perhaps I was a little over-brief on the GPL. One may not resell copies as part of a commercially-licensed program, though one may charge a fee for distributing them alongside, etc. etc. And I did misrepresent the LGPL, sorry (must have read that myth once too often). I was thinking of the dual licensing model used by Trolltech, MySQL, etc. Whatever, it doesn't change the fact that Paul and co. have plenty of options to consider.
NoMercy (+1.0) 15/10/05 11:20PM	"the number of different Linux distributions" Same programs, same kernel... only thing which is diferent is the way they manage the system and the packages for it. The fragmentation of BSD is probably a closer analogy, and after FreeBSD the others seem to be rather specialist (Open's secuirty, and Net's portability). Things which would help support on other platforms, eg releasing the ADFS code, so Linux can write to ADFS paritions safely would be useful, but releasing other bits in small ammounts I don't think will help. Unless there seriously concidering releasing the whole thing under something like the GPL, so code from other open source projects can be used in RISC OS... which might be useful, though once that's done there's no way back.
lostamarble (+0.8) 16/10/05 12:42AM	Assuming an Open Sourced RISC OS will be a boot (softloaded) option - this could bring about unintentional support for systems like the a5000 which have been stuck in ROS 3.1 for 10+ years, and after the price reduction of ROS 4.39 to encourage it's 'universal' adoption, thereby severing all links to Archimedes and AXxxx/ systems, there may be a few unhappy developers getting questions about long 'dead' hardware they never envisioned their software working on. If distribution of ROM sets in parallel with Flash ROM or boot loading images is not considered, will this be the final nail to force us RiscPC users to go out and buy an Iyonix ?
mrchocky 16/10/05 2:55AM	*In reply to steelpillow:* Again, the (L)GPL says no such thing. Please make an attempt to follow guestx's advice. For clarification against some of the other comments (in case it wasn't clear), I never advocated open sourcing the entirety of RISC OS, just parts of it.
druck (+2.0) 16/10/05 1:42PM	In reply to NoMery: there is no need for ADFS - or rather as you meant to say FileCore - to be open sourced in order to implement the filing system on Linux. The full specification has always been available, and if you can't implement it from that, the 1.3MB of hacked and hacked again ARM assembler in Filecore, isn't going help you one jot. But getting back to the crux of the issue, I don't making RISC OS open source would be beneficial, there just aren't enough developers to give it critical mass. There may be a few tinkerings round the edges by people interested in specific parts, but overall it wouldn't go anywhere. Not that is really has or is at the moment either, but I think it has more chance under commercial stewardship allowing it to be tightly focused on the needs of specific vertical markets, and not competing against open source alternatives such as Linux which are hampered by trying to be everything to erveryone. Thats not to say certain parts coulldn't be open sourced as Peter suggests, but this isn't to really take advantage of public access to the source, but rather as a mechanism to allow code to be integrated by both Castle and ROL OS variants, outside of the framework of commercial agreements which may or may not be fully honoured at this time.
steelpillow 16/10/05 6:48PM	*In reply to druck:* How can RISC OS compete long-term, even in vertical markets, if it gets increasingly left behind? Wouldn't an eventual opening up of the core source be likely to attract new talent? But I agree that the commercial route is the only short/medium term hope. It'll be interesting to see how the Xara experiment goes. In reply to mrchocky: Anybody who cares to pick such OT nits may find the GPL at http://www.gnu.org/licenses/gpl.html and judge for themselves if my ramblings make sense.
mrchocky 16/10/05 7:01PM	*In reply to steelpillow:* If it is OT, then why do you continue to mention it? However, it clearly is on topic, as the most well-known OSS licenses, and people ought to be reading the FAQ: http://www.gnu.org/licenses/gpl-faq.html which explains very clearly what can and cannot be charged for and under what conditions. *In reply to datawave:* ATAForm is not part of RISC OS; it is one of a a mutlitude of pieces of 3rd party software for which the developers have long since lost interest in the market, and would hardly be of any interest to them to release source code to, even if they still had it. Besides, RISC OS needs a proper generic formatter, that isn't tied to a specific filecore filesystem, otherwise we continue to reinvent the wheel, as Castle did for the USB/SCSI formatter. Here's the original article link, btw: http://riscos.blog.com/356092/
CJE (+1.0) 17/10/05 12:06PM	To be honest this discussion is a waste of everyones time, even if both Castle and RISCOS Ltd agreed to it, it would need Pace to agree to it. Castle have said that whilst they now own the RISC OS IPR, Pace included a requirement in the sale that the OS Sources would never be released. This was good business practice on Pace's part as they wanted to keep thier customers coming back to them. I know there was quite a lot of problems making sure that the sources for Printers+ did not include anything that had to be kept private!
mrchocky 17/10/05 2:04PM	*In reply to CJE:* I hardly think that protoming orignal discussion and clarifying important concepts is a waste of anyone's time. It's certainly far more constructive than rehashing old arguments. As for the OS Sources never being released - please read my orignal article, I never said anything like that.
stewart (+3.2) 18/10/05 10:25PM	If critical mass is ... critical, then you've got no chance - IMHO, there just aren't enough[] people who know enough about ARM assembler and the internals of RISC OS well enough. On the specific point of knowing the internals well enough, this point is similar to the point made in the blog article near the end where it talks about interactions between modules in the OS that are not necessarily obvious. One really has no idea without having seen all the sources and how they fit together. Furthermore, developing code that is agnostic to OS variants is a much more difficult problem nowadays as you've got so many to choose from - it was hard enough when it was just one core OS when we were Acorn, but now it'd be a much harder job. [] Please note: I didn't say that there were none
CJE 20/10/05 12:06PM	*In reply to mrchocky:* You are quotes with: "Peter Naulls argued that "certain parts" of the OS could be released under an open source licence." Even if it was only 'certain parts' it would still need Pace to agree, and I have now realised that it would also most likely need Broadcom and MSDW holdings to as well, that will never[1] happen, so it is only an academic argument! [1]I rarely use the word 'never' but I unfortunatly believe that this is a certainty
egel 21/10/05 3:21PM	I think it is beter the other way around: RISC OS should use (more) open source parts, like drivers, modules and utils. When I read GPL right that is possible with the right wording in the license on the non-free parts and the availability of non-free alternatives. In that way a completelly non-free RISC OS would still work but not as good as the mixed version.
1 comment(s) are below your moderation threshold. Login to view them.