nanogui: Thread: Licensing

In message <Pine.LNX.4.04.9905121938420.1171-100000@hyperspace> Alex Holden writes:
: Hahaha, nice summary of BSD and GPL philosophies :) I am starting to think
: that we'll have to homebrew "Yet Another License" of our own, due to the
: rather unusual situation we're in...

Actually the BSD summary would be more like "Here's the code, do
whatever you want with it" while GNU would be "Here's the code, we'll
do everything we can to make you release all software that comes
within linking distance of this code"

In actual practice, these two methods result in approximately the same
amount of code being shared back with the original authors.  People in
the BSD realm do so because they want to, but some people that use GNU
software ignore the license when it suits them.

Warner

On Wed, 12 May 1999, Warner Losh wrote:
> In message <Pine.LNX.4.04.9905121938420.1171-100000@hyperspace> Alex Holden writes:
> : Hahaha, nice summary of BSD and GPL philosophies :) I am starting to think
> : that we'll have to homebrew "Yet Another License" of our own, due to the
> : rather unusual situation we're in...
>
> Actually the BSD summary would be more like "Here's the code, do
> whatever you want with it" while GNU would be "Here's the code, we'll
> do everything we can to make you release all software that comes
> within linking distance of this code"

We were joking... Notice the smiley face?

> In actual practice, these two methods result in approximately the same
> amount of code being shared back with the original authors.  People in
> the BSD realm do so because they want to, but some people that use GNU
> software ignore the license when it suits them.

Got any examples of the latter? I know there was the Be drivers thing, but
that was resolved quickly and reasonably once someone pointed out to them
that they were breaking the terms of the GPL.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

In message <Pine.LNX.4.04.9905122043170.1171-100000@hyperspace> Alex Holden writes:
: We were joking... Notice the smiley face?

I forgot my smiley face.  I'm sorry. :-).

: > In actual practice, these two methods result in approximately the same
: > amount of code being shared back with the original authors.  People in
: > the BSD realm do so because they want to, but some people that use GNU
: > software ignore the license when it suits them.
: 
: Got any examples of the latter? I know there was the Be drivers thing, but
: that was resolved quickly and reasonably once someone pointed out to them
: that they were breaking the terms of the GPL.

I have been approached by several firms that wish to use Linux in an
embedded system, but do not want any changes made to the base Linux to
be contributed back, nor do they want any of their drivers to be
released in any form whatsoever, except as part of their package.  I
refused this work, so I don't know what finally happened with these
companies products.  Since I have non-disclosure agreements with these
companies as part of the work negotation phase I cannot disclose who
they are.  However, if I ever notice them release products, I'll
suggest that people take a look at their products to see if they are
in compliance.

I have seen companies steal packet drivers, released under the GPL,
port them and then refuse to release the source under any conditions
(major violation), or release the source under different conditions
(eg a BSD license) which is, imho a minor violation.  I have seen
compiler companies make improvements to gcc, gdb and some other tools,
release only the binaries, and then make the unmodified sources
available claiming that the patches to them are proprietary.  I can't
recall the name of the company, as this was a few years ago and the
company is long since dead.  These things came up from time to time on
the gnu.discuss mailing list when I was reading it years ago.

Warner

Warner Losh wrote:

> I have been approached by several firms that wish to use Linux in an
> embedded system, but do not want any changes made to the base Linux to
> be contributed back, nor do they want any of their drivers to be
> released in any form whatsoever, except as part of their package. 

Well, as long as their drivers don't require the modification of the
kernel (ie. properly made loadable modules), they'd be fine.

> I have seen companies steal packet drivers, released under the GPL,
> port them and then refuse to release the source under any conditions
> (major violation), 

Now we're on one of my favorite subjects to rant wildly (and often
inaccurately) about.

I asked Xerox on several occasions if I could have a copy of the
modifications they made to Linux/PPC for their
printer/copier/fax/scanner/slicer/dicer device, and was refused every
time.  I just wanted to see what they had done (I had no real interest
other than curiousity), but still.  Those boxes use a PPC (I think an
820 or similar) CPU with Linux, and a nice LCD interface to the whole
deal.

Personally, I don't like GNU because the folks at GNU/FSF like to claim
credit for things they didn't do.  Just because it's GPL doesn't mean
it's a GNU product.  For example, the GNU folks tried for over 10 years
to get a decent UNIX-like system (HURD) fully operational.  In the
meantime, Linux and FreeBSD became very popular and stable, and the HURD
is still barely there.  You can even run the Linux kernel under CMU
Mach, the microkernel that the HURD is based on.  So what does RMS do? 
Claims that Linux should be called GNU/Linux, 'cause it's mostly
(actually under 10 percent in many cases) GNU.  Sheesh.  But don't get
me started on RMS...

I really liked the idea of making a Linux distro that had as little / no
GNU as possible, with lots more BSD stuff.  The only thing I really see
as missing is a good C compiler.

Reagen

On Wed, 12 May 1999, Alex Holden wrote:
> On Wed, 12 May 1999, Alan Cox wrote:
> > > Hahaha, nice summary of BSD and GPL philosophies :) I am starting to think
> > > that we'll have to homebrew "Yet Another License" of our own, due to the
> > > rather unusual situation we're in...
> > Fortunately not. And the MPL (Mozilla public license) also has been through
> > a real legal body (netscape corporate legal). It works for Mozilla so far

It's in typical lawyer-speak gibberish, but the part of it which applies
here seems to be:

     3.7. Larger Works.
     You may create a Larger Work by combining Covered Code with other code
     not governed by the terms of this License and distribute the Larger
     Work as a single product. In such a case, You must make sure the
     requirements of this License are fulfilled for the Covered Code.

Where:

     1.7. ``Larger Work'' means a work which combines Covered Code or
     portions thereof with code not governed by the terms of this License.

     1.3. ``Covered Code'' means the Original Code or Modifications or the
     combination of the Original Code and Modifications, in each case
     including portions thereof.

     1.10. ``Original Code'' means Source Code of computer software code
     which is described in the Source Code notice required by Exhibit A as
     Original Code, and which, at the time of its release under this License
     is not already Covered Code governed by this License.

     1.9. ``Modifications'' means any addition to or deletion from the
     substance or structure of either the Original Code or any previous
     Modifications. When Covered Code is released as a series of files, a
     Modification is:

          A. Any addition to or deletion from the contents of a file
          containing Original Code or previous Modifications.

          B. Any new file that contains any part of the Original Code or
          previous Modifications.

If I am interpreting this correctly, we can license the code we have under
the MPL, and then any "Modifications" to our code need to be contributed
back to us, but any new code distributed along with it (and it doesn't
explicitly disallow statically linking to it) can be under whatever
license you want. This would seem to be just what we want. Opinions?

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

> If I am interpreting this correctly, we can license the code we have under
> the MPL, and then any "Modifications" to our code need to be contributed
> back to us, but any new code distributed along with it (and it doesn't
> explicitly disallow statically linking to it) can be under whatever
> license you want. This would seem to be just what we want. Opinions?
>

I like it, but, my gosh, the MPL is a large load of legalese...

gh

On Wed, 30 Jun 1999, Greg Haerr wrote:
> 	A month ago we talked about licensing for nano-X, and basically
> agreed that MPL was the way to go.  Where is the MPL license
> verbatim, do you know?  I think I should read it and include it in some
> of the sources to make sure we're covered...

It's at http://www.mozilla.org/NPL/MPL-1.0.html

I'm still not completely convinced that we're allowed to directly link
MPL'ed code to GPL'ed code though (which is what the BSD people are
talking about when they say the GPL is infectious). Even ignoring whether
the GPL allows us to link to MPL code or not, the main problem as I see
it is that the reason we wanted the MPL was so that people can write
proprietory drivers, window managers, etc. of their own and link them
into the server without releasing the source to them, but still ensuring
that they contribute any improvements they make to our code back to us.
That sounds fine, the MPL covers it perfectly, and I can't see most people
having a problem with it. The problem is that the GPL is more restrictive
about this and _doesn't_ let you link any proprietory code to it and
distribute it, and currently we only have permission to license David
Bell's code as GPL, not MPL. We're going to have to ask David if he's
prepared to let us relicense it as MPL or not (I think he's still lurking
on the list- any comment David?), and if not, go back to the drawing board
on licensing. A generic dynamic linking mechanism is a possibility, but
RMS has stated (with reference to Linux kernel modules) that in his 
opinion even that is a breach of the GPL, but that it's up to the authors
of the code in question whether they allow it or not. It's a shame that
open source licenses have become such a religious issue when all we want
to do is write freely available code.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Thu, 1 Jul 1999, Alex Holden wrote:
> Bell's code as GPL, not MPL. We're going to have to ask David if he's
> prepared to let us relicense it as MPL or not (I think he's still lurking
> on the list- any comment David?), and if not, go back to the drawing board
> on licensing. A generic dynamic linking mechanism is a possibility, but

Okay, David mailed me privately about this, and whilst he is happy to
license the code as LGPL, he says he doesn't know enough about the MPL to
comment on it (I explained why it seems ideal for Nano-X and gave him a
pointer to where to find it but didn't get a response). So, I'm not sure
where to go with the licensing now. The LGPL obviously doesn't fit the
Nano-X model as it has various built in assumptions and rules which only
make sense if the code is in the form of a library which can be linked to
a proprietory program, rather than a program which allows proprietory
drivers and programs to be linked into it. The GPL is clearly not ideal as
if you license any part of the program as GPL, all of it (including any
proprietory stuff people might want to link into it) has to be GPLed.
Dynamically loading of the proprietory code is a possible loophole in the
GPL, but it seems a bit hacky really, especially if we want to be easily
portable. Going with a BSD style license without the advertising clause
(basically "do what you want with it except for removing the copyright
notice") is a definite possibility, since David's original copyright was
compatible with that model, except that some of us want the protection of
a license which requires improvements to our code be contributed back to
us.

So what seems to be left is:
* Hope that David changes his mind.
* Go with LGPL, accept the limitations it would impose on the way we code
(defined APIs between the proprietory and non proprietory code, etc.), and
hope that nobody notices that the license doesn't make any sense for our
use of it.
* Don't provide any way to load proprietory code (clearly what RMS would
want, but would reduce the attractiveness of Nano-X to companies wanting a
tiny windowing system for embedded use, who otherwise might have helped us
improve Nano-X).
* Write the mini-X code out of Nano-X (quite a large and thankless task,
and a lot of effort to have to put in just to get around copyright
problems).

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

> * Go with LGPL, accept the limitations it would impose on the way we code
> (defined APIs between the proprietory and non proprietory code, etc.), and
> hope that nobody notices that the license doesn't make any sense for our
> use of it.

Well lets face it the only compiled into the application situation we are
likely to have is Linux 8086. That is a known hotbed of proprietary commercial
software 8)

Everyone else uses it client/server so its not a big deal - except maybe boot
disks, and if Debian or RH use it instead of Bogl alone it will be with GPL'd
installers so a non issue

Alan

Alex Holden wrote:

> * Go with LGPL, accept the limitations it would impose on the way we code
> (defined APIs between the proprietory and non proprietory code, etc.), and
> hope that nobody notices that the license doesn't make any sense for our
> use of it.

My understanding is that even under LGPL you still suffer 'pollution'
unless your very careful.  By this I mean, if you had a propriety part
that will form part of the 'library' that other people are going to use,
this gets polluted and falls under LGPL.  The only way that proprietary
code is kept clean is if it an application uses the LGPL'ed stuff as a
library.


Stuart.