Re: licenses, etc

Hi Alex, Given all the different scenarios, I suggest that the LGPL is your best bet. If you try a mixed license, you may end up with something like the Sun Java 'community' license, which: 1. enforces contribution of code refinements 2. allows sun to at any point do something proprietary. If you go with GPL you force anyone using binarycloud to GPL any additions, which will not sit well with all prospective paying non-technical clients. I believe the PHP community has show an extraordinary commitment to improving software, fostering communication and learning, and holding to the spirit of open-source. LGPL with an encouragement and kudos for contribution where possible still keeps binarycloud open, but allows people to write applications with it. From my understanding, under LGPL any fundamental 'core' changes will be included under the license, though if developers do need to keep modules separate, they will be able to, but will also have the freedom of including any modules under LGPL if they want to. In short, my opinion is that GPL is best used for 'complete' applications, so that they cannot be extended in a proprietary manner, locking out competitors and robbing the development community of refinements they have a direct stake in and responsibility for. I believe LGPL is much better when creating code that may be used as foundation building blocks for other applications that may, in a business sense, exceed the scope of the original application. Best regards, Andrew ---------------------------------------------------- Andrew Hill Director Technology Evangelism OpenLink Software http://www.openlinksw.com XML & E-Business Infrastructure Technology Provider On 12/17/00 5:35 PM, "Alex Black" <enigma@turingstudio.com> wrote: > hi all, > > andi gutmans has brought up a good point, along the lines of some thinking I > have been doing re: licensing. > > binarycloud is composed 80% of "new" code, which I have initially put up > under the GPL. there is also some code included in the distribution that we > did not write, under those circumstances we identify it as such in the > header, and include whatever was included with the script. > > so.. > > this presents a problem. > > here is a response to andi, which covers it: > ----------------------- > there are a few separate issues: > > -I want any modifications/improvements people make to the core code > (libs, base components like permissions) to be contributed back. > > -I want all significant changes to opensource _modules_ (think of them > like little page-building applications) to be contributed back. > > -Anyone who builds modules that use the binarycloud infrastructure, so > long as they build the module from scratch, i.e. a checkout module for a > specific site, should be able to keep that code proprietary. > > I'm running a commercial installation on binarycloud right now. It hasn't > gone live yet, but it's on the production servers and will go up in january. > Obviously a good deal of that code is proprietary, and is in fact someone > else's intellectual property. > > So you see my problem, kind of the split personality thing. > ----------------------- > > In some cases the lgpl is relevant, in other the GPL is more relevant... > > I'm thinking of writing a specific license for systems of this complexity, > kind of the "framework" license. > > What do people think of that? > > Given those three "constraints" - does anyone know of an existing license > that is applicable, or should I get one written? > > _a > > > -- > Alex Black, Head Monkey > enigma@turingstudio.com > > The Turing Studio, Inc. > http://www.turingstudio.com > > vox+510.666.0074 > fax+510.666.0093 > > Saul Zaentz Film Center > 2600 Tenth St Suite 433 > Berkeley, CA 94710-2522 > > > >