Google+

FLOSS Checklist: Open Source your project in 5 steps

 

FLOSS Checklist: Open Source your project in 5 steps
by Andreia Palma 6222 views

PROSE aims to get projects onto Open Source Projects, and to support them in open sourcing their software under a FLOSS licence. Once the decision to to go Open Source is taken, there are a number of steps required to actually distribute the software. To facilitate this process we’ve compiled a streamlined list of steps that projects must take, helping remove any  barriers that may stand in the way of sharing your software. There are 5 key steps to ensure that your project is ready to go open source. These steps define the PROSE FLOSS Checklist, which provides a quick guide towards open sourcing a piece of code.

The PROSE Open Sourcing software checklist

We’ve put together a checklist that helps you through the steps required to open source your software. Just download the PROSE checklist and start open sourcing your software today. While there are complex decisions behind each step, once those decision are taken there are very concrete and practical steps that will ensure your project is ready for sharing openly with other developers and contributors .To better understand the list the overall steps are provided below:

1. Copyright

In FLOSS as with any other code, copyright  may protect the rights of the person (or persons) who has created the code. The details of the copyright holder(s) should be displayed in the software header as a copyright notice . This is done in the COPYING file which should be created and added to the project source code. This information usually contains the main project contributors, who owns each part of the project’s code as shown in the example below:

Copyright © <year>, <copyright owner(s)> 

Depending on the Licence that applies to code it may be necessary to show copyright notice when running the software, along with the software licence. This information is  usually contained in the Licence text (so read it carefully). It will be something you should consider when you decide which licence to chose for any code you wish to open source.

2. Licensing

Agreeing on the need for a licence is the starting point for the licensing process. There are several sources that help you select an adequate licence. The PROSE licence guide (H3.2) or App (to be released in May – watch this space) are a good place to start. Once you have chosen a licence for your project, the actual software must reflect that.  A file containing licence’s a link to the licence as well as the notices and authorship must be added to the project. This file should be named LICENCE and should be placed in the top-level directory of the project’s distribution. An example of a licence file according to the GNU General Public Licence Version 3 would look like the following:

<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

The required content of these files may also be found in each licence’s web page, e.g.: http://www.gnu.org/licenses/gpl.html#howto
Alongside the copyright and licence files, all source code files also need licence headers, as explained below.

3. Header files

The third step requires adding licence headers to each relevant code file, with the names of the original creators and a link to the licence or the licence text. (If you are part of an EU-funded project, a notice should be present crediting the EU, along with the projects contract number, similar to what appears in R&D papers.) This should be done for source code files (e.g. *.c, or *.cpp), as headers are not required (and can’t be copyrighted). All code files should contain the copyright notice and authors as the code is jointly owned.
The contents of these headers should be equal to LICENCE file contents, in the shape of code comments, according to the language being used.

Another file that should be issued along with the software is developers’ contacts (step 4).

4. Contact

Adding contact information will ensure that any contributors or users can actually reach the project developers. This information should be added in the AUTHORS file, including names and email addresses, which should be added to the project’s root folder. An example of its contents follows below:

Harris Smith <harris.smith@company.com>

All of the remaining steps are optional but will contribute to the success of your project:

5. README file (OPTIONAL)

The README file contains information about what the software is, what it does and what it is useful for, list reused third-party resources, link to external resources, such as project’s website, and other useful information. The README ensure your project is easily understandable, making it easier for fellow open source developers to contribute.

6. INSTALL file (OPTIONAL)

If you can’t actually build the software, it will be very hard to contribute to it. Therefore, the INSTALL file should contain all of the necessary instructions on how to build and run your project,  critical to any user or developer. This includes instructions on how to build, when necessary, and install the software for all supported operating systems.

7. Changes file (OPTIONAL)

Add all changes history to the CHANGES file. This file is optional, specially if you use a version control system (such as GIT or SVN), but is in any case recommended to provide information on the history of changes (important ones) made to the software code. Changes can be improvements, fixes or new functionalities. Each change should specify version and release date.

8. Share

Once your project is ready for public release you need to get share it with the world and as its open source you will want to share the Source Code as well as the binary. The last step involves uploading your project to a public repository.  The best way to achieve this is to create a project in a repository hosting website then once you have created a project, upload your Source Code. Pick a platform that ensures visibility for your project which will expose it to the right community. For EU-funded projects (FP7, H2020) we recommend checking out Open Source Projects, which supports GIT and SVN, but other options are available. Make sure you are comfortable with the platform you choose, and take some time to get to know it. If everything goes well, you’ll be using it daily!

And there you have it. Just download the PROSE checklist, and start open sourcing your projects today with our help. You may need to take specific technical and legal advice later, but this blog will get you started.

 


Comments (1)

PROSE will contribute to the adoption of open source software on ICT projects, by increasing the lifetime of the software developed inside European projects and thus maximizing impacts. This will be achieved through the creation of a coordination platform for hosting software projects, as well as promoting dissemination and training events on Open Source topics.