Open Stack

On Fri, Jan 06, 2012 at 10:44:31AM +0000, Mark McLoughlin wrote:

> > Now, I think that's perfectly fine, because that's how free
> > software/open source has always worked. Indeed it is a key part of why
> > it works. It would be strange if OpenStack did things any
> > differently. But if *that's* okay, why is it not okay for contributors
> > to OpenStack to have the same freedom to indicate their licensing in
> > of contributions in a traditional manner -- namely, by merely
> > providing notice of the license (which might as well be the Apache
> > License 2.0)?  It doesn't make sense. 
> 
> I do agree, but I'm curious what you would argue makes it clear that a
> contribution is intended to be licensed under Apache License 2.0 if that
> contribution is merely a (significant) patch to an existing file
> containing an Apache License 2.0 header in a project containing an
> Apache License 2.0 LICENSE file.
>
> Is simply by contributing the patch to such a project that makes the
> licensing intent sufficiently clear? Or is it simply modifying such a
> file and making the modifications publicly available?

I start out by observing how open source projects typically work in
the real world. Typically, projects do not use any contributor
agreements and typically patches do not contain any explicit licensing
information.  Yet I see no evidence that this has led to any
interesting commercial or legal problem. Quite the contrary, I have
some reason to believe that this lack of formality is one reason why
open source project development works as well as it often does.  The
only way any of this makes legal sense is that open source project
development involves numerous acts of implicit licensing from
developer to developer, developers to public, contributors to project.

What's "sufficiently clear" has no objective answer. You can always
adopt procedures to get more clarity and more safety. For example,
OpenStack has seen fit to use an Apache-style CLA but some would argue
that copyright assignment would provide a marginally more secure
result (I have heard such arguments in general, and they make a
certain amount of sense).

There's a tradeoff between "making sure nothing can possibly go wrong"
(ultimately impossible) and minimizing friction and barriers to entry
for a project, which is often quite important, particularly where a
project has an intimate association with a particular business entity.

> This is the one area that some form of "contributor agreement" makes
> sense to me - requiring the contributor to explicitly make their
> licensing intent clear.
> 
> Simply adding Signed-off-by: to a commit message would be my preferred
> way of doing it, but do you think that helps clarify the intent or even
> whether such clarification is useful?

I like the Linux kernel approach (Signed-off-by requirement with a
brief but explicit explanation of what that actually means [the
"Developer Certificate of Origin"] in the patch-submission
documentation in the kernel source tree[1]). I'm known for voicing
skepticism about contributor agreements but I've recommended use of
"signed-off-by" to a number of projects.

Red Hat acquired the assets of Gluster, Inc. recently, and Gluster had
been using copyright assignment for GlusterFS. Shortly after the
acquisition, GlusterFS abandoned copyright assignment in favor of a
Linux kernel-style signed-off-by approach. Does it help/usefully
clarify intent, more than no sort of contributor agreement at all?
Maybe. To me, the important thing is that GlusterFS went from using a
practice that involves a lot of needless red tape and generally
repelled contribution, to a lightweight alternative that is regarded
as accomplishing some similar goals but which no one has ever
complained about, and which has been used for several years now by one
of the most successful and important open source projects in the
world. I'm personally quite happy that GlusterFS has found
"signed-off-by" sufficient for its needs.

> > There are other things one might mention, such as the fact that the
> > Apache License 2.0 ingeniously contains a built-in contributor
> > agreement of sorts already.
> 
> Right, so the "Submission of Contributions" clause in the license puts
> the onus on licensee to explicitly state that they do not intend their
> modifications to be contributed to the project under the license?

That's my interpretation of it. 

- Richard

[1]See <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/SubmittingPatches;h=4468ce24427cb011e7991d8f1ae2560764b170b8;hb=e343a895a9f342f239c5e3c5ffc6c0b1707e6244>