lkml.org 
[lkml]   [1998]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: FreeGPL license proposal (was Re: Linus Speaks About KDE-Bashing)
    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

    \
     
     \ /
      Last update: 2005-03-22 13:43    [W:5.377 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site