[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)

Monty Taylor mordred at inaugust.com
Tue Oct 22 00:09:41 UTC 2013



On 10/21/2013 10:44 PM, Clint Byrum wrote:
> Excerpts from Mark McLoughlin's message of 2013-10-21 13:45:21 -0700:
>> On Mon, 2013-10-21 at 10:28 -0700, Clint Byrum wrote:
>>> Excerpts from Robert Collins's message of 2013-10-20 02:25:43 -0700:
>>>> On 20 October 2013 02:35, Monty Taylor <mordred at inaugust.com> wrote:
>>>>
>>>>> However, even as a strong supporter of accurate license headers, I would
>>>>> like to know more about the FTP masters issue. I dialog with them, as
>>>>> folks who deal with this issue and its repercutions WAY more than any of
>>>>> us might be really nice.
>>>>
>>>> Debian takes it's responsibilities under copyright law very seriously.
>>>> The integrity of the debian/copyright metadata is checked on the first
>>>> upload for a package (and basically not thereafter, which is either
>>>> convenient or pragmatic or a massive hole in rigour depending on your
>>>> point of view. The goal is to ensure that a) the package is in the
>>>> right repository in Debian (main vs nonfree) and b) that Debian can
>>>> redistribute it and c) that downstreams of Debian who decide to use
>>>> the package can confidently do so. Files with differing redistribution
>>>> licenses that aren't captured in debian/copyright are an issue for c);
>>>> files with different authors and the same redistribution licence
>>>> aren't a problem for a/b/c *but* the rules the FTP masters enforce
>>>> don't make that discrimination: the debian/copyright file needs to be
>>>> a concordance of both copyright holders and copyright license.
>>>>
>>>> Personally, I think it should really only be a concordance of
>>>> copyright licenses, and the holders shouldn't be mentioned, but thats
>>>> not the current project view.
>>>>
>>>
>>> The benefit to this is that by at least hunting down project leadership
>>> and getting an assertion and information about the copyright holder
>>> situation, a maintainer tends to improve clarity upstream.
>>
>> By "improve clarity", you mean "compile an accurate list of all
>> copyright holders"? Why is this useful information?
>>
>> Sure, we could also "improve clarity" by compiling a list of all the
>> cities in the world where some OpenStack code has been authored ... but
>> *why*?
>>
> 
> If you don't know who the copyright holders are, you cannot know that
> the license being granted is actually enforceable. What if the Trove
> developers just found some repo lying out in the world and slapped an
> Apache license on it? We aren't going to do an ehaustive investigation,
> but we want to know _who_ granted said license.

You know I think you're great, but this argument doesn't hold up.

If the trove developers found some repo in the world and slapped an
apache license AND said:

Copyright 2012 Michael Basnight

in the header, and Thomas put that in debian/copyright, the Debian FTP
masters would very happily accept it.

I think that authors should attribute their work, because I think that
they should care. However, if they don't, that's fine. There is SOME
attribution in the file, and that attribution itself is correct. HP did
write some of the file. Rackspace also did but did not bother to claim
having done so.

debian/copyright should reflect what's in the files - it's what the
project is stating through the mechanisms that we have available to us.
I appreciate Thomas trying to be more precise here, but I think it's
actually too far. If you think that there is a bug in the copyright
header, you need to contact the project, via email, bug or patch, and
fix it. At THAT point, you can fix the debian/copyright file.

Until then, you need to declare to Debian what we are declaring to you.

>>>  Often things
>>> that are going into NEW are, themselves, new to the world, and often
>>> those projects have not done the due diligence to state their license
>>> and take stock of their copyright owners.
>>
>> I think OpenStack has done plenty of due diligence around the licensing
>> of its code and that all copyright holders agree to license their code
>> under those terms.
>>
>>> I think that is one reason
>>> the process survives despite perhaps going further than is necessary to
>>> maintain Debian's social contract integrity.
>>
>> This is related to some "social contract"? Please explain.
>>
> 
> http://www.debian.org/social_contract
> 
>>> I think OpenStack has taken enough care to ensure works are attributable
>>> to their submitters that Debian should have a means to accept that
>>> this project is indeed licensed as such. Perhaps a statement detailing
>>> the process OpenStack uses to ensure this can be drafted and included
>>> in each repository. It is not all that dissimilar to what MySQL did by
>>> stating the OpenSource linking exception for libmysqlclient's
>>> GPL license explicitly in a file that is now included with the tarballs.
>>
>> You objected to someone else on this thread conflating copyright
>> ownership and licensing. Now you do the same. There is absolutely no
>> ambiguity about OpenStack's license.
>>
> 
> I'm not sure that was me, but I would object to conflating it, yes. They
> are not the same thing, but they are related. Only a copyright holder
> can grant a copyright license.

Listing the holders in debian/copyright does not prove that the asserted
holder is a valid holder. It only asserts that _someone_ has asserted
that copyright.

It means that, should someone sue you for copyright infringement, there
is someone you can go to for clarification.

>> Our CLA process for new contributors is documented here:
>>
>>   https://wiki.openstack.org/wiki/How_To_Contribute#Contributors_License_Agreement
>>
>> The key thing for Debian to understand is that all OpenStack
>> contributors agree to license their code under the terms of the Apache
>> License. I don't see why a list of copyright holders would clarify the
>> licensing situation any further.
>>
> 
> So Debian has a rule that statements like these need to be delivered to
> their users along with the end-user binaries (it relates to the social
> contract and the guidelines attached to the contract.
> 
> https://review.openstack.org/static/cla.html
> 
> Article 2 is probably sufficient to say that it only really matters that
> all of the copyrighted material came from people who signed the CLA,
> and that the "Project Manager" (OpenStack Foundation) grants the license
> on the code. I assume the other CLA's have the same basic type of
> license being granted to the OpenStack Foundation.
> 
> So my recommendation stands, that we can clarify it in the released
> tarballs with a single document. I suggest that document have the text
> of the CLA's (since there are different CLA's for different types of
> submitters), and an assertion that all of the code in the underlying
> repository has been submitted by individuals who have signed at least one
> of these CLA's. That _should_ be sufficient for Debian's FTP masters,
> and if not, then for the Debian governing bodies that would be able to
> override the FTP masters.
> 
> Oh and I am not a lawyer, but I am a Debian developer and I am concerned
> that we make it clear exactly what users' rights are.

I believe our CLA is bullshit.

Our code has an Apache License on it. All of our files have Apache
license headers on them. They are all Apache licensed.

The users rights, as per the Debian Social Contract, are clearly stated
- they are the rights, granted to the user, under the auspices of the
Apache License.

Who granted those rights to the user is immaterial to how the license
operates. A correct list of everyone who may have contributed lines of
code to the file is also immaterial.

The source from which Debian is receiving the code, has attached a
license to the software. It is Free Software.

Our CLA was useless bullshit when our corporate lawyers forced it on us.
It is useless bullshit now. It will be useless bullshit until we rip it
out of the hands of our corporate lawyers and stomp it on the ground
until it is dead and the people who added it senselessly to our process
feel very silly that they do not have the ability to read the
quite-clear terms of the Apache License itself.

The last thing we need to do is validate in any manner that somehow the
CLA makes our Apache Licensed Free Software more Free or more Valid than
if we did not have our useless CLA.

In case it's not clear, I think:

a) we should not add a copy of any part of our CLA to our source tarballs
b) Thomas should put in debian/copyright what is in our headers, and
should consider them, as they are in our source tarballs, to be correct
c) If Thomas, or anyone else, considers our header attribution to be
incorrect, he or she should submit a patch or suggest that someone else
submit a patch to the file in question indicating that he or she feels
that there is incorrect content in that file

All of the back and forth about whether Debian should or should not
attempt to accurately catalog or enforce a list of contributors, while
interesting, is immaterial. They do, and we provide one.

Monty



More information about the OpenStack-dev mailing list