Open Stack

On 01/21/2014 05:02 PM, Richard Fontana wrote:
> On Tue, Jan 21, 2014 at 02:46:29PM -0500, Rich Bowen wrote:
>>
>> I would suggest language like what you see here: http://svn.apache.org/repos/
>> asf/httpd/httpd/branches/2.2.x/server/vhost.c
>>
>> So, perhaps:
>>
>> /* Licensed to the OpenStack Foundation under one or more
>>  * contributor license agreements.  See the NOTICE file distributed with
>>  * this work for additional information regarding copyright ownership.
>>  * The ASF licenses this file to You under the Apache License, Version 2.0
>>  * (the "License"); you may not use this file except in compliance with
>>  * the License.  You may obtain a copy of the License at
>>  *
>>  *     http://www.apache.org/licenses/LICENSE-2.0
> 
> I can't resist using this as an opportunity for a rant related to some
> things I've said before, not entirely off-topic. 
> 
> It's my understanding, and this is reinforced by the existing practice
> of copyright and license notices in OpenStack source files, that there
> is an understanding that a contributor is both granting a license
> under the relevant CLA and granting a license under the terms of the
> Apache License. I could point out that it is potentially even more
> complicated than that but let's keep it there for simplicity. I've
> contended that this is a form of duplicative licensing unprecedented
> in open source software development; if anyone has a counterexample
> I'd be happy to know about it. The reason it's unprecedented is that
> CLAs exist precisely so that contributors won't be granting in
> licenses under the project license (leave aside whether that's a good
> or bad thing). There are tons of Apache License projects that have
> contributors licensing contributions under the Apache License, like
> oVirt and OpenShift Origin, but these are the projects that don't use
> CLAs.
> 
> While -- as was noted today in a Twitter conversation -- ASF projects
> normatively accept 'smaller' patches without a CLA (the understanding
> being they are licensed under the Apache License itself), the only
> thing recorded in source code is the license grant from the ASF and,
> in some cases, the note that the code was largely licensed in under
> (nonpublic) CLAs, as in the ASF notice that you've adapted.
> 
> Your suggestion might make perfect sense, particularly to someone
> coming from the ASF tradition, but it calls into question why this
> duplicative licensing appears to be taking place. This is not the case
> for ASF projects. As an arbitrary example, a lot of Red Hat copyright
> licenses flow into Apache Camel, but Red Hat isn't granting an Apache
> License on Apache Camel (via apache.org at least), because Red Hat is
> the licensor of a CLA covering employee contributors to Apache Camel
> and that's the extent of the licenses it is granting in to that
> project. A copyright notice from Red Hat in Apache Camel would violate
> ASF standards but would be accurate. A Red Hat copyright notice
> immediately followed by an Apache License grant would be inaccurate,
> because the Apache License isn't coming from Red Hat; it's coming
> (mostly) from the ASF.
> 
> To understand my point here, look at any other project that uses CLAs,
> and you will see that there are no contributor copyright notices other
> than, in some cases, copyright notices from the main CLA licensee
> (here the OpenStack Foundation). OpenStack is the only exception I'm
> aware of, and I believe the rationale for having such contributor
> copyright notices at all is to make visible that, separate from the
> CLA, direct Apache License grants are being made by CLA signers.
> 
> Your proposal is one visible way to cease the practice of duplicative
> licensing. However, OpenStack developers and fellow travelers who have
> criticized the CLA regime won't like this, because it signifies full
> reliance on the CLA regime. 

For what it's worth, from my direct experience, < 20% of our developer
community understands this distinction. And probably < 50% of our core
review team members. For many this is the first open source project
they've ever worked on.

Which, on the one hand, is very cool. OpenStack is bringing new people
to Open Source development. On the other hand, it means at a certain
point people just generally agreed not to -1 code over people screwing
up the copyright line, because it was getting exhausting, and confusing
to new contributors. We've had 1000 active developers over the last 12
months. That's a ton of education to provide.

The copyright lines in OpenStack are thus terribly inaccurate, and I
don't really see that changing unless there were a team of people
reviewing for them. Honestly, I'd be happy to see that, especially if it
got us away from the CLA. But realize this is about review mental
bandwidth, and a pragmatic policy was adopted in most projects to ignore
the issue lacking clear guidance on policy.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/legal-discuss/attachments/20140121/3d11b964/attachment-0001.pgp>