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

Clint Byrum clint at fewbar.com
Mon Oct 21 21:44:10 UTC 2013


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.

> >  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.

> 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.



More information about the OpenStack-dev mailing list