[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: FreeGPL license proposal (was Re: Linus Speaks About KDE-Bashing)
From:       "Kendall Bennett" <KendallB () scitechsoft ! com>
Date:       1998-07-17 20:38:22
[Download RAW message or body]

Hi Richard,

> There are two drawbacks with the Mozilla Public License.
> 
> 1. It is not a real copyleft, because its form of copyleft applies
> only to changes within an existing source file.  Anyone can easily
> make proprietary extensions to an MPL-covered prorgam by putting his
> code into subroutines and putting them in separate files.

I can see how the current Mozilla license allows this, but it could 
be specifically disallowed by the addition of a subsection 'C' to the 
definition of a 'Modification' in section 1.9:

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.

  C. Any new file added to the series of files such that this file is 
required to recompile the Product or Library.

This would probably require a new defintion for 'Product' and 
'Library' in the definitions section. However the real issue here is 
that proprietry code can still be *linked* with a library covered by 
the Mozilla license (like our MGL) or with a library covered by the 
LGPL. Hence putting the code into a separate file that is linked into 
the library or putting the code into a separate file that is linked 
separately to the library is just semantics. Either way it can still 
be done with both licenses.

The big difference is that the LGPL requires that developers who do 
link with an LGPL'ed library provide the sources to the LGPL'ed 
library to their customers, and also provide binaries of the object 
files for the customer so they can re-link the application. This is 
simply not acceptable for commercial developers wishing to use an 
LGPL'ed library.

I personally believe that it is in the best interests of the Open 
Source community that commercial developers are *able* to use Open 
Source's in commercial products, because this widens the number of 
developers using that Open Source code and hence means the source 
code is more likely to be enhanced and maintained as Open Source code 
(the licensing forbids it from ever becoming proprietry so commercial 
developers can't legally just 'rip it off').

> 2. It is incompatible with the GPL.  In other words,
> if program A is released under the MPL and program B is
> released under the GPL, linking A and B cannot be done
> in a way that complies with both licenses.

This is true, but the only *reason* this is true is because the 
GPL/LGPL is too anti-commercial and commercial developers really 
can't use this code easily in a legally compliant fashion. If the 
GPL/LGPL was modified such that it was more compatible with 
commercial developers using such code, then the two licenses *would* 
be compatible (and perhaps we could kill off one and settle on a 
single license for the entire Open Source community).

Note that LGPL'ed code can be linked with MPL'ed code without any 
problems, so the use of LGPL'ed libraries with MPL'ed libraries 
should not be an issue. The issue is with regular GPL'ed code, 
however the entire substance of the GPL inhibits any code being 
linked with it that is not at 'least as free'.

Perhaps the GPL 3.0 should be modified such that linking with a 
library that is not also under GPL or a license that is at 'least as 
free' is allowed. This is already allowed if the libraries are 
'system components', but the gray definition of a system component is 
what has sparked the entire KDE/Qt debate.

> If you want to release a program in a way that isn't a firm copyleft,
> but allows linking it with anything whatever, I suggest using either
> the LGPL or the distribution terms used for Guile.

We are releasing development libraries, not entire programs. I 
*really* *really* wanted to the use LGPL and we studied it for many 
weeks and reviewed it with our lawyers. The requirements for use by 
commercial developers were too high and we had to find an alternate 
license.  The Mozilla license fit the bill for us perfectly.

Perhaps if your LGPL 3.0 that I keep hearing about fixes some of 
these issues, we could switch our code over to LGPL 3.0 (which would 
I assume facilitate code sharing between GPL and LGPL 3.0 products?).

BTW, I have no idea what Guile is, so perhaps you can point me at a 
reference?

Regards,


+--------------------------------------------------------------------------+
|        SciTech Software - Building Truly Plug'n'Play Software!           |
+--------------------------------------------------------------------------+
| Kendall Bennett                     | Email: KendallB@scitechsoft.com    |
| Director of Engineering             | Phone: (530) 894 8400              |
| SciTech Software, Inc.              | Fax  : (530) 894 9069              |
| 505 Wall Street                     | ftp  : ftp.scitechsoft.com         |
| Chico, CA 95928, USA                | www  : http://www.scitechsoft.com  |
+--------------------------------------------------------------------------+

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

[prev in list] [next in list] [prev in thread] [next in thread]