Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL)

Richard M Stallman rms at gnu.org
Wed May 7 10:34:31 PDT 2008


It seems to me that your elephants are actually no problem for this.

    Yet another elephant (scenario #4): we have a few proprietary third 
    party components, most of which were added prior to freeing our viewer 
    source code.

This is a serious problem for the use of your viewer -- people in the
Free World cannot use those components -- so I am glad you are working
on replacing them.

But it isn't a problem for the issue at hand.  Clearly the community
contributions are not in those on-free components.  The criterion I
suggested should apply to whatever component the person's
contributions are in.

    Another elephant (scenario #3):  we do allow license our source code 
    (with contributions) to third parties under separate license.  The way 
    we view such deals is that they give us revenue to hire developers that 
    write more free software.

I designed the criterion specifically with that in mind.  You would be
able to do that, using contributions under this criterion, provided
that the version you license out in that way follows the criterion.
In other words, the free version of the same component should have all
the features as the version you license out.  If they are in fact the
same code, as is the case with Qt for instance, the criterion is
automatically satisfied.

    To address one of many elephants in the room (scenario #2):  let's say 
    that Linden Lab decides that it wants to stop publishing the source code 
    for the viewer.  This is a very unlikely scenario in my view, but one I 
    can't unequivocally rule out.

In this situation, my criterion would require that you not include
more of the contributor's code in the future non-free versions than
you include in the last free version.  That should not be difficult.

To make future versions non-free would be rather shocking, and some
contributors might feel betrayed.  Thus, potential contributors ought
to consider this possibility before deciding they want to contribute.
However, that is a different issue, and doesn't interfere with use of
this criterion.

Use of thuis criterion could help convince community developers to
accept the possibility you would stop releasing free versions --
because it would promise them that all of their code that you ever do
use will be in one of your free versions (and most likely in the last
one).



More information about the SLDev mailing list