46

This is similar to my other question, but specifically about Copyright rather than Licensing.

Typically, each source file contains a line of the form

Copyright 2010-2015, Me
  • Is this strictly necessary, or would a single COPYRIGHT file at the root of the repository cover all files within the project?
  • Do I need a separate COPYRIGHT file as well, to cover the entire project as a collection, rather than individual files?
  • If I have a copyright line in each source file, should they all reflect the same year range? Or should each file's line reflect the year-range from creation to the year it was last modified?
4
  • 1
    Is this a project to which you are the sole contributor, or are there multiple people contributing? Jun 24, 2015 at 20:46
  • It's also relevant which licence you are using. The more permissive a licence you apply, the less relevant the copyright lines are. Jun 24, 2015 at 20:48
  • I personally go with one file in the project, but I don't know if it has any effect for laws. I know though that I can claim my copyright if I make this notice or not. But maybe it's harder to proof without such notice.
    – Mnementh
    Jun 24, 2015 at 20:48
  • 1
    Nowadays, a good middle ground is to put a one-line comment like # SPDX-License-Identifier: MIT in each source file, together with a list of the authors and copyright years for that file. Then put the full license texts in a LICENSES directory at the root of the project. The conventions are evolving, but some documentation is here: reuse.software/practices/2.0
    – Lassi
    Jul 21, 2019 at 8:48

4 Answers 4

32

I think it's important to include both copyright and licensing information in all files: it ensures that everyone's rights are perfectly clear, regardless of what happens to the code in the future. Your project may be small and self-contained initially, but it often happens that interesting code ends up copied into multiple projects, or that projects get adopted by various people down the line. In both cases it's much easier to keep track of licenses and copyright information if it's specified in every file.

If you consider large projects nowadays, many of them include code from a huge variety of other projects, some large, some small, and in some cases single files copied from various sources (including sometimes old Usenet posts!). Firefox is a good example of this; it includes files from many different projects, some quite small (included in Firefox here), and it can be quite hard to keep track of all the copyright holders and license information. Having it in every single file makes license auditors' jobs much easier.

There have been cases in the past of projects which couldn't be included in Linux distributions because of a couple of files whose licenses or copyright information wasn't clear... (I don't remember specifics off the top of my head, I could find them if necessary.)

Luis Villa wrote an interesting blog post on the topic.

As far as the difference between copyright and licensing goes, they are different, but licensing depends on copyright: a license is only valid inasmuch as it was originally given by the copyright holder. This reinforces the importance of including copyright information: it allows future users of your code to know who wrote it, and who to contact with any copyright-related queries (including licensing questions).

Concerning copyright years, I'll defer to the GPL howto (I don't know the reasoning behind this rule but it's probably applicable beyond just the GPL): according to the FSF, copyright statements are supposed to list the years in which the project was released, not the years in which modifications occurred. So any file which is part of a release should have its copyright statement updated on release; there are a number of tools which can automate this (copyright-update-directory in Emacs to name one). You can end up with different year ranges in your source files, but based on the first release they were part of.

3
  • What about files for which this is impossible? For example, JSON files do not support comments...
    – Pedro A
    Mar 22 at 18:11
  • 1
    @PedroA for files like that you can only rely on external copyright and licensing information, e.g. in a README file. In most cases I can think of, the files wouldn’t be all that useful on their own anyway, so the risk of finding copies in other projects without the copyright information is lower than in files I had in mind when I wrote this answer. Mar 23 at 14:22
  • Thank you very much!! I think you should incorporate that into the answer
    – Pedro A
    Mar 23 at 17:58
4

I'm just going to add to Trevor's answer.

If the license that you're using says something by this, then by all means you should follow it. Otherwise, I think a single file that explains that the copyright applies to all files in the repository should suffice.

0

This is partially based on preference.

If you are distributing / publishing something as a package with one license included there is no need to put the licence on every page. However if you are making a website you may want to reference the license / put the copyright notice on every page to make people aware of the licence your work is published under.

1
  • 2
    Despite comments elsewhere, I'm pretty sure there is a difference between Copyright and Licensing. One concerns the authors rights, the other those of the consumer.
    – kdopen
    Jun 24, 2015 at 21:15
0

The practice of putting legal headers to source files came from USA, because USA joined international agreements on intellectual much later and practiced local legal mechanisms, requiring dancing with headers.

If you are a part of civilized world - your country respect Berne Convention & TRIPS Agreement.

Under Berne Convention 1971 (my highlighting):

Article 5

(2) The enjoyment and the exercise of these rights shall not be subject to any formality; such enjoyment and such exercise shall be independent of the existence of protection in the country of origin of the work. Consequently, apart from the provisions of this Convention, the extent of protection, as well as the means of redress afforded to the author to protect his rights, shall be governed exclusively by the laws of the country where protection is claimed.

Under TRIPS Agreement:

Article 10 Computer Programs and Compilations of Data

  1. Computer programs, whether in source or object code, shall be protected as literary works under the Berne Convention (1971).

You don't need to indicate license by headers or LICENSE file. Your work is automatically protected regardless of any rituals you might imagine.

3
  • 1
    The point here isn’t to ensure protection, it’s to document rights (including rights given to receivers), and to increase the odds that that documentation will remain associated with relevant files if they’re copied to other projects. As you say, works are automatically protected, which means that any given file can’t be used outside the boundaries set by copyright law, unless that’s documented somehow — ideally in the file itself. Nov 8 at 9:10
  • it’s to document rights - these words have nothing to do with international law. Maybe you have in mind the old requirements to register or state ownership with your national law. Headers and LICENSE file won't defend you in court. Copyright infringement is evaluated based on fact of copying. Which might be very well obfuscated, stripping headers is just a small step in a crime ))
    – gavenkoa
    Nov 9 at 7:15
  • Again, this isn’t about ensuring protection. As you say, authors’ rights are protected anyway, as long as they can prove they wrote what they’re claiming (and copyright statements, or lack thereof, don’t matter). My point is that documenting copyright is a service to people receiving copyrighted code, not to its author. Imagine you write a piece of code, and that code is (legally) copied to another project; if the code itself doesn’t document its origin, it becomes harder for a third party to identify it, unless the party copying it takes pains to document it (which often doesn’t happen). Nov 9 at 7:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.