:-( Apparently I'm not doing so great at reply-to-list these days ---------- Forwarded message ---------- From: Mark Washenberger <mark.washenberger@markwash.net> Date: Thu, May 2, 2013 at 12:33 AM Subject: Re: [openstack-tc] Copyrights and License Headers in source files To: Mark McLoughlin <markmc@redhat.com> On Wed, May 1, 2013 at 10:53 PM, Mark McLoughlin <markmc@redhat.com> wrote:
Hi Mark,
On Wed, 2013-05-01 at 14:57 -0700, Mark Washenberger wrote:
Hi folks,
I was looking into the ASL-2.0, and chanced across the fact that in Apache projects, they require that source files only have the License Header, and may not have any copyright notices [1]. It occurred to me that we waste a fair amount of time on copyrights in license headers, and it would be nice not to have to do that anymore.
Like Monty said, I'd like to hear more about why these are seen as a time sink.
From this data, I think its clear that coders are making mistakes about
I'm having a difficult time providing hard numbers for you. I think one way to check for this would be to grep gerrit review notes, but I don't know how to do that. But in a non-exhaustive search, I can see some examples https://review.openstack.org/#/c/27001/ -> headers were missing from empty files, caught in review (eventually) https://review.openstack.org/#/c/23044/ -> copyright had wrong year (caught in review) https://review.openstack.org/#/c/22742/ -> just my fault, but I misunderstood the copyright policy and got someone to change to "Openstack Foundation" from their company https://review.openstack.org/#/c/20927/ -> wrong year (caught in review) https://review.openstack.org/#/c/20926/ -> wrong year (caught in review) https://review.openstack.org/#/c/20925/ -> wrong year (caught in review) https://review.openstack.org/#/c/20914 -> should be "Foundation" not "LLC", not caught in review https://review.openstack.org/#/c/21130 -> s/LLC/Foundation/ not caught in review I found these by manually inspecting only the latest 13 results I got when I searched for commits in glance that add files. licensing/copyright headers, and reviewers are having to pause to think about the correctness of those headers. While the amount of effort here isn't necessarily very large, I'd like to draw your attention to the amount of effort that it probably should be: 0. In proportional terms, we're pretty far away from ideal :-)
I also noticed a previous conversation [2] on this subject. I have not found any policy that actually requires us to include copyrights with each source file license header.
Feel free to suggest that this is more trouble than it is worth, but I'd like to propose that we discourage new contributions from including copyright attribution, and provide a process to work with the various parties we have to remove the copyrights from existing files.
I don't have a massively strong opinion on this and I'd never really considered the possibility of not having copyright headers, but my first thought is that I like that we have them. I like that "ownership" of the work is distributed and it's nice to be able to see how that ownership is distributed through the code base.
I'd never considered it either, until I found out that Apache Software Foundation projects are explicitly required to *not* put copyright headers in their source files (they do, however, retain license headers). I realize that rule doesn't apply to us, but if it's good enough for ASF, how are we different? I'd also contend that the view of ownership you get from looking at copyright headers is pretty inaccurate. For example (again from Glance), $ git grep -i rackspace | grep -i copyright | wc -l 0
In any case, I think it's too late for us to effectively make a change in like this successfully and not worth the hassle.
I would agree if I thought that such a change required any of the following: 1) changing existing copyright headers 2) changing the CLA 3) changing bylaws But I don't think those are needed. If we simply said "stop adding copyright headers", then I believe I could write a flake8 hacking rule to check for correct license headers (sans copyright) on new files. That would be enough for me, because my goal here is for people to not have to think about such headers during future development and review.