Contribution agreements (Re: [sldev] What is the point offirstlook
and giving feedback to LL)
robla at lindenlab.com
Tue May 6 21:36:52 PDT 2008
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.
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.
More information about the SLDev