Software Licensing
talks about: Software and License
The Software Freedom Law Center[1] defines the following common approaches to copyright handling in software projects:[2]
-
per file handling
-
centralized
SFLC explains that no copyright information does not yield copyright. Thus no copyright header is preferred way to go since it minimizes maintenance work. No yearly updates have to be performed. Future contributors do not have to be added manually, your version control system handles that way better than you anyway.
CC tells something about license headers for files.[5]
Atwood suggest to pick any license.[6]
Recommendation
Follow the suggesting of the FSF and pick the Creative Commons Zero license.[4]. Compared to similar licenses like the WTFPL[7] or UNLICENSE[8] which are often critized for their lack of legal language, the CC0’s only downside seems to be a missing OSI[9] stamp of approval[10]. The problem here is that the CC0 does not grant any (implicit) trademark or patent rights, thus placing users of your software in a position where they can legally use your software but are forced to pay royalties for using your patent implemented by that software.[11] In order to solve that problem, place all your trademarks and patent rights under the same CC0 license. If that is not possible, use the CC0 in your advantage and simple fork the software and re-release it in whatever license, whatever user requires. Cut down on maintenance by using a multi-license approach.[12]
The CC0 license is probably not DFSG[13] compatible because of the above issue. If you plan on release software into Debian repositories, use the mentioned multi-license approach. A short license like the ISC[14] is DFSG compatible and won’t clutter your LICENSE file.
|
Apply the following setup to your project in order to use the CC0 license. The setup is intended to reduce ongoing maintenance work with regards to copyright information while still supporting multiple contributors.
1) Use the following header for all source files. Replace $MY_PROJECT with the name of your project.
This file is part of $MY_PROJECT. It is subject to the license terms in the LICENSE file found in the top-level
directory of this distribution and at http://creativecommons.org/publicdomain/zero/1.0/. No part of $MY_PROJECT,
including this file, may be copied, modified, propagated, or distributed except according to the terms contained
in the LICENSE file.This header does not contain the typical copyright fragments, like the year of publication or the author. The SLFC[2] explains that missing copyright information does not void your copyright at all - thus it can be safely removed. Instead the file header simply redirects the reader to the LICENSE file in the root of the project.
2) Add a file called LICENSE in the root of your project which contains the CC0 legal code (copy).
Add any additional licenses to that same file if you follow a multi-license approach. Creative Commons suggest to call that file COPYING in order to highlight why you should be interested in reading the file, however LICENSE is more widely used and better supported by various tools.
3) Use the following shields.io badge for your project to make it shiny:
# in asciidoc
image:https://img.shields.io/badge/license-cc%20zero-000000.svg?style=flat-square["CC Zero", link="https://creativecommons.org/publicdomain/zero/1.0/"]
# in markdown
4) Place the following text at the bottom of your README:
To the extent possible under law, the author(s) have dedicated all copyright
and related and neighboring rights to this software to the public domain
worldwide. This software is distributed without any warranty.
You should have received a copy of the CC0 Public Domain Dedication along
with this software. If not, see http://creativecommons.org/publicdomain/zero/1.0/.Not legally binding in any way, but widely used (and expected) in the software world. Usually placed in the last paragraph with its own (sub-)heading.
5) Create a folder called AUTHORS and place a file called WAIVER with the following content in it:[15]
# Copyright waiver for <NAME_OF_PROJECT>
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
To the best of my knowledge and belief, my contributions are either
originally authored by me or are derived from prior works which I have
verified are also in the public domain and are not subject to claims
of copyright by other parties.
To the best of my knowledge and belief, no individual, business,
organization, government, or other entity has any copyright interest
in my contributions, and I affirm that I will not make contributions
that are otherwise encumbered.6) Finally sign the WAIVER, commit it, and push everything together with your first contribution to a project.
$ # sign
$ gpg2 --no-version --armor --sign AUTHORS/WAIVER --output AUTHORS/WAIVER-signed-by-USERNAME.asc
$ # commit
$ git add AUTHORS/WAIVER-signed-by-USERNAME.asc
$ git commit -S AUTHORS/WAIVER-signed-by-USERNAME.ascThe signed WAIVER replaces other alternatives like contributor license agreements (CLAs). It works without requiring any other software, like a centralized registry of developers. Whenever any of the developers changes her keys, simply re-run the last step and add a new signed waiver. Don’t overwrite the old one, instead prepend the year that the key was active/created or add the key ID.
7) Your done, free to do something else with your life now.
Future work will consist of adding the above header to each source file and verifying that GPG signatures are correct and match between signed waiver and signed commit. No yearly updates to your source files in order to keep headers in shape, no hassle in determining whether or not a single contribution is big enough to mention the contributor by name in the source file, nor anything else.