When someone writes software, the resulting intellectual property (software and documentation) is protected by copyright law, just like a literary or artistic work.
Owning the copyright in a piece of work, whether a book or software, means that the owner, usually the original authors or their employer, decides who can copy it, adapt it and distribute it. By default, only the owner can do that. Anyone who copies, changes or distributes someone else’s work without permission can be subject to legal action.
Therefore, the permission to use, copy, change, or distribute a software can only be granted through a licence.
In Europe, the licence is generally considered as a contract between a Licensor (the author of the software) and a Licensee (you, the user of the software, who can then use it according to the licence terms). Note that if you do not agree to the licence terms, you normally do not have the right to use, copy, change or distribute the software. If you do this without agreeing to the licence terms, you are violating copyright law.
All projects hosted on Joinup must be distributed according to Free or Open Source conditions. We consider the two terms as synonyms, even if “Open source” is the most used by economic operators and administrations. We often use the acronym “FOSS” (Free/Open Source Software).
FOSS licences comply with four freedoms expressed by the Free Software Foundation (FSF):
Licences may be “copyleft” (you must reuse the same licence if you re-distribute) or not
With more details, another non-profit organisation, the Open Source initiative (OSI) has implemented the Open Source Definition (OSD) based on 10 principles (see: www.opensource.org/docs/definition.php)
While the four freedoms above are present in all FOSS licences, other conditions strongly differ:
The Open Source Initiative (OSI) maintains a (already too long) list of about 60 “approved licence”. The effective number of existing “OSD compliant licences” may be 10 or 20 times higher (due to a phenomenon of licence proliferation during the last years). However, the certification as “OSI approved licence” is the most convenient (i.e. for FOSS requirements) as it covers most practical cases and exempts from tedious analysis of licence texts.
Inside the OSI list, the most used licences represent a kind of FOSS licensing standards or “best practices”. The following reduced list is based on the 2006 OSI Report of licence proliferation, complemented by two more recent licences, the EUPL and the GPLv3. Our own classification in three groups is indicative. You will find additional support in the licence wizard and by reading the text of these licences
When launching a FOSS project, it may by useful to sign with participants a specific contract, in order to aggregate and assign the copyrights of open source code in favour of a single sponsor. The CA may authorise the sponsor deciding alone about the participation of new “contributors”, the opportunity of public distribution, the licensing conditions (one or more acceptable licences could be defined in the agreement, however the sponsor could have the right to change the licence, to adopt a new licence version, to authorise dual licensing, to publish a FOSS exception list for larger works etc.).
The disadvantage of CAs is that potential contributors may refuse to enter a community where one member has more rights than the rest (Authors equality in an open, meritocratic oligarchy is a key to FOSS success). Another risk is project appropriation in case the sponsor sells its rights to a third party (or is purchased, merged with another economic operator).
Projects like the Linux kernel or Mozilla where successfully developed without any CA. However, without unique sponsor, these projects may be subject to intensive forking and updating their licence may become impossible (lack of unanimity between many authors).
On the other hand, a CA looks legitimate when a specific sponsor provides the bulk of the work and/or budget a project may need to survive.
A branch of the solution is making the community itself (i.e. in the case of a community hosted by a non-profit Foundation) the beneficiary of the aggregated copyright, or ensuring that the sponsor is non profit by nature: a CA is therefore most appropriate when a public authority (European institution, government, municipality) defines the requirements and organises the sponsoring of a FOSS project (possibly including some way to pay the work of contributors).
Another branch of the solution resides in the provisions of the CA, which may provide warranties about community management and licensing (a limited list of licences, “OSI-approved only” etc.)
A group called Project Harmony is working to present best practices in the matter of CA. Pros and cons of CAs are discussed there.
Contracting a NDA may appear like the contradiction of any open source approach, where the principle is source code publicity.
However, in early development phase and as long some maturity is not reached, it may be necessary to maintain source code disclosure inside a limited circle of participants. This could be the case for public sector projects where security aspects are important, or when adopting FOSS development methods inside a restricted circle (or club) participating to software mutualisation.
NDAs could be implemented as a part of contributor's agreement, during a transition period.