Re: Economics and the GPL

On Thu, 20 Jun 2002, Roger Fujii wrote:

> "Deven T. Corzine" wrote:
> > Funny how Stallman objects to the XEmacs vs. GNU Emacs competition, yet 
> > he seems quite sanguine about GPL vs. BSD competition.
> > 
> > What, did he never learn and understand the Golden Rule?
> 
> I never said he was consistant in applying his views....  :)

No, I guess you didn't. :-)

> > > Saying the FSF will blunt their only weapon is like saying political 
> > > advocates take an oath of silence.  It *might* happen, but the 
> > > incentives are really against it.
> > 
> > You may be jumping to conclusions here -- the legal issues with XEmacs 
> > code would vanish the instant it falls into the public domain, so you 
> > can't be sure that it's appropriate to generalize from that alone.
> 
> actually, it doesn't vanish.  Let's say software copyrights expire in 5 
> years and use Emacs as an example.  What this means to the FSF is that 
> all code > 5 years old will become PD, and all code <= 5 years is GPLed.  
> So, FSF would not be able to enforce the GPL on the PD code.

The PD version could not be enforced by the GPL, since anyone could freely 
use it, by definition.  However, assuming they've got enhancements in the 
past 5 years, the combined work should still be copyrightable, and they 
should then be able to enforce the copyright with the GPL.

If incorporating public domain code would make it impossible to enforce 
copyrights on the modified versions, then logically the FSF should place 
everything in the public domain, right?  Then proprietary products derived 
from that code would be unenforceable, right?

No, I don't believe this.  Unless their changes to the PD version are too 
inconsequential to qualify for copyright protection, incorporating PD code 
into GNU Emacs shouldn't have any bearing on the enforceability of the GPL.  
But I'm not a lawyer -- ask one and see what they say, I guess.

> This is the exact same reason why they won't use Xemacs' code - since 
> they can't enforce the GPL on it (as they are not the copyright holders), 
> they cannot use it.

But that's different, because the Xemacs code HAS copyright holders; there 
is SOMEONE out there with standing to enforce that copyright; they just 
don't know who.  With public domain code, there's no conflict there.

Honestly, I doubt that incorporating the GPL'd Xemacs code would really be 
that detrimental to their ability to enforce the GPL, especially if the FSF 
holds the copyright on the majority of the code.  However, I suspect they 
are being extra-cautious because they want the first case that tests the 
GPL to be as rock-solid as possible, just to be on the safe side.

If there were already court precedents establishing the strength of the 
GPL, they might not take such a hard line about incorporating GPL changes 
from unknown authors?

> So, in this scenario, they could only enforce the gpl on code that is < 5 
> years old - all the rest, they would be in really weak legal standing.  

By definition, they have no standing to enforce it on the public-domain 
code -- any company could make a proprietary product out of the 5-year-old 
code in this case.  But just like that company could protect their modified 
version, the FSF should be able to protect THEIR modified version as well.

> My only point was that it *fact* that they find the dilution of GPLed 
> code not acceptable (otherwise, they would use the GPLed code in Xemacs).  
> Given this, there is a good reason to think that FSF's position on this 
> is far from certain (I didn't say they were lying either).

The Xemacs issue may just be a "slippery slope" concern on their part -- 
suppose they relax a bit more and then a bit more, etc.  Eventually, they 
might find themselves inadvertantly in a minority stakeholder position in 
GNU Emacs, if they're not careful.  Then they would be in a questionable 
position indeed for enforcing the GPL.  And without court precedents to 
back up the GPL, they want to maintain solid standing to try to enforce the 
GPL and set that precedent, if and when the occasion should arise.  It's a 
reasonable precaution, but doesn't necessarily suggest that they want to 
see the perpetual-copyright system continue as it has...

> > A solution to this would be to go back to copyright registration, requiring
> > the source code of copyrighted software to be deposited with the Copyright
> > Office for safekeeping until it expires.  Of course, software publishers
> > would fight tooth and nail against this, but given the public interest in
> > gaining access to that source code once it falls into the public domain,
> > there's a lot to be said for such a requirement, as public policy...
> 
> Ah, this is a different issue.  But this would move it out of the copyright
> scheme and put it into the patent scheme (which I think should have been done
> in the first place).  So, essentially, just as current patents offer protection
> at the expense of disclosure, you would require the code for the same reason.
> A rational plan, but you don't see FSF advocating anything like that.... (at
> least, if they do, they're awfully quiet about it)

This would be an interesting debate, but it's probably an impossible sell.  
Interactions with trade secrets would confuse the issue, for example.  This 
is an interesting idea, but the lobbying against it from the industry (not 
just software, but also the content industry including RIAA and MPAA) would 
be off the charts.

While this might be good public policy, it's not likely to be enacted in 
the foreseeable future, unless effective campaign finance reform and some 
sort of lobbying reform manages to return us to a "government for the 
people" rather than a "government for the corporations" as we've largely 
become.  Oh well...

Deven