Page MenuHomePhabricator

license linting doesn't allow for copyright years other than the current
Closed, DuplicatePublic

Description

arc lint is telling me this:

$ arc lint
>>> Lint for listener.c:


   Error  (APACHELICENSE1) No License Header
    This file has a missing or out of date license header.

               1 /*
    >>> -      2  * Copyright 2012-2013 Facebook, Inc.
        +         * Copyright 2013 Facebook, Inc.
               3  *
               4  * Licensed under the Apache License, Version 2.0 (the "License");
               5  * you may not use this file except in compliance with the License.

I'd like it to at least accept that 2012-2013 is OK and not error out on me, and have the option to configure the linter so that it could "intelligently" propose upgrading a "Copyright 2012" to "Copyright 2012-2013"

This does get into fuzzy territory though because the copyright lines I've seen over the years can be a real zoo with things like this:

Copyright 1999,2000,2002-2005

Correctly parsing, interpreting and auto-adding the right year seems messy :-/

Another alternative is to configure the license linter to only error if it can't find a copyright statement at all; that way it can auto-add the correct copyright header at the time of writing.

Revisions and Commits

Event Timeline

We've dropped these blocks in Phabricator entirely (see T2035) with Facebook's blessing. Is that an acceptable workaround in this case?

I think that'll allow me to trim it down to a micro copyright header of 1-2 lines for the couple of projects I'm hacking on, but it's still dodging around a broader issue.

Certainly not a high priority thing; I'm sure I can put together a suitable lint rule for this in my project, but since I already have a hack around another issue with license linting (some code bases contain files with multiple copyright holders) I wanted to broach the topic of making the license linter base a bit more flexible.

The "missing" features of the base are:

  • Option to allow multiple copyright holders and not fail the "missing" part of the check
  • Option to allow multiple valid copyright holders and/or license texts and fail if the "wrong" things are present (honestly only see this being useful for pedantic or more locked down environments)
  • Option (though should probably be the default) to respect/allow a date range in the copyright header
epriestley triaged this task as Low priority.EditedJan 6 2013, 4:38 AM

Do you have any legal basis for the value of the "1999, 2000, 2002-2005" form?

As far as I can tell this is all an elaborate ruse of made-up cargo-cult nonsense with no legal basis and no relevant case law. From what I can surmise:

  • Explicit copyright notices may help prove willful infringement, but that's only relevant to seeking treble damages. I suspect the value of treble damages to copyright owners is probably not worth the engineering costs to maintain copyright headers in most cases. Also, no one seems to be offering this up as justification, even though it's the only actual legally-based justification I can identify. And this is very unlikely to be relevant in open source code (I presume damages are basically zero, so treble damages are also basically zero, and stopping the distribution rather than receiving damages would be the goal of any legal action), even if it might provide some partial justification for, e.g., Facebook's internal copyright headers.
  • It seems like there is no legal basis in the US for "X, Y", "X-Y" or "X-Present" forms, and providing a too-early date may actually reduce the duration of the copyright. I can not find recommendations for these forms that are justified by any legal argument.
  • Most copyright case law in the digital era seems to relate to piracy and the DMCA, not to software and/or open source. I can't find any case law related to copyright headers in open source software.
  • Even the instructions associated with licenses seem inconsistent and not based in law. For example, the Apache 2.0 license has a different set of instructions (explicitly, no copyright year) for application in ASF projects vs application in general (explicitly yyyy copyright year).
  • The ASF's justification for the header is that it allows third parties to recognize when individual files are permissibly licensed (this is also an argument in T2035), not that it provides any legal protection. It is hard for me to imagine that many projects gain more benefit from users who would not otherwise be able to figure out the license copying individual files into their own projects -- a scenario which I have literally never seen -- than they pay in engineering costs to deal with these headers -- especially not complex projects where all or nearly all source files are useless on their own. It seems like this goal could be accomplished just as well with a less complex rule anyway, e.g. "See NOTICE for license information."

Basically, I'd like actual legal justification for any rules we implement in the upstream. I've been unsuccessful in getting anything from real lawyers, and unable to find anything on my own, although I really have no idea how to search for case law effectively. In the absence of sound arguments for how these rules should work, I'm inclined to delete these linters: now that we no longer use these headers in the upstream, I'd rather not endorse any approach than try to implement a wildly diverse array of seemingly mythological incantations, covering multiple copyright years/owners/licenses and whatever else.

(For completeness, T2525 scorched the earth here.)

@vrana, this is why I had @blc nuke the license linters. As far as I know, no one outside of Facebook is using them, and it seems like they don't do the right thing at Facebook. I don't want to deal with supporting the wide variety of copyright year formats and multiple-license-headers and whatever else.

We can restore them temporarily if they're widely used, but I don't think they should be in Arcanist long-term because I don't want to have a big mess of different copyright year styles and multiple-licenses and whatever else.

Also I personally feel that copyright headers are a plague upon software development and we shouldn't endorse their application.

epriestley edited this Maniphest Task.
epriestley added a subscriber: Unknown Object (MLST).Jan 25 2014, 8:18 PM
avivey changed the visibility from "All Users" to "Public (No Login Required)".Feb 26 2016, 7:09 PM