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

2013-10-23 Thread Thomas Goirand
On 10/23/2013 06:32 AM, Michael Basnight wrote:
 
 On Oct 22, 2013, at 10:35 AM, Michael Basnight wrote:
 
 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/

 
 Now that this is merged, and there is no stable/havana for clients, Ive got a 
 question. What do the package maintainers use for clients? the largest 
 versioned tag? If so i can push a new version of the client for packaging.

Thanks for doing this.

Replied privately about updating the troveclient in Debian.

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-22 Thread Thomas Goirand
On 10/22/2013 04:55 AM, Mark McLoughlin wrote:
 Talk to the Trove developers and politely ask them whether the copyright
 notices in their code reflects what they see as the reality.
 
 I'm sure it would help them if you pointed out to them some significant
 chunks of code from the commit history which don't appear to have been
 written by a HP employee.

I did this already. Though if I raised the topic in this list (as
opposed to contact the Trove maintainers privately), this was for a
broader scope, to make sure it doesn't happen again and again.

 Simply adding a Rackspace copyright notice to a file or two which has
 had a significant contribution by someone from Rackspace would be enough
 to resolve your concerns completely.

But how to make sure that there's no *other* copyright holders, and that
my debian/copyright is right? Currently, there's no way...

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-22 Thread Thomas Goirand
On 10/22/2013 05:06 AM, Michael Basnight wrote:
 so if this is sufficient, ill fix the copyright headers.

Please do (and backport that to 2013.2...)! :)

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-22 Thread Thomas Goirand
On 10/22/2013 04:48 AM, Mark McLoughlin wrote:
 On Tue, 2013-10-22 at 01:55 +0800, Thomas Goirand wrote:
 On 10/21/2013 09:28 PM, Mark McLoughlin wrote:
 In other words, what exactly is a list of copyright holders good for?

 At least avoid pain and reject when uploading to the Debian NEW queue...
 
 I'm sorry, that is downstream Debian pain.

I agree, it is painful, though it is a necessary pain. Debian has always
been strict with copyright stuff. This should be seen as a freeness Q/A,
so that we make sure everything is 100% free, rather than an annoyance.

 It shouldn't be inflicted on
 upstream unless it is generally a useful thing.

There's no other ways to do things, unfortunately. How would I make sure
a software is free, and released in the correct license, if upstream
doesn't declare it properly? There's been some cases on packages I
wanted to upload, where there was just:

Classifier: License :: OSI Approved :: MIT License

in *.egg-info/PKG-INFO, and that's it. If the upstream authors don't fix
this by adding a clear LICENSE file (with the correct definition of the
MIT License, which is confusing because there's been many of them), then
the package couldn't get in. Lucky, upstream authors of that python
module fixed that, and the package was re-uploaded and validated by the
FTP masters.

I'm not saying that this was the case for Trove (the exactitude of the
copyright holder list in debian/copyright is less of an issue), though
I'm just trying to make you understand that you can't just ignore the
issue and say I don't care, that's Debian's problem. This simply
doesn't work (unless you would prefer OpenStack package to *not* be in
Debian, which I'm sure isn't the case here).

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-22 Thread Mark McLoughlin
On Tue, 2013-10-22 at 14:09 +0800, Thomas Goirand wrote:
 On 10/22/2013 04:55 AM, Mark McLoughlin wrote:
  Talk to the Trove developers and politely ask them whether the copyright
  notices in their code reflects what they see as the reality.
  
  I'm sure it would help them if you pointed out to them some significant
  chunks of code from the commit history which don't appear to have been
  written by a HP employee.
 
 I did this already. Though if I raised the topic in this list (as
 opposed to contact the Trove maintainers privately), this was for a
 broader scope, to make sure it doesn't happen again and again.
 
  Simply adding a Rackspace copyright notice to a file or two which has
  had a significant contribution by someone from Rackspace would be enough
  to resolve your concerns completely.
 
 But how to make sure that there's no *other* copyright holders, and that
 my debian/copyright is right? Currently, there's no way...

I've never seen a project where copyright headers weren't occasionally
missing some copyright holders. I suspect Debian has managed just fine
with those projects and can manage just fine with OpenStack's copyright
headers too.

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-22 Thread Thomas Goirand
On 10/22/2013 08:09 AM, Monty Taylor wrote:
 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

ACK.

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-22 Thread Thomas Goirand
On 10/22/2013 04:45 AM, Mark McLoughlin wrote:
 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*?

Mark, I haven't asked for things to be 100% accurate. I know that's not
possible. I've asked that we make sure headers aren't 90% wrong, which
was my gut feeling when writing the trove debian/copyright file and
seeing only HP in the headers...

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

Well, I am just willing to write things correctly, and I have been in
situations where it wasn't possible easily, and wanted to fix this once
and for all, by opening the topic in this list. It is as simple as that.
There's no need for the discussion to go *that* far. Nobody is
discussing the fact that OpenStack is free software.

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-22 Thread Thomas Goirand
On 10/22/2013 02:12 AM, Jeremy Stanley wrote:
 On 2013-10-22 01:45:13 +0800 (+0800), Thomas Goirand wrote:
 [...]
 The main problem I was facing was that troveclient has a few files
 stating that HP was the sole copyright holder, when it clearly was
 not (since I have discussed a bit with some the dev team in
 Portland, IIRC some of them are from Rackspace...).
 [...]
 So, for me, the clean and easy way to fix this problem is to have a
 simple copyright-holder.txt file, containing a list of company or
 individuals. It doesn't really mater if some entities forget to write
 themselves in. After all, that'd be their fault, no?
 [...]
 
 I don't really see the difference here at all. You propose going
 from...
 
 A) copyright claims in headers of files, which contributors
 might forget to update
 
 ...to...
 
 B) copyright claims in one file, which contributors might also
 forget to update
 
 I don't understand how adding a file full of duplicate information
 to each project is going to solve your actual concern.

My idea was that in the case of B, it's more easy to fix/patch a single
file than lots of them, and also that the existence of the file itself
is an invitation for copyright holders to add themselves in, while a
copyright header in a source code isn't that explicit.

Though I can agree of course, that in both cases, contributors might
forget to add themselves in...

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-22 Thread Mark McLoughlin
On Tue, 2013-10-22 at 14:19 +0800, Thomas Goirand wrote:
 On 10/22/2013 04:48 AM, Mark McLoughlin wrote:
  On Tue, 2013-10-22 at 01:55 +0800, Thomas Goirand wrote:
  On 10/21/2013 09:28 PM, Mark McLoughlin wrote:
  In other words, what exactly is a list of copyright holders good for?
 
  At least avoid pain and reject when uploading to the Debian NEW queue...
  
  I'm sorry, that is downstream Debian pain.
 
 I agree, it is painful, though it is a necessary pain. Debian has always
 been strict with copyright stuff. This should be seen as a freeness Q/A,
 so that we make sure everything is 100% free, rather than an annoyance.

A list of copyright holders does nothing to improve the freeness of
OpenStack.

  It shouldn't be inflicted on
  upstream unless it is generally a useful thing.
 
 There's no other ways to do things, unfortunately. How would I make sure
 a software is free, and released in the correct license, if upstream
 doesn't declare it properly? There's been some cases on packages I
 wanted to upload, where there was just:
 
 Classifier: License :: OSI Approved :: MIT License
 
 in *.egg-info/PKG-INFO, and that's it. If the upstream authors don't fix
 this by adding a clear LICENSE file (with the correct definition of the
 MIT License, which is confusing because there's been many of them), then
 the package couldn't get in. Lucky, upstream authors of that python
 module fixed that, and the package was re-uploaded and validated by the
 FTP masters.

I fully understand the importance of making it completely clear what the
license of a project is and have had to package projects that don't make
this clear. Fedora's guidelines on the subject are e.g.

https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text

 I'm not saying that this was the case for Trove (the exactitude of the
 copyright holder list in debian/copyright is less of an issue), though
 I'm just trying to make you understand that you can't just ignore the
 issue and say I don't care, that's Debian's problem. This simply
 doesn't work (unless you would prefer OpenStack package to *not* be in
 Debian, which I'm sure isn't the case here).

I can say Debian policies that no-one can provide any justification for
is Debian's problem. And that's the case with this supposed Debian
requires a complete list of copyright holders policy.

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-22 Thread Robert Collins
On 22 October 2013 20:39, Mark McLoughlin mar...@redhat.com wrote:
 On Tue, 2013-10-22 at 14:19 +0800, Thomas Goirand wrote:
 I agree, it is painful, though it is a necessary pain. Debian has always
 been strict with copyright stuff. This should be seen as a freeness Q/A,
 so that we make sure everything is 100% free, rather than an annoyance.

What Debian asks for is more than anyone else needs, and I've never
seen a satisfactory explanation for why Debian requires it. The
concordance of licence terms is useful, but the concordance of
copyright holders isn't - a) it's usually wrong and b) it's usually
wrong and c) unless there is a use case like 'I don't want to use code
written by person X', it doesn't serve any purpose ... and it doesn't
serve that case, because copyright claimants != authors.

It saddens me everytime I put a new package together, because it's
such a monumental waste of time.

 A list of copyright holders does nothing to improve the freeness of
 OpenStack.

Ack.

 I'm not saying that this was the case for Trove (the exactitude of the
 copyright holder list in debian/copyright is less of an issue), though
 I'm just trying to make you understand that you can't just ignore the
 issue and say I don't care, that's Debian's problem. This simply
 doesn't work (unless you would prefer OpenStack package to *not* be in
 Debian, which I'm sure isn't the case here).

 I can say Debian policies that no-one can provide any justification for
 is Debian's problem. And that's the case with this supposed Debian
 requires a complete list of copyright holders policy.

I agree - and I say this as a Debian Developer :).

The actual policy is:
http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
In addition, the copyright file must say where the upstream sources
(if any) were obtained, and should name the original authors. 

The 'copyright information' for the package is not well defined.
Currently the FTP masters look for a concordance. I think it would be
reasonable to raise a discussion about this - seeking to clarify what
needs to be captured - e.g. 'the package has to have a distribution
license granted by the copyright holders -or- a statement from the
copyright holders that it is in the public domain'. As long as all the
claimed copyright holders are claiming the same license, there is
nothing more needed for either Debian or it's derivatives to be able
to:
 a) use the package
 b) redistribute it [per whatever licence]
 c) filter it if they have license specific policies for some
project/environment

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-22 Thread Clint Byrum
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 

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

2013-10-22 Thread Michael Basnight
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 

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

2013-10-22 Thread Michael Basnight

On Oct 22, 2013, at 10:35 AM, Michael Basnight wrote:

 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/
 

Now that this is merged, and there is no stable/havana for clients, Ive got a 
question. What do the package maintainers use for clients? the largest 
versioned tag? If so i can push a new version of the client for packaging.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-21 Thread Joe Gordon
On Sun, Oct 20, 2013 at 6:38 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2013-10-20 20:57:56 +0800 (+0800), Thomas Goirand wrote:
  Well, good luck finding all the copyright holders for such a large and
  old project. It's not really practical in this case, unfortunately.

 To a great extent, the same goes for projects a quarter the size and
 age of the Linux kernel--doesn't mean we shouldn't try to fix that
 though. In our case, we at least have names and (possibly stale)
 contact information for all the people who claim to have authored
 contributions, so I suspect we're in a somewhat better position to
 do something about it.



Although we may be in a better position to find all the copyright owners,
it appears that many projects skirt the issue by making the copyright owner
an open ended group:

http://ftp-master.metadata.debian.org/changelogs//main/p/python-django/python-django_1.5.4-1_copyright

http://ftp-master.metadata.debian.org/changelogs//main/r/rails-4.0/rails-4.0_4.0.0+dfsg-1_copyright
(I
don't think one person actually owns the copyright on rails)




 Part of the issue is that historically the project has held a
 laissez faire position that claiming copyright on contributions is
 voluntary, and that if you don't feel your modifications to a
 particular file are worthy of copyright (due to triviality or
 whatever) then there was no need to update a copyright statement for
 new holders or years. So the assumption there was that copyrights
 which an author wanted to assert were claimed in the files they
 touched, and if they didn't update the copyright statement on a
 change that was their prerogative.

 I think we collectively know that this isn't really how copyright
 works in most Berne Convention countries, but I also don't think
 reviewers would object to any copyright holder adding a separate
 commit to update valid copyright claims on a particular file which
 they previously neglected to document.
 --
 Jeremy Stanley

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-21 Thread Stefano Maffulli
On 10/20/2013 06:00 AM, Jeremy Stanley wrote:
 I know the Foundation's got work underway to improve the affiliate
 map from the member database, so it might be possible to have some
 sort of automated job which proposes changes to a copyright holders
 list in each project by running a query with the author and date of
 each commit looking for new affiliations. That seems like it would
 be hacky, fragile and inaccurate, but probably still more reliable
 than expecting thousands of contributors to keep that information up
 to date when submitting patches?

To solve the problem for future contributions (if we agree there is a
problem), wouldn't it be simpler to add one line to the commit saying
something like Copyright ownership by: Small Corp? This can be
semi-automatic by hackers (they only need to keep it current). We may
even check automatically at the gate the validity of that assertion
against the (to be built) database of Corporate CLAs.

For past contributions and to solve immediately the issue with
troveclient I guess we can use the data we have from activity
board/gitdm/stackalytics. You can contact me offline, of course.

/stef


-- 
Ask and answer questions on https://ask.openstack.org

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-21 Thread Thomas Goirand
On 10/20/2013 09:00 PM, Jeremy Stanley wrote:
 On 2013-10-20 22:20:25 +1300 (+1300), Robert Collins wrote:
 [...]
 OTOH registering one's nominated copyright holder on the first
 patch to a repository is probably a sustainable overhead. And it's
 probably amenable to automation - a commit hook could do it locally
 and a check job can assert that it's done.
 
 I know the Foundation's got work underway to improve the affiliate
 map from the member database, so it might be possible to have some
 sort of automated job which proposes changes to a copyright holders
 list in each project by running a query with the author and date of
 each commit looking for new affiliations. That seems like it would
 be hacky, fragile and inaccurate, but probably still more reliable
 than expecting thousands of contributors to keep that information up
 to date when submitting patches?

My request wasn't to go *THAT* far. The main problem I was facing was
that troveclient has a few files stating that HP was the sole copyright
holder, when it clearly was not (since I have discussed a bit with some
the dev team in Portland, IIRC some of them are from Rackspace...).

Just writing HP as copyright holder to please the FTP masters because it
would match some of the source content, then seemed wrong to me, which
is why I raised the topic. Also, they didn't like that I list the
authors (from a git log output) in the copyright files.

So, for me, the clean and easy way to fix this problem is to have a
simple copyright-holder.txt file, containing a list of company or
individuals. It doesn't really mater if some entities forget to write
themselves in. After all, that'd be their fault, no? The point is, at
least I'd have an upstream source file to show to the FTP masters as
something which has a chance to be a bit more accurate than
second-guessing through git log or reading a few source code files
which represent a wrong view of the reality.

Any thoughts?

Thomas Goirand (zigo)

P.S: I asked the FTP masters to write in this thread, though it seems
nobody had time to do so...


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-21 Thread Thomas Goirand
On 10/20/2013 09:38 PM, Jeremy Stanley wrote:
 Part of the issue is that historically the project has held a
 laissez faire position that claiming copyright on contributions is
 voluntary, and that if you don't feel your modifications to a
 particular file are worthy of copyright (due to triviality or
 whatever) then there was no need to update a copyright statement for
 new holders or years.

I don't really mind the above way, as long as there's an easy way for me
to write my debian/copyright file, which isn't the case ATM. Currently,
it's close to second-guessing, which is what needs to be fixed. A
copyright-holder.txt file would fix it, and I'm guessing that it's
existence only would push companies to add themselves in...

Thomas Goirand (zigo)


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-21 Thread Jeremy Stanley
On 2013-10-22 01:45:13 +0800 (+0800), Thomas Goirand wrote:
[...]
 The main problem I was facing was that troveclient has a few files
 stating that HP was the sole copyright holder, when it clearly was
 not (since I have discussed a bit with some the dev team in
 Portland, IIRC some of them are from Rackspace...).
[...]
 So, for me, the clean and easy way to fix this problem is to have a
 simple copyright-holder.txt file, containing a list of company or
 individuals. It doesn't really mater if some entities forget to write
 themselves in. After all, that'd be their fault, no?
[...]

I don't really see the difference here at all. You propose going
from...

A) copyright claims in headers of files, which contributors
might forget to update

...to...

B) copyright claims in one file, which contributors might also
forget to update

I don't understand how adding a file full of duplicate information
to each project is going to solve your actual concern. We could
automatically generate it based on the contents of the copyright
headers in other files (in which case it will be no more accurate
than they are), or we could manually maintain it using the same
mechanisms we do for the contents of the copyright headers in other
files (resulting in at best the same end result, and at worst a new
conflicting set of data to reconcile).
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-21 Thread Mark McLoughlin
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 mord...@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*?

  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.

 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.

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.

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-21 Thread Mark McLoughlin
On Tue, 2013-10-22 at 01:55 +0800, Thomas Goirand wrote:
 On 10/21/2013 09:28 PM, Mark McLoughlin wrote:
  In other words, what exactly is a list of copyright holders good for?
 
 At least avoid pain and reject when uploading to the Debian NEW queue...

I'm sorry, that is downstream Debian pain. It shouldn't be inflicted on
upstream unless it is generally a useful thing.

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-21 Thread Michael Basnight

On Oct 21, 2013, at 1:55 PM, Mark McLoughlin wrote:

 On Tue, 2013-10-22 at 01:45 +0800, Thomas Goirand wrote:
 On 10/20/2013 09:00 PM, Jeremy Stanley wrote:
 On 2013-10-20 22:20:25 +1300 (+1300), Robert Collins wrote:
 [...]
 OTOH registering one's nominated copyright holder on the first
 patch to a repository is probably a sustainable overhead. And it's
 probably amenable to automation - a commit hook could do it locally
 and a check job can assert that it's done.
 
 I know the Foundation's got work underway to improve the affiliate
 map from the member database, so it might be possible to have some
 sort of automated job which proposes changes to a copyright holders
 list in each project by running a query with the author and date of
 each commit looking for new affiliations. That seems like it would
 be hacky, fragile and inaccurate, but probably still more reliable
 than expecting thousands of contributors to keep that information up
 to date when submitting patches?
 
 My request wasn't to go *THAT* far. The main problem I was facing was
 that troveclient has a few files stating that HP was the sole copyright
 holder, when it clearly was not (since I have discussed a bit with some
 the dev team in Portland, IIRC some of them are from Rackspace...).
 
 Talk to the Trove developers and politely ask them whether the copyright
 notices in their code reflects what they see as the reality.
 
 I'm sure it would help them if you pointed out to them some significant
 chunks of code from the commit history which don't appear to have been
 written by a HP employee.
 
 Simply adding a Rackspace copyright notice to a file or two which has
 had a significant contribution by someone from Rackspace would be enough
 to resolve your concerns completely.
 
 i.e. if you spot in inaccuracy in the copyright headers, just make it
 easy for us people to fix it and I'm sure they will.

++ to this. Id like to do what is best for OpenStack, but i dont want to make 
it impossible for the debian ftp masters to approve trove :) so if this is 
sufficient, ill fix the copyright headers.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-21 Thread Monty Taylor


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

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

2013-10-21 Thread Michael Basnight

On Oct 21, 2013, at 5:09 PM, Monty Taylor wrote:
 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 mord...@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 endorse this message. 

But seriously, the Trove team will take some time tomorrow and add copyrights 
to the files appropriately. Then ill be sure to ping zigo.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-20 Thread Thomas Goirand
On 10/19/2013 11:50 PM, Jeremy Stanley wrote:
 On 2013-10-19 23:29:28 +0800 (+0800), Thomas Goirand wrote:
 Though the Debian FTP masters seems to insist on having correct
 copyright holders in debian/copyright, and I am a bit lost after the 2
 rejects I just had.
 
 Well, this is still a fuzzy topic. We have a lot of contributions
 and know who the authors are, but not necessarily who the copyright
 holders were on behalf of whom they might have contributed various
 changes (only that the copyright holders authorized them to
 contribute this work under a specific license, because the authors
 signed agreements to this effect). It would almost certainly take a
 policy decision by the technical committee if we wanted to start
 requiring all authors of new changes to add/update copyright
 statements accurately on every file they touch, and there is quite
 probably no chance at all we can precisely nail down historical
 copyright holder data for previous changes already merged.

It doesn't have to be on every files. It is fine if we have a single
file per project, IMO, and if the contributor doesn't change it, then
the copyright holder continues to be the OpenStack foundation.

What maters to me here, is that I don't have to double-guess, because if
I do, FTP masters will ask where does this come from?.

 The licensing has nothing to do with copyright holders. These are 2
 different topics, please don't mix them in. :)
 [...]
 
 OH! But you couldn't be more wrong. Licensing has everything to do
 with copyright holders in this case, because what we're applying is
 a *copyright license*. ;)

Right, though the licensing is well known. It's the copyright holders
which is very fuzzy and need to be clarified...

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-20 Thread Robert Collins
On 20 October 2013 04:50, Jeremy Stanley fu...@yuggoth.org wrote:

 Well, this is still a fuzzy topic. We have a lot of contributions
 and know who the authors are, but not necessarily who the copyright

s/authors/submitters/. I've heard (though I lack direct evidence) that
some teams funnel their patches through a single submitter [so you
have an influential visible submitter], but the actual author isn't
known :).

So we know a claimed author. I'm not even sure that gerrit cross
references ssh keys and committers - but I expect folk would notice a
totally new patch from someone other than who gerrit says pushed the
code.

 signed agreements to this effect). It would almost certainly take a
 policy decision by the technical committee if we wanted to start
 requiring all authors of new changes to add/update copyright
 statements accurately on every file they touch, and there is quite
 probably no chance at all we can precisely nail down historical
 copyright holder data for previous changes already merged.

I think updating a static registry on every patch is a very high cost
to pay. OTOH registering one's nominated copyright holder on the first
patch to a repository is probably a sustainable overhead. And it's
probably amenable to automation - a commit hook could do it locally
and a check job can assert that it's done.

-Rob


-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-20 Thread Robert Collins
On 20 October 2013 02:35, Monty Taylor mord...@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.

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-20 Thread Joe Gordon
On Oct 20, 2013 11:29 AM, Robert Collins robe...@robertcollins.net
wrote:

 On 20 October 2013 02:35, Monty Taylor mord...@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.

http://ftp-master.metadata.debian.org/changelogs//main/l/linux/linux_3.11.5-1_copyright

Not even the kernel itself has a complete list of all the copyright owners.

best,
Joe

sent on the go


 -Rob

 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-20 Thread Thomas Goirand
On 10/20/2013 05:41 PM, Joe Gordon wrote:
 http://ftp-master.metadata.debian.org/changelogs//main/l/linux/linux_3.11.5-1_copyright
 
 Not even the kernel itself has a complete list of all the copyright owners.
 
 best,
 Joe

Well, good luck finding all the copyright holders for such a large and
old project. It's not really practical in this case, unfortunately.

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-20 Thread Jeremy Stanley
On 2013-10-20 20:57:56 +0800 (+0800), Thomas Goirand wrote:
 Well, good luck finding all the copyright holders for such a large and
 old project. It's not really practical in this case, unfortunately.

To a great extent, the same goes for projects a quarter the size and
age of the Linux kernel--doesn't mean we shouldn't try to fix that
though. In our case, we at least have names and (possibly stale)
contact information for all the people who claim to have authored
contributions, so I suspect we're in a somewhat better position to
do something about it.

Part of the issue is that historically the project has held a
laissez faire position that claiming copyright on contributions is
voluntary, and that if you don't feel your modifications to a
particular file are worthy of copyright (due to triviality or
whatever) then there was no need to update a copyright statement for
new holders or years. So the assumption there was that copyrights
which an author wanted to assert were claimed in the files they
touched, and if they didn't update the copyright statement on a
change that was their prerogative.

I think we collectively know that this isn't really how copyright
works in most Berne Convention countries, but I also don't think
reviewers would object to any copyright holder adding a separate
commit to update valid copyright claims on a particular file which
they previously neglected to document.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-20 Thread Jeremy Stanley
On 2013-10-20 13:00:31 + (+), Jeremy Stanley wrote:
[...]
 automated job which proposes changes to a copyright holders list
 in each project by running a query with the author and date of
 each commit looking for new affiliations
[...]

Though the more I think about this, it would be complicated (if even
possible) to accommodate contributors with multiple concurrent
affiliations.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-19 Thread Clint Byrum
Excerpts from Thomas Goirand's message of 2013-10-18 23:01:50 -0700:
 
 Hi there,
 
 TroveClient just got rejected by Debian FTP masters. Reply from Luke
 Faraone is below.
 
 In general, I would strongly advise that a clean COPYRIGHT-HOLDER file
 is created with the copyright holders in them. Why? Because it is hard
 to distinguish between authors and copyright holders, which are very
 distinct things. Listing the authors in debian/copyright doesn't seem to
 satisfy the FTP masters as well... :(
 
 FYI, my reply was that I knew some of the authors were working for
 Rackspace, because I met them in Portland, and that I knew Rackspace was
 one of the copyright holders. Though that's of course not enough for the
 Debian FTP masters.
 
 Your thoughts?

Recently there was a movement to remove the copyright headers from all
the files in OpenStack. Some folk disagreed with this movement, and the
compromise was that they were discouraged but allowed.

Nobody who writes code wants to hear that they have to think about
licensing, copyrights, etc. But at a bare minimum, copyrights should be
asserted somewhere in each project's repository.

Now, some people will say thats what we have git for. I suggest to
those who would suggest we just trust git commit logs that this is
not sufficient. For instance, I submit code with my personal email
address, even though it is all work-for-hire and thus sending copyrights
to HP rather than me individually.

I suggest that we just put Copyright headers back in the source files.
That will make Debian's licensecheck work fairly automatically. A single
file that tries to do exactly what debian/copyright would do seems a bit
odd.

 
 Cheers,
 
 Thomas Goirand (zigo)
 
  Original Message 
 Subject: [Openstack-devel] python-troveclient_0.1.4-1_amd64.changes REJECTED
 Date: Sat, 19 Oct 2013 04:00:19 +
 From: Luke Faraone ftpmas...@ftp-master.debian.org
 To: PKG OpenStack openstack-de...@lists.alioth.debian.org, Thomas
 Goirand z...@debian.org
 
 
 Dear maintainer,
 
 debian/copyright is **not** an AUTHORS list. This package appears to be
 Copyright (c) 2013 Hewlett-Packard Development Company, L.P., and some
 other
 companies, not copyrighted each individual employee at HP who worked on it.
 
 Your automated debian/copyright generation is most probably suboptimal for
 most packages, and is most certainly not a substitute for manual review.
 One
 missed copyright holder:
 
 python-troveclient-0.1.4\troveclient\base.py:
 Copyright 2010 Jacob Kaplan-Moss
 
 Cheers,
 
 Luke Faraone
 FTP Team
 
 
 ===
 
 Please feel free to respond to this email if you don't understand why
 your files were rejected, or if you upload new files which address our
 concerns.
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-19 Thread Michael Still
On Sat, Oct 19, 2013 at 7:52 PM, Clint Byrum cl...@fewbar.com wrote:

 I suggest that we just put Copyright headers back in the source files.
 That will make Debian's licensecheck work fairly automatically. A single
 file that tries to do exactly what debian/copyright would do seems a bit
 odd.

The problem here is that the copyright headers were wrong. They aren't
religiously added to, and sometimes people have tried to gift code
to the Foundation by saying the code is copyright the Foundation,
which isn't always true. So, we can't lean on these headers for
accurate statements of copyright.

Michael

-- 
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-19 Thread Monty Taylor


On 10/19/2013 04:52 AM, Clint Byrum wrote:
 Excerpts from Thomas Goirand's message of 2013-10-18 23:01:50 -0700:

 Hi there,

 TroveClient just got rejected by Debian FTP masters. Reply from Luke
 Faraone is below.

 In general, I would strongly advise that a clean COPYRIGHT-HOLDER file
 is created with the copyright holders in them. Why? Because it is hard
 to distinguish between authors and copyright holders, which are very
 distinct things. Listing the authors in debian/copyright doesn't seem to
 satisfy the FTP masters as well... :(

 FYI, my reply was that I knew some of the authors were working for
 Rackspace, because I met them in Portland, and that I knew Rackspace was
 one of the copyright holders. Though that's of course not enough for the
 Debian FTP masters.

 Your thoughts?
 
 Recently there was a movement to remove the copyright headers from all
 the files in OpenStack. Some folk disagreed with this movement, and the
 compromise was that they were discouraged but allowed.

This is not true.

The compromise is that they are not required, and that people would stop
rejecting patches if they did not include a license header.

At no point in time, to my knowledge, did we EVER reach an agreement
that they are actually discouraged. We merely acknowledged that we have
developer apathy on this point and weren't going to get it right.

 Nobody who writes code wants to hear that they have to think about
 licensing, copyrights, etc. But at a bare minimum, copyrights should be
 asserted somewhere in each project's repository.

Also not true. I write code, I care a great deal about licensing and
copyrights. I'm sad that ANY developer working on Open Source software
does not care about these things - I think it's very lame when they don't.

 Now, some people will say thats what we have git for. I suggest to
 those who would suggest we just trust git commit logs that this is
 not sufficient. For instance, I submit code with my personal email
 address, even though it is all work-for-hire and thus sending copyrights
 to HP rather than me individually.

Yup. Agree. git is not sufficient. The only thing that is sufficient is
a positive assertion by an informed developer of their copyright.

 I suggest that we just put Copyright headers back in the source files.
 That will make Debian's licensecheck work fairly automatically. A single
 file that tries to do exactly what debian/copyright would do seems a bit
 odd.
 

 Cheers,

 Thomas Goirand (zigo)

  Original Message 
 Subject: [Openstack-devel] python-troveclient_0.1.4-1_amd64.changes REJECTED
 Date: Sat, 19 Oct 2013 04:00:19 +
 From: Luke Faraone ftpmas...@ftp-master.debian.org
 To: PKG OpenStack openstack-de...@lists.alioth.debian.org, Thomas
 Goirand z...@debian.org


 Dear maintainer,

 debian/copyright is **not** an AUTHORS list. This package appears to be
 Copyright (c) 2013 Hewlett-Packard Development Company, L.P., and some
 other
 companies, not copyrighted each individual employee at HP who worked on it.

 Your automated debian/copyright generation is most probably suboptimal for
 most packages, and is most certainly not a substitute for manual review.
 One
 missed copyright holder:

 python-troveclient-0.1.4\troveclient\base.py:
 Copyright 2010 Jacob Kaplan-Moss

 Cheers,

 Luke Faraone
 FTP Team


 ===

 Please feel free to respond to this email if you don't understand why
 your files were rejected, or if you upload new files which address our
 concerns.

 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-19 Thread Monty Taylor


On 10/19/2013 05:49 AM, Michael Still wrote:
 On Sat, Oct 19, 2013 at 7:52 PM, Clint Byrum cl...@fewbar.com wrote:
 
 I suggest that we just put Copyright headers back in the source files.
 That will make Debian's licensecheck work fairly automatically. A single
 file that tries to do exactly what debian/copyright would do seems a bit
 odd.

 The problem here is that the copyright headers were wrong. They aren't
 religiously added to, and sometimes people have tried to gift code
 to the Foundation by saying the code is copyright the Foundation,
 which isn't always true. So, we can't lean on these headers for
 accurate statements of copyright.

This is correct. As with many things that are harder for us than for
other people, we have =1000 developers and the history thus-far has
been for people to be rather antagonistic and annoyed when someone tries
to suggest proper copyright attribution.

What we CAN say is that every single commit is Apache licensed. Our CLA
and enforcement of it, sad as this statement makes me, ensures that we
know that.

I'm not sure what to do re: FTP masters. Could someone expand for me
like I'm an idiot what the goal they are trying to achieve is? I _think_
that they're trying to make sure that the code is free software and that
it is annotated somewhere that we know this to be true, yeah? Is there
an additional thing being attempted?

Monty

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-19 Thread Sean Dague

On 10/19/2013 08:22 AM, Monty Taylor wrote:



On 10/19/2013 04:52 AM, Clint Byrum wrote:

Excerpts from Thomas Goirand's message of 2013-10-18 23:01:50 -0700:


Hi there,

TroveClient just got rejected by Debian FTP masters. Reply from Luke
Faraone is below.

In general, I would strongly advise that a clean COPYRIGHT-HOLDER file
is created with the copyright holders in them. Why? Because it is hard
to distinguish between authors and copyright holders, which are very
distinct things. Listing the authors in debian/copyright doesn't seem to
satisfy the FTP masters as well... :(

FYI, my reply was that I knew some of the authors were working for
Rackspace, because I met them in Portland, and that I knew Rackspace was
one of the copyright holders. Though that's of course not enough for the
Debian FTP masters.

Your thoughts?


Recently there was a movement to remove the copyright headers from all
the files in OpenStack. Some folk disagreed with this movement, and the
compromise was that they were discouraged but allowed.


This is not true.

The compromise is that they are not required, and that people would stop
rejecting patches if they did not include a license header.


Correction

Would not be rejected if they did not include a *copyright* header.

License headers are still required (we even added a hacking rule for that).


At no point in time, to my knowledge, did we EVER reach an agreement
that they are actually discouraged. We merely acknowledged that we have
developer apathy on this point and weren't going to get it right.


I think the lack of a firm stance here honestly caused more confusion. 
I've seen wildly different interpretations on projects because we're in 
a giant grey area (as can be seen by the different interpretations on 
this list).


Perhaps it's time to open up that giant can of worms again and try to 
get more specific on copyright requirements though I'm not sure the 
discussion would end up any differently.


-Sean

--
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-19 Thread Monty Taylor


On 10/19/2013 08:29 AM, Sean Dague wrote:
 On 10/19/2013 08:22 AM, Monty Taylor wrote:


 On 10/19/2013 04:52 AM, Clint Byrum wrote:
 Excerpts from Thomas Goirand's message of 2013-10-18 23:01:50 -0700:

 Hi there,

 TroveClient just got rejected by Debian FTP masters. Reply from Luke
 Faraone is below.

 In general, I would strongly advise that a clean COPYRIGHT-HOLDER file
 is created with the copyright holders in them. Why? Because it is hard
 to distinguish between authors and copyright holders, which are very
 distinct things. Listing the authors in debian/copyright doesn't
 seem to
 satisfy the FTP masters as well... :(

 FYI, my reply was that I knew some of the authors were working for
 Rackspace, because I met them in Portland, and that I knew Rackspace
 was
 one of the copyright holders. Though that's of course not enough for
 the
 Debian FTP masters.

 Your thoughts?

 Recently there was a movement to remove the copyright headers from all
 the files in OpenStack. Some folk disagreed with this movement, and the
 compromise was that they were discouraged but allowed.

 This is not true.

 The compromise is that they are not required, and that people would stop
 rejecting patches if they did not include a license header.
 
 Correction
 
 Would not be rejected if they did not include a *copyright* header.
 
 License headers are still required (we even added a hacking rule for that).
 
 At no point in time, to my knowledge, did we EVER reach an agreement
 that they are actually discouraged. We merely acknowledged that we have
 developer apathy on this point and weren't going to get it right.
 
 I think the lack of a firm stance here honestly caused more confusion.
 I've seen wildly different interpretations on projects because we're in
 a giant grey area (as can be seen by the different interpretations on
 this list).
 
 Perhaps it's time to open up that giant can of worms again and try to
 get more specific on copyright requirements though I'm not sure the
 discussion would end up any differently.

I think it might be time to open it up again - and seems like a good
test of our new TC's ability to have a discussion on a potentially hairy
topic. The fact that it might be causing a demonstrable issue with the
distros might be a good data point that did not exist last time.

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.

Monty

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-19 Thread Thomas Goirand
On 10/19/2013 08:24 PM, Monty Taylor wrote:
 
 
 On 10/19/2013 05:49 AM, Michael Still wrote:
 On Sat, Oct 19, 2013 at 7:52 PM, Clint Byrum cl...@fewbar.com wrote:

 I suggest that we just put Copyright headers back in the source files.
 That will make Debian's licensecheck work fairly automatically. A single
 file that tries to do exactly what debian/copyright would do seems a bit
 odd.

 The problem here is that the copyright headers were wrong. They aren't
 religiously added to, and sometimes people have tried to gift code
 to the Foundation by saying the code is copyright the Foundation,
 which isn't always true. So, we can't lean on these headers for
 accurate statements of copyright.
 
 This is correct. As with many things that are harder for us than for
 other people, we have =1000 developers and the history thus-far has
 been for people to be rather antagonistic and annoyed when someone tries
 to suggest proper copyright attribution.

Though the Debian FTP masters seems to insist on having correct
copyright holders in debian/copyright, and I am a bit lost after the 2
rejects I just had.

 What we CAN say is that every single commit is Apache licensed. Our CLA
 and enforcement of it, sad as this statement makes me, ensures that we
 know that.

The licensing has nothing to do with copyright holders. These are 2
different topics, please don't mix them in. :)

 I'm not sure what to do re: FTP masters. Could someone expand for me
 like I'm an idiot what the goal they are trying to achieve is? I _think_
 that they're trying to make sure that the code is free software and that
 it is annotated somewhere that we know this to be true, yeah? Is there
 an additional thing being attempted?
 
 Monty

I believe you are right. I'll point them to this thread.

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-10-19 Thread Jeremy Stanley
On 2013-10-19 23:29:28 +0800 (+0800), Thomas Goirand wrote:
 Though the Debian FTP masters seems to insist on having correct
 copyright holders in debian/copyright, and I am a bit lost after the 2
 rejects I just had.

Well, this is still a fuzzy topic. We have a lot of contributions
and know who the authors are, but not necessarily who the copyright
holders were on behalf of whom they might have contributed various
changes (only that the copyright holders authorized them to
contribute this work under a specific license, because the authors
signed agreements to this effect). It would almost certainly take a
policy decision by the technical committee if we wanted to start
requiring all authors of new changes to add/update copyright
statements accurately on every file they touch, and there is quite
probably no chance at all we can precisely nail down historical
copyright holder data for previous changes already merged.

 The licensing has nothing to do with copyright holders. These are 2
 different topics, please don't mix them in. :)
[...]

OH! But you couldn't be more wrong. Licensing has everything to do
with copyright holders in this case, because what we're applying is
a *copyright license*. ;)
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev