Paul,
On 2/23/2016 10:18 AM, Paul Jakma wrote: > 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. yup. >> 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). yes, but a qualified statement not an unqualified one. They make this point explicitly and in their example. > 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. Sure, but I'd hope you'd block someone adding a copyright statement on others work. > 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. Why is that a problem? As you say above, it's their choice. > 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. I was careful to select non-discouraging language in my proposal as it's the author's choice. > 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? :( right, so if someone has a question -- they need to consult their lawyer. Again, the language above is lifted straight from your reference. > >> + >> + 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? Hereto this language is lifted from your original reference. And as you say above it's best rely on best-practice docs and advice as much as possible. I think using their language is pretty safe while if we really want to craft new language, it's time to ask advice from corporate counsel -- which will make tis a very high overhead discussion. > > 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. Or we remain neutral on the topic, which is basically what the lifted language does. > > - 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? I see no reason to take a position one way or another. If someone doesn't want to add a copyright, it's their choice. If they do, it's also their choice as long as they don't copyright someone else's work. Lou > > regards, _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
