> Would the OSI consider discussing a "Commercial Open Source License" > for "OSI Endorsement" but *not* OSI approval?
> In other words, us commercial folks will pull together a license that > is *almost* OSI compliant. And instead of running folks off when they > ask the enevitable, or pointing them to licenses that (in the eyes of > most commercial organizations) have notable deficiencies, point them > towards and OSI endorsed commercial license?
The questions I would ask you is:
1. Are you confident that enough developers would be interested in using your source under a "not-quite-open-source" license? If you aren't going to get a worthwhile reaction from your intended developer community, it may not be worthwhile pursuing this direction.
2. Are you really really sure you can't achieve your goals using either an existing OSI-approved license or another OSD-compliant license you create?
From your earlier message:
> Existing licenses set forth either too many restrictions, or are not > sufficiently templated to allow a company > to adopt them without giving up control of the license. ie: many of > the commercially-viable or even commercially-interesting licenses are > controlled by one company, which is generally not the copyright holder > of the software being published under that license.
I'm not sure if your concern about "too many restrictions" is for too many restrictions on you (the publisher) or the developer community. But considering the range of licenses, from BSD to GPL to what *I* consider to be "commercial open source licenses" (e.g., MPL, SISSL, IBM PL, RPSL), one would think an existing one would have a reasonble mix. And, even if one doesn't, there's nothing to prevent you from creating another one.
> In other words (pick a > number) X% of the product is truly Open Source, while Y% of the > product is not. Maybe 90/10, who knows. But the key here, is that > the commercial world does "want in" to the Open Source community, > and we're looking for some form of viable comprimise that will let > us work together and be embraced by (or in) the OSD.
You mean like Sun does with OpenOffice.org (LGPL) and StarOffice? Or AOL does with Mozilla (MPL/GPL/LPGL) and Netscape? Or RealNetworks does with the Helix DNA (RPSL) and their commercial products? Or Trolltech does with Qt (QPL) and their commercial editions/tools? Or IBM does with Eclipse (CPL) and WebSphere? I could list lots more here if you need more examples.
In most of these cases, the solution was to use an open source license for the open source bits, and a commercial license for the commercial bits.
Now, depending on what your goals are for your product and the developer community you hope to build, different open source licenses, different commercial license terms, and different slices of your 90/10 split may be in order. This list probably isn't the best place for that kind of discussion, as that gets down into a lot of nitty-gritty stuff peculiar to your business situation. But I'll be astounded if we can't find a mix that will be of value to you and your desired developer community.
It may be I'm totally missing the boat on your areas of concern. If so, please let us know!
-- Mark Murphy | Systems Consultant | CollabNet, Inc. [EMAIL PROTECTED] | +1.908.285.8110 | www.collab.net
-- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
