A few more logs for the flame (err...thread), BSD and Dave's original
license?  Maybe even a NASM type license, short and sweet, with
restrictions against those who would like to use the code for commercial
purposes.  IMHO, the GPL and LGPL are too detailed and too restrictive.
People who enjoy the code should use the code.  Maybe those who have evil 
commercial purposes should be punished, but they should not be completely 
prejudiced against.  I think the intent is to make the Nano/Micro series
a standard for small systems. I also like Allegro's gift society type
license though it may not be restrictive enough for some.

------------------------------------------------------------------
"It's not about the money...It's about the rules.  Without rules,
   we might as well be tree climbers flinging crap at each other."
                          - Red Foreman of That '70s Show

On Mon, 4 Oct 1999, Gregory Leblanc wrote:

> I've been kind of following this thread, since it's fascinating.  Anyway, I
> know the GPL, and I've read the LGPL a couple of times, but I can't find
> this other one, MPL.  Any pointers?  
> 
> > -----Original Message-----
> > From: Bradley D. LaRonde [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, October 04, 1999 2:32 PM
> > To: Alex Holden
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Re: Request for comments - Microwindows
> > 
> > 
> > > On Mon, 4 Oct 1999, Bradley D. LaRonde wrote:
> > > > So if I'm understanding you right, you are saying that we 
> > might have an
> > > > opportunity with Micro* to do something similar, but only 
> > if we GPL the
> > > > server part (or maybe LGPL?), but definately not MPL it.  
> > Is that right?
> > >
> > > Because of the restrictive nature of the GPL, you can't legally link
> > > proprietory code into it. The Linux kernel on Intel PCs, 
> > with millions of
> > > potential users, is just starting to become popular enough 
> > that we can
> > > actually force some hardware vendors to release specs to 
> > allow a GPLed
> > > driver to be written, or to even write a GPLed driver 
> > themselves. Up till
> > > fairly recently, and with less common hardware, this didn't 
> > usually work,
> > > and a lot of hardware had to be reverse engineered.
> > 
> > I don't mind reverse engineering something.  The tempting 
> > thing is when a
> > vender says they'll give you the specs but you can't release 
> > anything but a
> > binary.  That is something to avoid IMO.  Maybe it is better 
> > to reverse
> > engineer it than to cave to the vendor's desires.
> > 
> > Why give up your right to release source code?  Why not tell 
> > that vendor
> > "I'll sign and NDA, but only with the condition that I can 
> > release my work
> > open-source."  I have.
> 
> Agreed.  If we have to reverse engineer some drivers, so be it.  But we
> should demand that our work can be released GPL'd.
> 
> > 
> > > How long do you think
> > > it'll be before Nano-X on Foo obscure Palmtop or embedded system has
> > > enough millions of users for a hardware manufacturer to be 
> > forced into
> > > releasing a GPLed driver or specs for somebody to write a 
> > GPLed driver for
> > > it? Roughly never?
> > 
> > If Linux was guided from the start by that thinking, it may 
> > never have made
> > it to that point either.
> > 
> > I think that GPL is the answer for the server part.
> > 
> > Do we believe in this thing or not?  I do.
> > 
> > Are we willing to reverse engineer a few devices?  Are we 
> > willing to have to
> > write some extra code now and then?  I am.
> > 
> > So let's just take a deep breath, GPL the server part, go 
> > forward, and not
> > look back.
> > 
> > As for the client part, same thing execpt add an L before the GPL.
> > 
> > Regards,
> > Brad
> > 
> 

Reply via email to