per file handling
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.
Atwood suggest to pick any license.
Follow the suggesting of the FSF and pick the Creative Commons Zero license.. Compared to similar licenses like the WTFPL or UNLICENSE which are often critized for their lack of legal language, the CC0’s only downside seems to be a missing OSI stamp of approval. 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. 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.
The CC0 license is probably not DFSG 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 is DFSG compatible and won’t clutter your
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 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.
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.
# 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 ![CC Zero](https://img.shields.io/badge/license-cc%20zero-000000.svg?style=flat-square)
4) Place the following text at the bottom of your
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:
# 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.asc
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.