On Tue, 23 Feb 2016, Lou Berger wrote:
Paul,
The link you provide is quite informative -- although I'm a bit
worried about encroaching on armchair lawyering .
Ack, indeed. Best rely on best-practice docs and advice as much as
possible.
From that link:
Not every contribution to a free software project is copyrightable
Since copyright notices are not mandatory, there is generally no harm
in under-using them, particularly if authorship is recorded in VCS
logs. Over-use, however, can cause problems.
Sure, but the very next bit is:
"It’s a good idea to have developers add their own copyright notices,
since a copyright notice is a legal representation being made regarding
the developer’s rights, but the project should also discourage
contributors from indiscriminately adding notices."
And the document does suggest that adding a Copyright string at the top,
having made a copyrightable modification, is not indiscriminate (by
'indiscriminate' they seem to mean automated / without regard to whether
any kind of copyrightable modification was actually made to a file).
With my Quagga hat on, if someone contributes something and feels a need
to add "their" copyright claim, I usually'd have no reason to not put it
through.
I'm going to hazard a guess that many corporates would tend to prefer
that employees making contributions in the course of their work add
Copyright strings, if there's any copyrightable material at all.
the project should also discourage contributors from indiscriminately
adding notices.
We havn't though had much of a problem with people adding notices when
they shouldn't though. The problem is more the reverse.
Also, if the wording is discouraging, I think that would
disproportionately affect non-large-corporate contributors. Contributors
working at large-corporates are more likely to have legal departments
who produce policy documents, checklists, even training courses
sometimes - all to encourage the appropriate adding of copyright
strings.
Non-large-corp-contributors won't have that, to balance out any
potentially-leading language from us. So they may as a consequence be
more shy about documenting claims.
Based on that, how about, instead add to current HACKING.MD:
+
+ Care should be taken when adding copyright statements to existing
files as
+ not every contribution to a free software project is copyrightable. See
+ http://softwarefreedom.org/resources/2007/originality-requirements.html.
Ah, interesting, though not very accessible? Seems more a legal text
than "best practices for engineers" thing? :(
+
+ When adding a copyright based on a modification, you must also include a
+ description of the modification along with the notice. For example:
+ Copyright 2012 Jane Hacker <[email protected]> Fixed
random number
+ generator to output numbers other than 9.
+
Hmm, adding a changelog type thing seems high-overhead given the SCM
data (plus, on the same line as the copyright string makes for a very
long line potentially). I'd possibly rather have that in the commit
message, and then have some git or automake magic to generate a file
from that when we 'make dist' to create a release tarball, and we only
need to police the git commit message.
But, even that smells a bit high-overhead too. To really guarantee the
information, you'd have to put a file with all the diffs in distributed
tarballs. You'd have to replicate the contents of the SCM into the
tarball?
Hmmm...
I don't really want to over-complicate this.
- Adding such strings on new files: Everyone is fine on that, no doubt
(unless it's a copy? :) ).
- Adding such strings on modifications: Encourage or discourage, but
some contributors will have their own 'encouragement' on that. Either
we push-back on all, inc. those, or we encourage all, to be fair.
- Replicating change data in the files, less keen on.
I'm just not keen on discouraging people from adding these claims, just
on a 'feeling' basis - other than any vlagrantly "wrong" claims (e.g.
adding a string for a clearly unrelated entity; or adding one with no
other change of any real substance).
Is there a need to discourage?
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Time is an illusion, lunchtime doubly so.
-- The Hitchhiker's Guide to the Galaxy_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
