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

Michael Basnight mbasnight at gmail.com
Tue Oct 22 17:35:49 UTC 2013


Top posting cuz im a baller. We will get this fixed today. PS clint i like the way you think ;)

https://review.openstack.org/#/c/53176/

On Oct 22, 2013, at 9:21 AM, Clint Byrum wrote:

> Excerpts from Monty Taylor's message of 2013-10-21 17:09:41 -0700:
>> 
>> On 10/21/2013 10:44 PM, Clint Byrum wrote:
>>> Excerpts from Mark McLoughlin's message of 2013-10-21 13:45:21 -0700:
>>> 
>>> 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.
>> 
> 
> The copyright header is a data point. Now somebody looking to vet the
> license situation can go and contact Michael Basnight, and look at the
> history of the code itself. They can validate that Michael Basnight was
> an early author, made announcements, isn't a habitual code stealer, etc.
> 
> Is this correct? No, but it gives someone looking to do due diligence
> confirmation that Michael had the right to license the code.
> 
> No headers, and no information anywhere just makes an investigation that
> much harder.
> 
> So it is just a data point for auditing. The problem, which Robert
> Collins alluded to, is that nobody is actually auditing things this way.
> 
> This is something to bring up in Debian. I think I'll work off list with
> Thomas to draft something for Debian which proposes a clarification
> or relaxation of the copyright holder interpretation of Debian policy
> currently adopted by the FTP masters.
> 
>> 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.
>> 
> 
> Indeed, this hasn't come up, presumably, because the other
> debian/copyright files have done just that. That is definitely the path of
> least resistance, and the one I have taken. This is not trivial either,
> As somebody who made a feeble attempt at documenting the copyright
> holders for MySQL (all of you reading this have no idea how hard Monty
> is cackling right now), I can say that it is basically pointless to do
> anything except automatically generate from existing sources and spot
> check.
> 
>>> 
>>> 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.
>> 
> 
> That sounds pretty valuable to me. Imagine Debian has some big
> corporation sending them cease and desist letters and threats of
> copyright infringement lawsuits. It would be useful to be able to
> deflect that efficiently given their limited resources.
> 
>>>> 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.
>> 
> 
> I'd appreciate it if you would include your _actual_ feelings in these
> emails and not mince words next time Monty.
> 
> Point taken, no CLA in tarballs. Up until this point I actually thought
> the CLA was something that was part of the community ethos, some kind of
> "look we are making it better for companies". Did not realize it was
> just a legal shim put in by the corporate lawyer drones.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131022/f7f89156/attachment.pgp>


More information about the OpenStack-dev mailing list