[License-review] License drafting quality and process [was Re: Comment on MOSL and similar licenses]
pe.schmitz at googlemail.com
Thu Jun 13 07:36:35 UTC 2013
>What problem are you trying to solve here? It doesn't seem like a
>problem we actually have.
If really there is no problem, Josh, then forget my suggestion of "simple
certificate". I don't want to invent a false problem to propose a wrong
Anyway there is at least one problem: the poor quality of most new
On this point, the suggestion of a more formal "license submission as a
check list" including the points I mentioned in my 6 June mail could
probably improve the situation.
In the current situation of license proliferation, an additional point
could be added to the list:
- detail how far software code covered by your proposed licence could
benefit to other FOSS communities and be merged/reused in projects covered
by other OSI approved licenses.
2013/6/12 Josh Berkus <josh at postgresql.org>
> > This was not at all my idea, if you read me correctly: I suggested the
> > rapid deliverance of an "OSD compliance certificate" (even if the license
> > does not improve / revolutionate the FLOSS ecosystem). The certificate
> > be the evidence that the licence is open source (facilitating the
> > by the first followers).
> > OSI may then take more time to classify eventually the license as
> > "OSI-approved" once a representative level of projects will use it (as
> > case may be).
> What problem are you trying to solve here? It doesn't seem like a
> problem we actually have. I'll also point out that popularity is no
> guarantee of validity. For example, the "Beerware" license is extremely
> popular, but is completely unenforceable.
> First, let me agree with Rick and point out that the only licenses we've
> approved in the last year were new versions of old approved licenses.
> Every other proposed license we've seen has been rejected as either (a)
> not OSD-compliant, or (b) very poorly conceived and written, or (c)
> wholly duplicative of an existing license. As far as I'm concerned,
> that part of the process is working fine.
> What's not working fine is how people *feel* about the rejection
> process. What happens currently in the worst case is:
> (1) Crayon license submitter (CLS) emails their "clever" idea for a new
> license to this list.
> (2) We point out some of the shortcomings in the license and reject it.
> (3) CLS becomes indignant and accuses us of personal enmity and/or
> (4) CLS attempts to lobby and/or harass us into submission. This
> doesn't work.
> (5) We are contemptuous of CLS. CLS hates us.
> (6) CLS decides to use their "license" anyway.
> My thinking was that an explicit process where the submitter *had* to
> consult an attorney before submitting ... and where the only reply we'd
> give to one who didn't was to point to that requirement ... would cause
> the CLS to talk to an attorney first who would at least point out that
> the license they're sending is badly written and unenforceable. Or,
> more likely, get hung up on finding an attorney and never write their
> crayon license in the first place.
> However, I think enough people on here have pointed out that CLS's are
> ignoring any kind of reasonable process anyway, so adding process
> requirements won't work; they'll simply ignore them.
> In a way, this is actually the process working as designed. As the
> number of possible new licenses which are OSD-compliant, original and
> sensible approaches the vanishing point, increasingly the only
> submissions we're going to see are going to be from the ill-informed and
> impulsive. So maybe there's no fixable problem here, at all.
> --Josh Berkus
> License-review mailing list
> License-review at opensource.org
pe.schmitz at googlemail.com
tel. + 32 478 50 40 65
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the License-review