2.1. Choosing a Project

In many cases, you will have a choice of several projects to port, but on some occasions you may not have to make a choice at all – the project may be selected for you or perhaps you're the author of an original project that you want to port. Where there are multiple projects available, it is often possible to make an initial selection purely by examining project websites and documentation.

Making a selection is not an exact science and depends on a number of personal and technical preferences, such as whether you are familiar with the software as a user, or are more comfortable with C than with C++.

Figure 2.1. The porting process

Here are some other things to bear in mind when making a selection:

• Is the project actively maintained?

  There is a lot of 'abandonware' out there, software which is unfinished or at best only beta quality. Trying to fix bugs in the original code could be very difficult unless it is well documented (which is very rare) or easy to understand.

• How many people were involved in the project?

  The vast majority of open source projects are developed by one or two people. Projects with multiple contributors tend to be better documented (or at least commented) and follow better engineering practices.

• Will you have co-operation from the original authors?

  If the original authors or current maintainers of the project are supportive of your port, they may be able to give advice or even do some of the work for you. For larger projects it is always worth making contact at an early stage, particularly if the aim is to re-integrate any changes.

• Has the project already been ported to other platforms?

  The more platforms a project has already been ported to, the easier it is likely to be to port to another one. This is because the platform-specific code should have been separated from portable code during previous ports.

• Is the project suitable for your target hardware?

  Factors to consider here are both practical (e.g. screen size and input method) and technical (e.g. required processing power and RAM and use of floating-point arithmetic).

• Are there any dependencies?

  Open source projects often build upon other open source libraries. Proprietary projects might use third-party libraries with commercial licenses. Are the libraries used in the project already available on the Symbian platform? If not, will you have to port them too and can you legally do so? Many commonly used libraries are available on the Symbian platform (see Chapter 4).

• What license is the project distributed under?

  If you (or your company) own the copyright to the code then this is not an issue: you can use the code in any way you wish. For open source projects, there are hundreds of different licenses available and you need to be careful not to violate the terms of use. One of the main issues is the strength of any 'copyleft' clause, which broadly divides the licenses into three categories:

  • unrestricted (you can keep any changes to yourself), e.g. Apache and BSD licenses

  • weak copyleft (you must release the original code and, in many cases, any changes under the same license but you can add or link with proprietary code), e.g. LGPL and Eclipse licenses

  • strong copyleft (you must release the source for any project which uses this code under the same license, typically using one of the GPL versions).

If you are using open source code in a commercial project then you need to check the license details very carefully and it would be wise to have your company's legal advisors give approval to proceed. However, even open source developers need to be careful as there can be incompatibilities between licenses which prevent the combination of source code licensed under different terms.

Symbian Foundation Open Source Licensing A specific license worth looking at in more detail is the Eclipse Public License (EPL)[] selected for the Symbian Foundation code-base. This is a weak copyleft license that specifically allows proprietary extensions. Any changes to EPL-licensed code must be released under the same license. Additional modules, plug-ins or applications can be distributed with EPL-licensed code under any licensing scheme that is compatible as long as the additions or modifications would not be considered a 'derivative work' under US Copyright Law. Guidance from the Eclipse Foundation is that copying EPL-licensed code with a few minor modifications creates a 'derivative work', while writing a new module or plug-in with your own code that merely interfaces with EPL-licensed APIs does not. In scenarios between those two extremes, it would be wise to seek legal advice if there is any uncertainty as to what constitutes a 'derivative work'. The GNU Public License (GPL)[] is very popular in the free software community and, in fact, the Linux kernel is licensed under version 2. Code licensed under the GPL cannot legally be combined with EPL-licensed code. So Symbian Foundation code cannot be included in a GPL-licensed project. A GPL-licensed project can only be ported to the Symbian platform if all of its dependencies fall under a 'system library' exception clause[] in the appropriate version of the GPL. Essentially, this means that if you are developing purely against a public SDK and don't need to distribute any additional EPL-licensed components with your executable then it should be fine.

^[] The EPL is available from www.eclipse.org/legal/epl-v10.html.

^[] The GPL is available from www.gnu.org/copyleft/gpl.html.

^[] See www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs for the exact details.