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

[Rob Lanphier]

Hi Richard,

This set off a good discussion at Linden Lab on this topic. Rather than 
keep everyone in the dark about where our thinking is at, I'm going to 
just let you know where we're at.

More inline:

On 5/4/08 1:08 PM, Richard M Stallman wrote:
> Allowing the contributor of a change to use his own code
> however he wishes, even after he has contributed it to
> the original program, is the right thing to do.  But I think
> it is not enough to deal with this issue.
>
> The possibility I would like to avoid is that the developer might
> include my code in a non-free version while not including it in his
> comparable free version.  If he did that, then my contribution would
> primarily aid non-free software.  Even though I would be allowed to
> add it myself to a free fork -- supposing there is one -- that would
> not be enough to change the situation.  

If I understand this correctly, you're worried that we might take a 
contribution and include it in a proprietary fork of the code, while 
also publishing a free version of the code that doesn't include the 
contribution.   We'll call this scenario #1 for purposes of this 
conversation (you'll see why in a bit).  If that's all the issue is, I 
agree that'd be kind of a crummy thing to do.  I can't see why we'd have 
an interest in doing that.  However, any legally binding commitment we 
make would likely result in us unintentionally surrendering legal rights 
that we'd still like to reserve, which I'll describe below.

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.  Since we can't easily extract 
contributions that are marbled in with our original code, any commitment 
we make for the contributed code is practically intertwined with our own 
code.  Thus, with a commitment in place not to close ours+contributed 
code, we'd be powerless to ever close it.  While that may seem a 
desirable outcome for the free software community, that's a very tough 
commitment to make for a company which has so much invested in this 
asset.  Looking at this from the point of view of our investors, if we 
became convinced that we just wouldn't get contribution at all without 
making that commitment, we'd /possibly/ change our tune, but it's also 
very possible that being forced to commit to making all future versions 
free forever might instead drive us away from being fuller members of 
the free software community.

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.  Such software can also be used by proprietary 
developers, but free software developers get the advantage of not having 
to pay us for the privilege, where as companies that want to keep their 
modifications closed have to pay.  I think this is a net win for the 
free software community.

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.  We've generally advocated to everyone that has licensed us 
proprietary technology that they offer their code as free software and 
have had some pretty stern conversations in a case or two.  We even 
purchased a company (Windwark Mark) and together subsequently freed the 
software they wrote.  However, this is a pretty tough market segment to 
find all-free software and still stay competitive with proprietary 
competitors.  We've had many a debate as to where to draw the line, and 
I think that while we're moving more slowly than I would like us to, 
we're moving surely enough toward publishing our own all-free version of 
the viewer, and others have been able to make very functional all-free 
alternatives using our codebase.  We'll likely be removing at least one 
of the non-free components (FMOD) soon thanks to community contribution 
(under this agreement!). All that said, we're not at a point yet where 
we can jettison all of our proprietary components nor have we yet 
successfully convinced the developers of all of these components to free 
their software, but we've made progress.

So, while we agree that scenario #1 is bad, I think that in order to 
really figure out any possible changes in our commitment, we'd have to 
agree on the right outcomes to scenarios #2-4, and then craft wording 
that was well-adjusted to all of these scenarios.

> So I think that we should call on such developers to make a promise
> such as, "If we include your code in a non-free version, we will
> include your code with equal functionality and technical advantahes in
> a free version, and that free version will have all the features and
> capabilities that are common to that non-free version and the free
> version you improved."
>
> With that promise, you will know that your code will contribute to a
> free version that isn't just demoware.

While we aspire toward that goal, I don't think we can make a legally 
binding commitment for the reasons described above.  However, even in 
its current state, a 100% free viewer is a viable option, and well past 
"demoware" state.  Furthermore, I think contributing source code back to 
us is the most  efficient way for everyone involved to keep improving 
toward a better viewer.

Rob