[Bf-committers] Re-licensing issues, contributor agreements

Ton Roosendaal ton at blender.org
Sun Sep 28 19:42:39 CEST 2008

Hi all,

Currently a discussion about upgrading or amending Blender's license is 
quite theoretical... the main hurdle is to have all contributors 
agreeing on such. Some projects tackle it by handing over copyright to 
the Foundation. For Blender that's not practical nor wanted... see for 
example evident benefits from having Fluids or Bullet in our code.

Most of the larger open source projects do have a 'contributor 
agreement' in place, this to legally protect the foundation and the 
project, to clearly indicate the owner's copyright, and sometimes to 
define a (limited) freedom for a foundation to amend licenses.

I've seen a couple of examples now, the Python Foundation has the 
prettiest example I think:
Much easier readable than Apache's:
Mozilla has a different approach:
And Perl goes a little bit further:

Main issue: if we choose relicensing options, we should word the 
"relicensing" in a way that won't conflict with the original intentions 
of the contributors...

Next to such an agreement, we can also make an optional version where 
the copyrights get transfered to the Blender Foundation. That's for all 
my work and currently for Brecht's code, and for all work we did (and 
will do) for Open Projects here.

If we can agree on such agreements, I'll have to contact every 
contributor in the past to get this settled, and - most challenging - 
get the original shareholders of NaN Holding to agree. :)

This topic - and license definition in general - is a good topic for a 
roundtable on the Blender Conference too.

Currently, my preference is to stick to GNU GPL. I'm quite happy with 
the limitations of this license, but would prefer to add a clear 
amendment in Blender's license to exclude Python scripts and .blend 
files from it.
Moving the gameplayer only to LGPL (or MIT whatever) would be quite 
hard to achieve without actually relicensing almost all of Blender's 
core code. This shouldn't be done without a very long and thorough 
review period. :) Same goes for a GPL3 upgrade btw.

To end this long mail, here's an excerpt from a mail from Allison 
Randall, board member of Perl Foundation about this topic. She proposes 
some alternatives.



If you don't have signed assignments or licenses from contributors, then
you have a range of options, and I'd suggest talking to a lawyer to pick
the right option or combination of options for your project. The most
conservative option is to require signed assignments or licenses from
all contributors before making the change. The next is to request
agreement (email is fine) from all contributors without a signed
assignment or license, relying on compilation copyright for the legal
authority to change the distribution license. The first two options work
best in smaller and younger projects, because the larger the project the
harder it is to reach everyone, and the older the project, the more
likely it is that some early contributors will have lost contact with
the project, dropped off the net, or died.

The third option is to rely on the nature of the original license to
allow redistribution under the new license. This won't work if the
original license is GPL, but does work for license upgrades (except GPL
3.0), or compatible licenses (BSD to just about anything, for example).

A fourth option is to make a public announcement that you plan to change
the license, with a note that any contributors who object to the change
should let you know so you can remove their code. This again relies on
compilation copyright for the authority to change the license. It should
really only be used by projects so large or so old that it's impossible
to contact all the contributors (more for social reasons than legal
ones). It's also advisable (though not legally required) to have some
form of signed agreement with committers. For a simple update of the
same license this option is easily workable. For a radical change of
license, you'll probably want to lean more toward option two, at least
getting assent in some form from as many contributors as possible.

(I've spent a good bit of time with lawyers on this over the past few
years, relicensing Parrot and planning to relicense Perl.)



Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands

More information about the Bf-committers mailing list