[License-review] License drafting quality and process [was Re: Comment on MOSL and similar licenses]

[Patrice-Emmanuel Schmitz]

>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
solution!
Anyway there is at least one problem: the poor quality of most new
submitted licenses.
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.
P-E.


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
> will
> > be the evidence that the licence is open source (facilitating the
> adoption
> > 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
> the
> > 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
> incompetence.
>
> (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
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review
>



-- 
Patrice-Emmanuel Schmitz
pe.schmitz at googlemail.com
tel. + 32 478 50 40 65
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20130613/57f1d22f/attachment.html>