gpl backlash?

[Wilfredo Sanchez]

| >   NeXT used GPL'ed code for years without adding much value to the   
| > GNU Project because they made lots of NeXT-specific changes and   
| > didn't care at all whether they got folded into the FSF source  
base.
| > Sure the software remaind "free", but none of it ever made it into   
| > the FSF sources and was therefore generally useless to the  
Community.
|
| Except the *NeXT* community.

  OK, that's fair.

| Well, different people have different objectives for opening  
systems up (or
| making open systems in the first place), of course.  My objective is to 
| benefit the user, and make the user's life nice.

  OK, I like that objective.

| For some things, that means simply ensuring that no one can do  
anything to
| the code without letting other people see those changes; the GPL  
is nice
| here.  From past experience this seems to include compilers, since few 
| people can expend the resources to a) write a whole compiler to  
introduce a
| new feature or b) write that feature to be portable across every  
platform
| the original compiler works for.  So the GPL helps to keep people from 
| wimping out, and writing in new features for just one platform.   
However, it
| also provides the incentive that you don't have to write the rest  
of the
| compiler.

  Certainly the GPL has worked well here.  Writing a compiler is  
enough of a pain in the ass that dealing with the GPL, regardless of  
your objections, is likely worthwhile.

  And I'll grant you that the GPL has done great things for free  
software.  In times when nobody in business thought free software was  
interesting, it kept things moving.  To that end, the GPL is a  
wonderful thing.  On the other hand, people are starting to see real  
economic benefit (resource management, compatibility,  
standardization) to open source.

  The GPL's major flaw is its unbounded viral nature.  That scares  
(quite reasonable) people away from it, and I think that's a real  
bummer.  I don't mind the "keep this free" sentiment.  (In fact,  
Apple's license, which I had some input on, has a similar requirement  
to keep derivative works under the same terms, and I think that's  
fair.)  But you have to at least specify what you mean by derivative  
works, and allow for the possibility of integration of open code with  
closed code.  And yes, you can probably find ways to change the code  
such that you don't have to contribute anything of value if you  
dance around the license enough, but I can accept that.

  With the GNU license, there is no telling whether if I write a  
10,000 line program, which has one line:

	system("/bin/ls");

and oops, /bin/ls is from GNU fileutils.  Well, crap, is my program  
infected by the GPL?  Does that means I can't run my program on  
Linux?  Well of course not, you say.  But the license doesn't say,  
and that's just plain silly.  On the other hand, this sort of  
confusion might just render the GPL useless in court, and out goes  
the "protection" that you're after.  Lucky it's never been tried in  
court; I'm quite curious about it.

| For other things, the most important thing for the end user is
| compatibility; internet servers, for instance.  In those cases,  
it's more
| important that *absolutely everything* come from a commnon code base, 
| period.

  Well, it's important that things interoperate, not that they use  
the same code, though sharing code does tend to help that a lot.

| >    1 Infinite Loop, 302-4K, Cupertino, CA
|
| This has got to be a joke...?

  Yes and no.

	-Fred


--
       Wilfredo Sanchez, wsanchez at apple.com
Apple Computer, Inc., Core Operating Systems / BSD
          Technical Lead, Darwin Project
   1 Infinite Loop, 302-4K, Cupertino, CA 95014