Software Licenses

Adaptation and translation of the guidelines and recommendation I've written for a Dutch academic not-for-profit organisation in 2015, with some updates in 2017. I've replaced the name of the organisation with "Your Organisation".

Recommendations

 * Publish software written at Your Organisation with an Apache license, version 2 or higher.


 * Publish slides or published reports or articles presented by Your Organisation with a creative commons attributions license, version 4 or higher (CC BY 4.0)


 * When editing previously published works (software, slides or reports), use the already applicable license, but pay attention to license incompatibility when using the GPL license.


 * If your publication contains photos (or other elements) made by someone else, make sure you have permission to use those sources, and state the source in your publication.

Apache 2 license
Include in each source code file (.c, .py, .rb, .java, etc.) the name of the author, version or revision (and / or publication date), and the following license text:

Copyright Your Organisation

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to writing, distributed under the License is distributed on "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OR ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Note that the copyright holder is Your Organisation, not of the author (the employee who created it). Hence the advice to mention the author separately from the copyright holder and in addition to the license.

Creative Commons license
Include a creative commons logo and/or this texts in each publication:

https://licensebuttons.net/l/by/4.0/88x31.png

This work is licensed under a Creative Commons Attribution 4.0 International License.

This line is taken from http://creativecommons.org/licenses/by/4.0/

The recommend place is a colophon slides with this logo and your contact details at the end of your slide deck.

Deviation from the preferred license
It is possible to deviate from the preferred licenses (Apache and Creative Commons).

If you work in a joint venture (a project with people from different organisations), and a different license has already been chosen, it is usually advisable to follow that license.

Other alternatives such as the MIT license, 3-clause and 2-clause BSD licenses and ISC license are more 'lightweight' than the Apache 2 license, and can also be used.

The GPL license can also be chosen, provided that the risks outlined below are sufficiently clear.

Licenses other than those mentioned above are generally not recommended.

More information about the various open-source licenses can be found on Github's http://choosealicense.com or EUdat's https://ufal.github.io/public-license-selector/.

Intellectual Property in Partnerships
When entering into a partnership, it must be decided in advance how to deal with the intellectual property contributed by the partners, both intellectual property created prior to the prior to the project, and created within the project.

This (software license) recommendation does not determine how such an agreements should look like. If necessary, the Netherlands eScience Center (NLeSC) policy towards publishing licensing and intellectual property can be used as a guideline.

Justification
The knowledge and software developed by Your Organisation was paid (indirectly) by contributions from the general public. These publications can help others in their work. In addition, republishing can increase the brand awareness of our organisation.

The commercial value of most software and publications is limited, and our organisation is not focused on exploiting this.

It is therefore in the interest of our organisation that the software, presentations and reports published by it are widely distributed. An open source license is therefore the most suitable license.

Copyright
All software and documents are copyrighted, even if there is no license. The rightful claimant of all work-related software and documents made by Your Organisation employees is Your Organisation. So there is a difference between the rightful claimant (Your Organisation) and the author (the Your Organisation employee).

More legal background can be found for example on the website of Arnoud Engelfriet: http://www.iusmentis.com/ (in Dutch)

Other rights
In addition to copyright, other rights may also be involved, such as database rights, patents and trademarks.

Open source software does not have to be free of rights. The FFmeg library for MPEG-4 / H.264 video is open source, but for commercial use the MPEG LA requires a patent license.

Most software arranges other rights outside of the software license. For example, it is possible to register the name or logo of an open source product as a trade name.

The Apache 2 license also regulates patent law in addition to the use of copyright. In addition, there are restrictive conditions for reusing the name in a commercial product.

License categories
Below is a subdivision into license types for software:


 * Closed source licenses
 * Open source licenses
 * Copyleft licenses, such as GNU GPL and Creative Commons share-alike.
 * Permissive licenses, such as MIT and BSD and Creative Commons attribution.
 * Public domain

Licenses such as MIT and BSD are permissive, they have few restrictions, and allow commercial reuse, even in closed source spin-offs.

The GNU GPL is a copyleft license, also referred to as a 'free software' license. This is a restrictive license, and allows much less reuse. The underlying reason is activism: by limiting reuse to republishing under the same license, it is guaranteed that derived works are also open source.

The risk of using the GNU GPL is license incompatibility.

License Incompatibility
If two programs are published under a different license, and these two licenses contain conflicting conditions, then there is a license incompatibility. In that case, it is possible for the user to use the software, but it may not be republished: the conflicting conditions mean that it is not possible to devise a license that meets both original licenses.

Particularly due to the different restrictions in the GPL, it is sometimes not possible to combine GPL-licensed software with other software, such as with OpenSSL (the OpenSSL license contains a condition that conflicts with the GPL license.) This is why the library the GnuTLS library has been completely rewritten, so opting for an unfavorable license can result in a lot of duplication).

Another conflict is between the GPL version 2 and Apache version 2 licenses. GPL version 3 is compatible with Apache version 2.

In particular, it is also not possible to combine GPL version 2 software with GPL version 3 software, because GPLv2 and GPLv3 are incompatible with each other. For example: the Linux kernel is only published under GPL version 2. It is therefore not possible to include a driver in the Linux kernel that has been published under a GPL version 3 license.

The advice is to publish the software under multiple licenses when using the GPL, namely GPLv2 or higher or GPLv3 or higher:

Copyright (C) Your Organisation

This program is free software: you can edit and / or modify the GNU General Public License as published by the Free Software Foundation, or 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 a copy of the GNU General Public License along with this program. If not, see .

Reciprocity
As long as there is one copyright holder of a work, the work can be re-licensed. There is then a dual license (previous users may continue to use the previously published version under the original license).

As soon as a third party makes a contribution to the work or the software, it will generally do so under the same license. It is therefore important that a (good) license has been chosen before that time.

The risk of a restricitive copyleft license is that external contributions also have a restrictive copyleft license, and the end result is more susceptible to license conflicts.

The risk of a liberal open source license is that external contributions are not required to release their source code.