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

[Callum Lerwick]

On Tue, 2008-05-06 at 21:36 -0700, Rob Lanphier wrote:
> 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.

Yes, I for one would see this as a major breach of trust with the
community. As such, I really don't think the community needs a promise
from Linden Lab. Rather, I think the the promise should go in the other
direction. Should Linden Lab resort to such shenanigans, the open source
community will quite possibly abandon Linden Lab in a heartbeat and fork
our own project.

> 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. 

IMHO, Linden Lab turning around like this would be a bigger loss for
Linden Lab than it is for the community. And probably a PR nightmare for
LL on top of that. Thus yes, I don't see this happening. ...unless
Linden Lab gets bought out by, say, Microsoft. Such things are possible
in the world of business. Business, and life, is risk. Linden Lab could
get bought out next week. I could get hit by a bus tomorrow. If you
spend all your time trying to avoid any risk of anything ever not going
perfectly your way, you'll never go anywhere or do anything.

Personally I don't think further legally binding assurances are
necessary. The GPL license and not giving up ownership of my own code
are all the assurance I need.

(Is this a bad time to mention I really wish LL would move to GPLv3 or
at least GPLv2+ to get rid of the APR incompatibility, which ironically
makes the viewer unable to merge in outside GPL code? :)

> 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.

I don't understand this reasoning. "Free forever" is the fundamental
goal of the Free Software movement, is it not?

> 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.

This seems perfectly reasonable to me. And Linden Lab is not the first,
or only company to adopt this model.

> 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.

By "stay competitive" LL seems to mean "we like to avoid doing any work
we can instead license from others". Which may seem reasonable from a
pure business sense, but is ultimately a self fulfilling prophecy. If
there's a lack of open source solutions, it's because *you* haven't
worked to create it. The whole power of FLOSS is in that it only has to
be done right once, and everyone thereafter benefits.

Keep in mind, I myself, and others, are willing to, and have *already*
put quite a bit of work in to clearing proprietary dependencies from the
viewer. Without even being paid by LL for it. All that I, for one, ask
is that LL not further bog me down by continuing to add more proprietary
dependencies. It would be a huge slap in the face and a major breach of
trust.

As much as I generally hate black and white thinking, you really can't
have it both ways here. You either have to fully commit to adding no
further closed dependencies, and eliminating existing ones, or I'm just
wasting my time trying to get the viewer into Fedora. (Well, actually
I'm not. Forking is always an option...)

> 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.

I really haven't heard much feedback about OpenJPEG 1.3. Especially not
from LL. Personally I find its performance quite satisfactory as is,
though I am currently sitting on another %15-%25 speedup via some T1
optimization, the merging of which is pending figuring out the situation
with OpenJPEG 2.0... (I see a tarball is up on their download page now,
I still need to take a look at it.)

(Also note that it has been confirmed, MSVC doesn't seem to optimize
worth crap. There is something like an order of magnitude (!)
performance difference between compiling OpenJPEG with MSVC vs gcc. Also
note Intel C++ gets similar performance to gcc. So... don't be surprised
if it's still slow with MSVC. For now use gcc or Intel C++. :P)

> We'll likely be removing at least one of the non-free components
> (FMOD) soon thanks to community contribution (under this agreement!).

fmod 3 is a dead end anyway. Work has to be put in to move to a
different API anyway, so might as well make that API OpenAL... :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080507/3fc5ebef/attachment.pgp