While the work on new Gentoo copyright policy is still in progress, I think it would be reasonable to write a short article on copyright in general, for the benefit of Gentoo developers and contributors (proxied maintainers, in particular). There are some common misconceptions regarding copyright, and I would like to specifically focus on correcting them. Hopefully, this will reduce the risk of users submitting ebuilds and other files in violation of copyrights of other parties.
First of all, I’d like to point out that IANAL. The following information is based on what I’ve gathered from various sources over the years. Some or all of it may be incorrect. I take no responsibility for that. When in doubt, please contact a lawyer.
Secondly, the copyright laws vary from country to country. In particular, I have no clue how they work across two countries with incompatible laws. I attempt to provide a baseline that should work both for US and EU, i.e. ‘stay on the safe side’. However, there is no guarantee that it will work everywhere.
Thirdly, you might argue that a particular case would not stand a chance in court. However, my goal here is to avoid the court in the first place.
The guidelines follow. While I’m referring to ‘code’ below, the same rules to apply to any copyrightable material.
- Lack of clear copyright notice does not imply lack of copyright. When there is no license declaration clearly applicable to the file in question, it is implicitly all-rights-reserved. In other words, you can’t reuse that code in your project. You need to contact the copyright holder and ask him to give you rights to do so (i.e. add a permissive license).
- Copyright still holds even if the author did not list his name, made it anonymously or used a fake name. If it’s covered by an open source license, you can use it preserving the original copyright notice. If not, you need to reliably determine who the real copyright holder is.
- ‘Public domain’ dedication is not recognized globally (e.g. in the EU copyright is irrevocable). If you wish to release your work with no restrictions, please use an equivalent globally recognized license, e.g. CC0. If you wish to include a ‘public domain’ code in your project, please consider contacting its author to use a safer license option instead.
- Copyrights and licenses do not merge when combining code. Instead, each code fragment retains its original copyright. When you include code with different copyright, you should include the original copyright notice. If you modify such code fragment, you only hold copyright (and can enforce your own license) to your own changes.
- Copyright is only applicable to original work. It is generally agreed that e.g. a typo fix is not copyrightable (i.e. you can’t pursue copyright for doing that). However, with anything more complex than that the distinction is rather blurry.
- When a project uses code fragments with multiple different licenses, you need to conform to all of them.
- When a project specifies that you can choose between multiple licenses (e.g. BSD/GPL dual-licensing, ‘GPL-2 or newer’), you need to conform only to the terms of one of the specified licenses. However, in the context of a single use, you need to conform to all terms of the chosen license. You can’t freely combine incompatible terms of multiple licenses.
- Not all licenses can be combined within a single project. Before including code using a different license, please research license compatibility. Most of those rules are asymmetrical. For example:
- you can’t include GPL code in BSD-licensed project (since GPL forbids creating derivative work with less restrictive licensing);
- but you can include BSD-licensed code in GPL project (since BSD does not forbid using more restrictive license in derivative works);
- also, you can include BSD/GPL dual-licensed code in BSD-licensed project (since dual-licensing allows you to choose either of the licenses).
- Relicensing a whole project can happen only if you obtain explicit permission from all people holding copyright to it. Otherwise, you can only relicense those fragments to which you had obtained permission (provided that the new license is compatible with the remaining licenses).
- Relicensing a project does not apply retroactively. The previous license still applies to the revisions of the project prior to the license change. However, this applies only to factual license changes. For example, if a MIT-licensed project included LGPL code snippet that lacked appropriate copyright notice (and added the necessary notice afterwards), you can’t use the snippet under (mistakenly attributed) MIT license.