Subject: Re: Request opinion on proposed license
From: "Karsten M. Self" <>
Date: Fri, 30 Jul 2004 11:49:06 -0700

on Thu, Jul 29, 2004 at 04:08:00AM -0700, Kevin Halle ( wrote:
> Hello,
>    Thank you all for considering my message.  I am considering
> submitting a request for approval of a new license.  Before
> formally submitting it, I would like to elicit the opinions of
> you, the members of this list, on whether it is likely to pass
> the Open Source Initiative requirements.

Consider putting a blank line between paragraphs for readability.

>    The new license is meant for a parallel programming platform,
> which includes an Operating System, a Virtual Machine
> definition, and a Language.  As such, the hope is that it, or
> software like it, will become a de-facto standard in five to ten
> years time.  In this role, it would be the base upon which a
> wide range of software is developed.

Nice, but irrelevant to licensing.  Leave your marketing departent at

>    The motivation for the license is to provide the highest
> possible level of quality assurance, documentation, and project
> management, as well as a coherent, uniform standard that all
> distributions adhere to, which is critical to gaining acceptance
> outside of the highly-technical community.

These are goals better set by project management and release control
systems rather than a license.

Not that they're bad goals of themselves.

>    I believe that the highest levels of quality assurance and
> documentation can only be provided with monetary support. 
> Further, an active testing program and a body capable of
> enforcing conformance also requires monetary support, in my
> opinion, in order to be maximally effective at guaranteeing
> coherence.

>    Thus, I propose a new license which modifies the GPL.  It
> carries the same language, with the one exception that a
> third-party organisation is named which has the power to
> negotiate with commercial entities.   

I'd discourage this on several grounds:

  - It may be seen by many as gratuitously breaking compatibility with
    the GNU GPL/LGPL codebases.  These codebases constitute roughly
    85-90% of free software by my own count of such repositories as
    Sourceforge and the Debian project's package list.

  - It's largely outside the scope of the principle license.  Licensing
    rights to software reside with the author or copyright assignee.  In
    this light, most GNU Projects require copyright assignment be made
    to the FSF.  My understanding is that these assignments don't allow
    the FSF to negotiate additional, non-GPL licensing terms, but a
    third party developing an independent project could certainly do so.

  - There are alternative means of doing same on a project basis.  Start
    your project.  Require that contributions to the project which are
    to be included in the main distribution be assigned to your
    third-party organization, and that it have the right of independent,
    non-free, software relicensing.  You'll probably want to think over
    this reuqest from the PoV of the independent software contributor:
    why should they be willing to contribute their work to your project
    for possible proprietary application, without compensation?  As one
    popular sigline puts it:  I write free software for free.  When I
    write non-free software, I expect to be paid for it.

  - Alternatively, consider a dula-license scheme.  The Mozilla project
    uses a GPL + MozPL license combination.  I'll assume you're familiar
    with the GPL's "the entire work must be GPL'd" requirement, the
    MozPL's principle twist is the individual source files must remain
    under the MozPL, but additional source files can be added under
    other licensing terms, including proprietary licenses.  So long as
    then *entire* project base is under _both_ licenses, additional
    outside GPL'd code can be mixed (the MozPL file-by-file allowance is
    overruled).  But the original (dual-licensed) work can be used with
    proprietary extensions (the MozPL applies).  Logically, dual
    licensing can be considered as a logical nonexclusive OR:  you must 
    abide by the requirements of license A, OR you must abide by the
    requirements of license B (and if you choose, you can abide by both

    TrollTech's QPL + GPL licensing is another well-known example, as is's <Sun something> + GPL, and Perl's Artistic + GPL.

    You may notice a trend of dual licensing with the GPL.

  - New licenses are generally discouraged.  They're frequently
    unnecessary (see above), considered gratuitous, break compatibility
    with existing licenses (see above), restrict your available
    codebase to a very small set, require interpretation by multiple
    parties (OSI, license kibbitzers such as myself, Linux distros,
    end-users, corporate adopters...), and for all but a very, very,
    very few answer only the needs of a single organization, which on
    closer examination, they don't even really meet either.  Please
    reconsider:  your proposal seems ill-advised.

>    This negotiation may allow proprietary, non-open source
> derivative works to be sold by the commercial entity.  In
> exchange, the third-party organisation receives royalties which
> it uses to hire professional QA, fix bugs, write documentation,
> and develop a conformance test suite.  The commercial entity has
> to pass the conformance test suite in order to maintain its
> rights to distribute the derivative work non-open source.

See above.  You're probably going to meet all these objectives with a
dual licensing approach. 

>    The derivative work must still maintain all other aspects of
> the GPL, including distributing source for the pre-derivative
> work the derivative is based upon, and including a copy of the
> new license.

...but not GPL compatibility.  See above.  Consider dual-licensing.

>    For non-commercial entities, such as researchers and
> individual developers, the license reverts to the standard GPL,
> with the one exception that any derivatives may only use the
> name of the original work upon condition that they pass the
> conformance test suite.  

Clause 6 of the GNU GPL v2 says that this isn't the GPL.  You lose.

> If they fail the conformance suite or
> are not tested with it, they must include a notice stating that
> the work is derived from the original but has failed the
> conformance suite.

Clause 6 of the GNU GPL v2 says that this isn't the GPL.  You lose.

I'd also suggest you spend several days of your time looking over
various licensing legal discussions ov the Sun Java license and why it
isn't FSF Free Software or OSI Open Source.  This will be *considerably*
cheaper than the 6-18 months of legal billable hours you'd need to
hammer out a license likely to meet even very grudging acceptance from a
small minority of the FS/OS world.  It may also forestall a considerable
rehashing on this list of issues the subscribers are intimately
aquainted with but you appear not to be.

>    Distributions of patches is allowed, 

See many discussions of qmail and/or pine "patch distribution" and why
this is considered harmful.  See above WRT your research time, billable
hours, and intimate famiarity.

> however, if the work compiled with the patches fails the conformance
> suite or is not tested with it, the notice of being derived from the
> original but failing conformance must be included.
>    The third-party entity charged with negotiating with
> commercial entities must be a non-profit organisation committed
> solely to carrying out the responsibilities of managing work
> assigned to it under the new license.

Sun Java, above.
> Will a license such as this be certifiable as Open Source?  

Possibly, though not clearly, see above.

More importantly:  will such a license serve the needs and/or goals of
your organization, or are there existing, functional, and more
acceptable alternatives available?

I *very* strongly suspect the latter.
> Thank you for your time,  sincerely,

Freely granted on condition of due consideration.



Karsten M. Self <>
    Ceterum censeo, Caldera delenda est.