[legal-discuss] Copyright statements in source
markmc at redhat.com
Wed Jan 22 15:07:15 UTC 2014
On Wed, 2014-01-22 at 08:35 -0500, Sean Dague wrote:
> On 01/22/2014 06:27 AM, Mark McLoughlin wrote:
> > On Tue, 2014-01-21 at 17:02 -0500, 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 think I've seen you allude to this before but it went right over my
> > head.
> > Contributors sign the CLA and this grants the OpenStack Foundation a
> > license (which is slightly more broad than ALv2) to the code. The
> > Foundation then distributes the code under ALv2.
> > You're saying that our copyright notices also signifies that
> > contributors are also granting a license under ALv2 directly to whomever
> > receives a copy of the code.
> > I'd agree with Sean that <20% of our contributors understand this
> > distinction (or its practical significance). In fact I'd guess it's
> > approaching 0% :)
> >> 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.
> > Ok, wow - I never understood that most CLA-using projects don't have
> > individual per-file copyright notices.
> >> 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.
> > This sort of stuff struggles to be seen as a priority issue amongst our
> > contributors IMHO.
> > The issue of copyright notices became a hot topic purely because
> > developers were frustrated when their patches were -1ed for copyright
> > notice nitpicks. This was seen as a waste of time signifying (I guess)
> > that they generally are not seen as important. Your description of their
> > significance (i.e. as a direct license grant) could change that
> > slightly.
> > The issue of our CLA regime is grumbled about regularly but, since it's
> > a pretty low friction process, so there's little urgency around it.
> > I came across one sad/unhappy developer outside the developer lounge in
> > Hong Kong who had been refused access because he's not an ATC. Although
> > he has contributed some small fixes via other people and would
> > contribute more, he (quietly) refuses to sign the CLA even though he
> > fully understands the terms of the CLA. My understanding is he rejects
> > the notion that he needs to enter into an agreement with the foundation
> > in order to be able to contribute code.
> > I think it's time we stepped back and considered all the angles here -
> > not just "drop the CLA", "delete the copyright notices". What do we (the
> > project) want? What are our values?
> > I'd suggest:
> > - We want to be able to distribute OpenStack under the Apache License
> > v2, so:
> > - All code to the project must be contributed under the ALv2
> > - We can incorporate BSD/MIT licensed code from other projects
> > - We can use LGPL, BSD, MIT, etc. licensed libraries; currently,
> > we're being conservative and not using GPL/AGPL libraries
> +1. I think OpenStack shared culture believes in all those things. I'd
> go as far as saying "we hold these truths to be self evident..."
> > - There is no need for contributors to grant the foundation a special
> > license.
> > - We copy the kernel's Signed-off-by/DCO method of having all
> > developers who contribute to a patch state they have the right to
> > contribute the patch under ALv2
> > - We consolidate all copyright notices into a single "copyright
> > multiple authors" notice above the ALv2 header, making it clear the
> > code is directly licensed by the authors under ALv2 without the
> > foundation acting as an intermediary
> > This is just a strawman idea to draw some comments. What am I missing?
> Honestly, I'd be happy with all that.
> I think the technical implementation with our toolchain to enforce
> something like that would be pretty easy. (We're actually really good at
> encoding policy into code once we've agreed on the policy.)
> I think this all just hinges on who can make that policy decision. I
> feel like past discussions here largely fell apart on the fact that
> there was neither a clear concensus (at least not at the TC level), nor
> a clear decision making authority on it.
We (the TC) can probably do the copyright notice change pretty easily,
understanding that it would mean the "duplicative licensing" situation
Removing the need for a CLA (and adding the requirement for
Signed-off-by) would be a change to 7.1(a) of the bylaws and require a
majority vote of >=25% of the individual members.
More information about the legal-discuss