Resolving the licensing issues.

[Jim Thompson]

Rob Landley wrote:

>On Wednesday 01 March 2006 1:06 pm, Jim Thompson wrote:
>  
>
>>>A patch based on existing code is not a derivative work?  OK, it might
>>>be "your derivative work", but it's a derivative work, right?
>>>      
>>>
>>Yes, and that means that if the implmentor of the patch distributes the
>>code (containing) the patch outside his org, *then* the GPL comes into
>>play.
>>
>>The FSF (who know the rules about as well as anyone) require written
>>assignments for submitted patches to FSF-maintained code before it goes
>>in the tree.
>>
>>I can't see how this situation is any different.
>>    
>>
>
>The FSF wants written assignments for copyright, not for licensing purposes.  
>They actually want the copyright (or at least an interest in the copyright) 
>transferred over to them so they have an easier time establishing standing if 
>they ever need to sue anybody to enforce the GPL.
>  
>
But they've never had to.

>The Linux kernel doesn't do that, and neither do we.  The authors of the code 
>can take action ourselves, or designate somebody to do so on our behalf.  
>Erik does this with the "hall of shame" and despite handing over 
>maintainership (because buildroot is now taking up the non-uclibc time he 
>used to spend on busybox) his copyrighted code is still all over the place 
>and he'd have no trouble establishing standing.  Bruce Perens wouldn't 
>either, and he hasn't touched the thing since Erik took over.
>  
>
IANAL, but there are legal issues with this approach.   And yes, I
understand the trade-off in increased complexity for you and Erik .vs a
cleaner database and files full of bits of paper that will probably
never be used.

Just don't... think you're completely in the clear, OK?

>The fact the FSF's insistence on physical pieces of paper signing over 
>copyrights was a huge source of friction preventing changes from getting 
>merged and discouraging developers from participating, and was probably as 
>big a factor as Richard Stallman's ego in the original Gnu project stalling 
>and dying 15 years ago.
>  
>
This is the wrong list for this, but... the GNU project didn't "stall"
or "die", and I formally object to your characterization that is has (or
did).  

The FSF requires written assignments for code that is part of GNU for
very specific legal reasons.  These have nothing to do with the ego of
RMS, and everything to do with him actually understanding copyright law
(and having some very good legal advisors, too.)

Once things with SCO started, I think even Linus started understanding
the error of running a process that "open loop".   The kernel committers
have

The additional "friction" in the process created by having to sign and
send bits of paper is likely what caused ESR to break ranks(*) with RMS
and GNU, eventually promoting "open source" instead.

More here:  http://www.smallworks.com/archives/00000396.htm

Personally (and professionally) I figure that I got a lot more than I'm
giving back (and I've been using buildroot/busybox/uclibc based systems
since 2000 or 2001 or so, back before most people knew there was a
buildroot.)   Any work I've done on these (and its been a long dry spell
since I have) is always given back under GPL terms.

Jim
(*) not a big loss in terms of technical talent.  Close examination will
reveal that esr tends to "over claim" what he's contributed.  (Some of
the evidence is on the smallworks.com weblog.)   Even Perens has "torn
the sheet" with esr.