Re: FreeGPL license proposal (was Re: Linus Speaks About KDE-Bashing)

Kendall Bennett (KendallB@scitechsoft.com)
Fri, 17 Jul 1998 12:38:22 -0800


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