[quagga-dev 14715] Re: adding copyright lines when modifying a file

Paul Jakma paul at jakma.org
Tue Feb 23 10:22:59 GMT 2016

On Mon, 22 Feb 2016, Lou Berger wrote:

> Hi,
>    The following caught my eye:
> https://lists.quagga.net/pipermail/quagga-dev/2016-January/014686.html
>> + at c Copyright @copyright{} 2015 Hewlett Packard Enterprise
> Development LP
> Which lead me to finding http://patchwork.quagga.net/patch/1800/ aka
> https://lists.quagga.net/pipermail/quagga-dev/2016-January/014712.html
> +You are encouraged add any applicable copyright claims to files being
> +modified or added.  The standard way is to add a string in the following
> +format near the beginning of the file:
> +
> +    Copyright (C) <Year> <name of person/entity>[, optional contact details]
> +

Yes. My reason for that encouragement is cause it is better to have 
people document claims than not - and at present contributors rarely add 
Copyright strings, even when they likely should. If that suggested 
addition to HACKING can be refined, all the better. :)

> The added copyright statement in the 1st mail conforms with the 2nd 
> mail (change to HACKING.md), but the result of the 1st is to add a 
> Copyright where non has existed before -- which reads to me as if the 
> Copyright is covering the whole file -- clearly not a desired (or 
> probably intended) result.

My understanding was that a "Copyright ..." claim should not be read as 
exclusive to any other claims, or to (per se) apply to the whole file. 
It's just saying that entity believes it has a (non-exclusive) claim to 
something, somewhere, in that file.

This SFLC doc seems to suggest same (§"Maintaining file-scope copyright 
notices", e.g.):


> It seems to me that at most a modification to an existing quagga file 
> should says is "Portions Copyright...."

> My personal (and company's) approach is to add no new statement on 
> files we modify, and to add a Copyright statement on files we create 
> without derivative content.  (See bgp_encap.c for an example of a file 
> we created *with* significant derivative content.)
> So my question is:
> What's the right answer?

The SFLC doc suggests it is fine to add "Copyright ..." strings when 
modifying a file with copyrightable updates (and the bar on what is 
copyrightable is _extremely_ low; as I read elsewhere "Happy Birthday" 
is copyrightable, even though it was identical to an earlier song, bar 3 
obvious words).

> - Adding an unqualified Copyright following
> http://patchwork.quagga.net/patch/1800/
> - Adding "Portions Copyright ..."
> - Treating all modifications as Derivative Works and non-copyrightable
> - Requiring a new file for any new Copyrighted material
> - Something else
> I think at very least, the Copyright statement above and HACKING.md
> should be modified to say Portions...

An issue I have with _now_ adding "Portions..." to new claims would be 
that there are existing "Copyright..." strings that don't have that that 
may also be "Portions". I wouldn't have the energy to go research every 
one of them to try determine the status of each. It might not even be 
possible to do so for any that were made pre-git (certainly, GNU Zebra 
CVS meta-data is gone - even while zebra.org CVS was still online, 
running CVS2git conversions on it would give errors, there seemed to be 
corruption in the CVS meta-data).

The end result would be that we'd have some with "Portions" and some 
without, and it'd be confusing.

Perhaps instead we could just document more generally that "Copyright" 
strings are non-exclusive, and need only apply to portions?

> Does anyone else care/have an opinion? (If not, I'll submit a patch to
> HACKING.md adding the word "Portions".)

I think it's always good to make things more clear, and enhance shared 
understandings. I'm just wondering if there are other solutions, as 
"Portions" on some could of itself add ambiguity, through contrast.

Paul Jakma	paul at jakma.org	@pjakma	Key ID: 64A2FF6A
It has been said that man is a rational animal.  All my life I have
been searching for evidence which could support this.
 		-- Bertrand Russell

More information about the Quagga-dev mailing list