Updated license - please comment

[Karsten M. Self]

on Wed, Jun 18, 2003 at 05:13:26PM -0400, Forrest J. Cavalier III (forrest at mibsoftware.com) wrote:
> Mark Rafn <dagon at dagon.net> wrote, in part:
> 
> > It doesn't even seem close to me.  Let me know if I'm insane, or reading 
> > it wrong, but I can't see how such a restriction can be considered open 
> > source.
> > 
> > I know they're straight from the LGPL, but they are irrelevant there
> > because the LGPL is a pure superset of the GPL (see LGPL section 3),
> > unlike the license under discussion.
> > 
> > Yes, this indicates that I think the LGPL without section 3 would 
> > be non-open-source.
> > 
> 
> I agree with you.
> 
> I have difficulty understanding 2d.  It seems complicated.
> 
> In private email, Christophe Dupre summarized the intention this way:
> 
> > 2 d is there to make sure that the library remains usefull by
> > itself, and does not become a wrapper for proprietary tools.
> 
> I don't know if 2 d meets that intention or not.  It is hard to
> understand 2d.  But I have my doubts that the intention is compatible
> with Open Source, (depending on how we define "Proprietary")

This and other comments regarding this license suggest to me that RPI is
repeating the frequent error of confounding source licensing with
submission management.

Source licensing are the terms under which you license your code,
outbound.

Submission management is the process, including both terms (e.g.:
copyright assignment, acceptence and denial rules) under which a project
accepts code for inclusion in the core project corpus.

These are very different, and only slightly related, issues.  Many
newcomers (particularly newcomers with a significant organizational
structure) to the FLOSS scene confound the two issues.  Frequently to
their own detriment.  Most follow one of two tracks:  the project
founders, or more conventional licensing terms (frequently following
the model of the GNU GPL, LGPL, BSD, or Mozilla Public License) are
chosen.

There is a crucial play on not only the legal, but psychological aspects
of FLOSS development.  Generally, compulsory disclosure / compulsory
submission requirements are widely frowned on.  There is only one OSI
certified license I'm aware of which includes such terms, and as I
recall the project it is associated with has subsequently switched to
more liberal terms (I can't recall if the is the Apple or Sun license).

Significantly, this is the one license recognized by OSI but not the
FSF.



Regarding the quoted comment of Mr. Dupre above, the task of seeing that
the library (in its core proeject implementation) remains a library, and
not "a wrapper for proprietary tools" is really the task of project
management more than the license.  Once loosed to the wild, if copyright
terms allow proprietary integration, then unless mechanisms other than
copyright are sought, use of the work is not regulable.


IANAL, TINLA, YADA.

Peace.

-- 
Karsten M. Self <kmself at ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
   Reading is a right, not a feature
     -- Kathryn Myronuk                           http://www.freesklyarov.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20030623/1444e9c1/attachment.sig>