on Wed, Jun 18, 2003 at 05:13:26PM -0400, Forrest J. Cavalier III ([EMAIL PROTECTED]) wrote: > Mark Rafn <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
pgp00000.pgp
Description: PGP signature
