cURL and libcurl

Copyright without years

13 Comments

Like so many other software projects the curl project has copyright mentions at the top of almost every file in the source code repository. Like

Copyright (C) 1998 - 2022, Daniel Stenberg ...

Over the years we have used a combination of scripts and manual edits to update the ending year in that copyright line to match the year of the latest update of that file.

As soon as we started a new year and someone updated a file, the copyright range needed update. Scripts and tools made it less uncomfortable, but it was always somewhat of a pain to remember and fix.

In 2023 this changed

When the year was again bumped and the first changes of the year were done to curl, we should then consequentially start updating years again to make ranges end with 2023.

Only this time someone asked me why? and it made me decide that what the heck, let’s completely rip them out instead! Doing it at the beginning of the year is also a very good moment.

Do we need the years?

The Berne Convention states that copyright “must be automatic; it is prohibited to require formal registration”.

The often-used copyright lines are not necessary to protect our rights. According to the Wikipedia page mentioned above, the Berne Convention has been ratified by 181 states out of 195 countries in the world.

They can still serve a purpose as they are informational and make the ownership question quite clear. The year ranges add questionable value though.

I have tried to find resources that argue for the importance of the copyright years to be stated and present, but I have not found any credible sources. Possibly because I haven’t figured out where to look.

Not alone

It turns out quite a few projects run by many different organizations or even huge companies have already dropped the years from their source code header copyright statements. Presumably at least some of those giant corporations have had their legal departments give a green light to the idea before they went ahead and published source code that way to the world.

Low risk

We own the copyrights no matter if the years are stated or not. The exact years the files were created or edited can still easily be figured out since we use version control, should anyone ever actually care about it. And we give away curl for free, under an extremely liberal license.

I don’t think we risk much by doing this move.

January 3, 2023

On this day I merged commit 2bc1d775f510, which updated 1856 files and removed copyright years from almost everywhere in the source code repository.

I decided to leave them in the main license file. Partly because this is a file that lots of companies include in their products and I have had some use of seeing the year ranges in there in the past!

Bliss

Now we can forget about copyright years in the project. It’s a relief!

13 thoughts on “Copyright without years”

  1. Yes, and no, and but …

    Yes, it is low risk to remove the years because you don’t intend to enforce the copyright.

    And, no, those files should not have had a range of years in the first place (that’s an ambiguous notice, which would be interpreted as the first year anyway). It’s a cargo cult thing.

    But the committed version isn’t a valid notice at all, since the year of first publication is required to make it so (at least in the US). The US code is described at https://www.copyright.gov/title17/92chap4.html

    Note that a valid copyright notice also has value as a deterrent and as sticky documentation. The law (and some OSS licenses) require that such notices be retained unaltered.

    OTOH, removing all of the notices is fine, if that is what you want to do. My preference is to have one, overall, valid copyright notice in README or NOTICE files. That one should have a date of first publication, which usually refers to the date that this overall collected/joint work is published (i.e., this year). But you can also choose to just make it the year that the file was created and never have to update it again.

    1. Note the “a notice of copyright as provided by this section may be placed on” within the linked page ( https://www.copyright.gov/title17/92chap4.html ). I.E.: note the “_may_”.

      This was changed by H.R.4262 – Berne Convention Implementation Act of 1988, (https://www.congress.gov/bill/100th-congress/house-bill/4262/text), from “shall be placed on all” making the Notice of Copyright optional.

      So it’s correct that in the context of the 401 that “Copyright ” is not a “Notice of Copyright”, but it’s also not required for copyright to be established (since 1988).

    2. I keep the copyright mentions (without years) for informational purposes for those who find the files and read them. They then tell the reader who owns the copyright and explain the license.

      This happens to also match how the REUSE check/project wants them.

  2. Is there any rationale perhaps to include the original year when the file was created as a sort of “copyrighted from this year onward”? So perhaps a copyright line like “Copyright (C) 1998+, Daniel Stenberg, , et al.”?

    1. @Jeffrey: sure, that would still solve the update-problem and provide some extra info but I don’t think users ever actually cares about that. Copyright wise, I don’t think there’s a problem if everyone just think of all curl files as being created 1998… =)

      1. Adding the latest year (“1998-2023”) helps give the impression that the code is being maintained and improved actively. Without the latest year, it might look like the code was created and stagnated in 1998.

        This is just optics, though. I agree that it’s low risk from a copyright perspective to omit the year(s).

  3. Daniel:
    This makes 100% sense and thank you for showing the way!
    I maintain a tool that can parse most copyrights and it copes with dates alright but the start-of-January churn of “let’s change the copyright date in all files” is just busywork without a purpose that creates dummy commits.

    For the record, there is a lawyer that I respect has a different take on this date issue. And I will respectfully disagree with him and side with you!

    https://liferay.dev/blogs/-/blogs/how-and-why-to-properly-write-copyright-statements-in-your-code#why-keep-the-year

    Yet another lawyer that I respect has (surprise) a different opinion on your side: https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects

    And in your support here is a post by a prolific FOSS developer that also has plenty of links to examples that go your way https://hynek.me/til/copyright-years/

  4. I wrote a longer blog post on the topic of copyright statements in source code, from both US and EU (Slovenian) law perspective.

    TL;DR: best practice = use © sign and year of file creation/commit and _don’t_ bump the year

    In that blog post I also address several myths and maintain an FAQ, including the bumping; the ranges; why copyright notices are not needed, but a good idea, …

    https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code

  5. IMO, the reason to put the year in the copyright notice is so it’s possible to determine whether the copyright has expired.

    1. @bob: in many countries, copyrights are owned until 70 years after the creator’s death. I think you can assume most copyrights on source code to still be valid for a rather long time. I suspect the code will go stale and the project to die long before the copyrights expire.

      If you think I die this year, most copyrights in curl will thus expire in 2093. A year I bet most readers of this blog won’t care about curl anymore.

      1. > 2093. A year I bet most readers of this blog won’t care about curl anymore

        That’s the kind of thinking that gave us the millennium bug, though =P

        I’d be midly amused at best if a traveler from the future told me curl is still around I’m 2100.

  6. Copyright is a way of protecting intellectual property so a person may reap the benefit of their work. But as mentioned above, it expires. While a copyright notice may not be required to assert the copyright, it will allow someone to assess that the work is not subject to copyright any more after it expired. It will otherwise be hard in to assess when the last changes have been made after 70 years of inactivity in the project – also because much of the metadata associated with files may have been lost.

    While appreciating that this is a hassle, I think the long term benefits may outweigh the cost. After all, it’s not a quick change to make and only has to be done if work is being done anyway.

Comments are closed.