Shared Source FAQ
- Can I help?
- What is shared source RISC OS about?
- How is the shared source project organised?
- Is this “Open Source”?
- Why haven’t you used the GPL?
- How does the dual-license work?
- Which RISC OS components will be available?
- Why have you selected these components to release first?
- What tools do I need to build these components?
- Can I include a RISC OS module in my free application?
- What does “publishing” mean?
- Can I include RISC OS sources in my commercial program?
Can I help?
If you are interested in helping ROOL with the shared source RISC OS project, take a look at our recruitment page.
What is shared source RISC OS about?
The primary objectives of sharing the sources to RISC OS are to bring RISC OS software to a wider community and to encourage growth in both the RISC OS user and developer communities.
We hope that by doing this we can promote more rapid development of the software base and remove the barriers to use normally associated with proprietary platforms.
How is the shared source project organised?
The shared source RISC OS project is maintained by RISC OS Open Limited on a not-for-profit basis with Castle Technology Limited. We are doing this because we believe that RISC OS is a valuable technology which should be available to the widest global audience possible. There are lots of documents on this web site which explain more about this project.
It is important to remember that although ROOL are acting as the public front to the shared source RISC OS project, we are not the owners of RISC OS. The sources belong to Castle Technology.
Is this “Open Source”?
The phrase “open source” is widely used and misused. For that reason, some people have taken steps to define it more formally. Take a look at www.opensource.org for the ‘official’ OSI definition of “open source”. From that definition, it is clear that the shared source RISC OS project is not open source for the simple reason that it makes a distinction between people who want to use or access the RISC OS sources for non-commercial purposes and those who want to use them for commercial purposes.
There are some people who hold very negative views of anything which is not ‘pure’ open source. In fact, some argue that a shared source scheme is no better than proprietary closed-source. We at ROOL feel that such arguments are unfounded; they fail to recognise the huge benefit to developers in being able to actually see the source code to the APIs with which they want to interact.
It is also of great value to be able to submit fixes and extensions to RISC OS components if doing so helps you to get your software to work the way you want it to. In that respect, the RISC OS shared source scheme presents no more of a barrier than pure open source.
Why haven’t you used the GPL?
This subject is complex and the full reasoning behind the choice of license terms is beyond the scope of this document. Below is a brief overview which should at least outline some of the reasons.
Selecting the correct license terms under which the opening up of access to RISC OS sources is being done is not an easy process. The most fundamental rule is that no matter what opinion anyone else has on the matter of licenses, this software belongs to Castle so the ultimate decision is theirs and theirs alone.
ROOL and Castle have looked at a large number of source-opening models and licenses and one of the most well known is the GNU General Public License (GPL). This is not the license under which RISC OS is being made available. In our experience with real-world customers who want to base their software on RISC OS, the GPL would prohibit its use because they want to keep their intellectual property their own. After all, that is what they hope will give their product the edge in the market.
It’s also clear from looking at the GPL that it has no real concept of RISC OS relocatable modules. The GPL expects a Linux-like system when applied to an operating system. This would make understanding scope of its effects very difficult in the case of building a complete RISC OS ROM with some of the Castle shared source modules and some a mixture with others completely independently developed.
How does the dual-license work?
In simple terms, we want people to be able to view and use the sources to RISC OS. If you want to release software free of charge and that software includes some or all of the RISC OS shared sources, you can do so with the condition that you publish the RISC OS sources that you used (along with any modifications you made) along with your software. We encourage you to submit useful changes back to ROOL for incorporation into the main source tree to benefit all RISC OS users, but you are under no obligation to do so.
If you intend to sell your product and that product uses some or all of the RISC OS shared sources, you must pay a royalty fee to the owners (Castle Technology) per unit shipped. In this case, you do not have to feed back or publish your changes to the RISC OS sources – although you are still encouraged to do so as this would not only benefit the rest of the community but provide a richer RISC OS for you to use in future.
Which RISC OS components will be available?
In order to keep the workload down, there will be a phased release of sources over the coming months. The first set to be released under the dual-license, shared source scheme will be:
- The RISC OS build environment
- The Shared C Library
- The main disc-based applications (Paint, Edit, Draw, etc)
- Other disc-based applications (Boot, System, Scrap, Unicode, Configure)
- Browse, WebServe and related Fetcher modules
- The USB Printer Manager, printer drivers and printer dumper modules
- The configuration plug-ins
- Some screen savers
- Other modules which are handy for developers
The more support and encouragement we get, the sooner we’ll be able to add to this list with even more of the RISC OS source tree.
Why have you selected these components to release first?
The process of opening up access to the RISC OS sources is a tricky and time-consuming one. The further down into the core of the OS you go, the more bits you find in there that mention or relate to confidential projects from the past and present.
So we have had to make a choice about what we can release first with the least effort in order to judge the reaction from the community. Also, we wanted to select components which would potentially be of immediate use. Here are some examples:
The printer drivers
It is accepted that there have long been limitations in the RISC OS printer drivers, such as the maximum supported resolution. Opening up access to the sources will allow developers to address this problem, the results of which would be a benefit to all.
The Shared C Library
This is a module which provides fundamental support to programs written in compiled C. The forking of OS development between Castle Technology Ltd and RISC OS Ltd has lead to problems due to incompatibility between the two different C Libraries. These problems will hopefully soon be a thing of the past.
This browser has had some ongoing development right up to the recent past and works on 32-bit machines, such as the Iyonix. It might provide an interesting reference to other RISC OS browser projects.
Browse also contains a number of features which are unique (or were at the time of their being implemented) to RISC OS applications – one of which being PDF export.
All of this is potentially valuable to the developer community and users alike so we wanted to include this in the list of first components to release.
The Fetcher modules
These are part of the Browse distribution but are useful in and of themselves because they make it extremely easy for you to perform fetches (and uploads) using a number of protocols, such as HTTP and FTP.
One trivial example of how this could benefit a developer is that you could include some of the Fetcher modules with your application and implement an online update mechanism very easily (i.e. fetch an update manifest from your web site, check it against what is currently installed and then fetch the update archive if needed).
For that reason alone, it’s well worth releasing these modules and their sources.
Some modules for developers
There are quite a few modules which have stayed in-house during the development of RISC OS but which we’ve always wanted to see out in public because they are so useful. Finally, we have the chance not only to release them but to open their sources for improvement.
The main disc-based applications
These will be amongst the first to release because it is quite easy for us to do so – they haven’t really had any use in the more confidential embedded projects as they are aimed at the desktop market. We also believe that they are interesting to developers as examples of how to write RISC OS desktop applications, mostly in C.
Finally, if there are any features which you are really itching to see in the RISC OS 5 desktop tools, now will be the chance for you to add them.
What tools do I need to build these components?
All of the RISC OS components in ROM and disc builds for Iyonix are built with the Castle C/C++ tool suite. This is an historic state of affairs which has been of benefit to development because we could develop sources and the tools hand in hand. ROOL hope to improve availability of the Castle C/C++ tools to make it easier for RISC OS developers to build the components as they were designed to be built.
Another popular set of build tools available for RISC OS is the GCC SDK suite but none of the RISC OS components have ever used this for the simple reason that they never needed to. However, as the GCC SDK is available free of charge, we expect that at least some of the work which is done by the RISC OS developer community will be to make any modifications required to allow the shared source components to be built using the GCC SDK.
The modification of the shared sources to build with the GCC SDK would be more than welcome. However, please ensure that in doing so you don’t stop the component from building with the Castle C/C++ tools. ROOL will include changes to software only if those changes do not break the software for the rest of the community.
Can I include a RISC OS module in my free application?
Yes. You must publish the RISC OS sources for the module you used, including any modifications which you made. It is important to remember that those sources remain the property of Castle Technology and fall under the same license – you cannot simply re-publish them under your own license terms.
A formal license will be released due course.
What does “publishing” mean?
Whether you’re developing commercial or non-commercial software, you are free to publish the shared RISC OS sources. Publishing your source code usually means you make code available on a Web site, either for its own sake or included in an archive along with your own software. The Web site does not have to be yours – for example, you may choose to use one of the many public source repository sites.
If you use parts of the RISC OS shared source in unmodified form, it is sufficient to ensure that your software documentation describes the exact parts and revisions used.
ROOL will provide a mechanism for accepting submissions from you for changes and additions to be made to the shared RISC OS sources so that they can be folded back into the ‘official’ source tree on the ROOL web site.
Can I include RISC OS sources in my commercial program?
Yes. The dual-license scheme means that commercial software can also use shared RISC OS sources. You do not have to publish those sources or any changes you make to them. You do, however, have to pay a royalty fee to Castle Technology for each unit you ship.
This system is much simpler than the way you would traditionally have had to do things; you would have had to negotiate license terms and fees with the owner of software (Castle). It’s also considerably cheaper.
A formal license will be released in due course.