[License-review] Some notes for license submitters

[Kyle Mitchell]

On 2018-06-12 17:06, Bruce Perens wrote:
> These are not OSI rules, but they're some clues for license submitters
> about how I think the license review process should work.

One upshot of the L0-R license review process, on my end,
was that Bruce throws significant weight.  There are many
capable, independent thinkers on this list.  But there's
little collective stomach for opposing the strongly worded
opinions of old hands, or even for probing the reasons
behind those views.  The published guide to the
license-review process, which does claim to set out OSI
rules, won't tell you that.

My experience reinforced the impression that despite the
excellent technical feedback that can be and will be had on
license-review, the operative parts of the process turn more
on personal prerogative and esteem than stewardship in a
technical spirit.  I fully expect that view to be written
off as sour grapes, though others have expressed it here,
and not just when proposing licenses.

If I could, I'd find a way around that impasse.  The old
hands have a great deal to teach.  But that wisdom can't
really be learned by receipt and recitation.  When old hands
stop answering mailing lists---more than a few already
have---we'll lose a great part of it.  A hundred hours in
the mailing list archive won't make it clear.

> There are already too many Open Source licenses. If we never accepted
> another, that would not be a particularly bad thing. OSI can't prevent
> anyone from using such licenses, but some of us will make it clear if we
> don't believe your license is Open Source.

Do not be shocked, during your license-review process, to
see arguments to the effect that the process you've prepared
for shouldn't exist to begin with.  And from several list
participants.  Among whom you may be asked to develop
consensus.

> A license is a sort of program designed to be executed by the courts.

A fun metaphor!  A favorite of mine, too.

Unfortunately, the spec for American courts leaves much
behavior undefined.

> If you have not made use of an attorney in drafting your license, you are very
> unlikely to understand how the courts would actually execute your license.
> The result would generally be harmful to Open Source developers who depend
> on your license to work as they expect. I made up a name for these licenses
> some years ago: *Crayon Licenses,* from a Monty Python sketch in which a
> man has a cat license, with the word "dog" crossed out and "cat" written
> in, in crayon.

I hadn't connected the phrase to the sketch!  Definitely one
to borrow.  Thanks.

> Please don't submit crayon licenses, reviewers will not see
> them as a good deal for the Open Source developer community, and are likely
> to abandon the review process as soon as they understand that they're
> crayon.

Feel free to discuss crayon licenses with lawyers privately.
License drafters don't tend to share the view that the last
good open source license has been written.  If you've
stumbled on something interesting---in functionality or
implementation---it may be worth refining, professionally.
And of course maybe it won't, and that's a judgment all the
professional will get to make.  Either way, be reasonable
about how you propose your ideas and to whom, and manage
your expectations.  We stay busy.

> Many of the presently accepted and newly submitted licenses are duplicative
> of other accepted licenses in their effect, and exist solely because a
> particular lawyer at a particular establishment was happier with their own
> language. Our own attorneys may not concur that they are better. In
> general, licenses that are duplicative of other licenses in their effect
> should not be accepted any longer, unless it's to meet new developments in
> case law or solve an obvious legal deficit. The combinatorial problem of
> Open Source licenses has a cost for everyone.

I would _strongly_ recommend those involved in
license-review stay open to old combinations of license
features in new, plainer language.  More accessible drafting
yields substantial lawyer-, cost-, and drama-reducing
benefits.  Plain English legal drafting is making inspiring
headway, as a craft.  Open source licensing shouldn't cut
itself out of the benefits.

There are also gains to be had from "branding" and
historical affinities.  For example, OSI approved
BSD+Patent.  I don't know that an _exact_ analog to the
particular combination of permissive license and patent
language chosen there existed before.  But the optics of,
well, BSD plus patent language, do have special value.

> You are encouraged to withdraw or deprecate your own approved licenses.
> There is no shame attached to this and you will be thanked, the field has
> evolved and we've all learned since those licenses were submitted.

I think I know the answer, but for others referring later:

Would you encourage new licenses duplicative of withdrawn
and deprecated licenses?

> Many of the licenses submitted cater to the needs of the submitting
> organization at the *expense *of the broader Open Source community. If your
> license doesn't consider the broader developer community and its needs,
> it's difficult to see why OSI should approve it. Some recently-submitted
> licenses propose to create precedents which would in general be harmful for
> the community.
>
> A whole category of licenses has been submitted to push the boundaries of
> Open Source beyond what was intended in the writing of the Open Source
> Definition. These are not generally well-received by the reviewers. Many of
> the proposed business methods result in something less than Open Source,
> and there is little reason to support them.

I hold my lines here.

On community interest:

Conclusory statements of community interest, superseding the
Definition and any drive to refine it transparently, belie
OSI's stated approach to license approval, which would stand
it on steadier ground.  As long as policy assessments trump
the Definition, this process isn't primarily technical, but
political.  The community OSI represents may not include
your community.  The concerns of developers that motivate
your proposal may not resonate.

On OSD:

Community compacts like the Definition matter insofar as the
community can scrutinize them, understand them, and rely on
common understanding.  Honoring that understanding, not
revelation of original drafting intent, creates legitimacy.

When my contracts turn out vague, ambiguous, or incomplete,
process tries to suss out the common understanding of the
parties who agreed to work under them.  My drafting
experience doesn't trump anything, though it often helps
decide how best to amend.  Where OSD is vague, ambiguous, or
incomplete, likewise, open source needs debate, not decree.

I've praised the Definition in high tones.  It's reached the
true benchmark of a great operative document:  It's done
decades of service, and still worth revising.

> Don't imply legal threats to the OSI or reviewers during the review
> process. It never works and doesn't make you friends.

Was my mention of tax-exemption received as a threat?  It
wasn't intended that way.  I don't want to see OSI involved
in any issue of the kind, a hot topic in the practice
community at present.

When a small part of our conversation triggered an
issue-spotting reflex, I mentioned it.  I built that reflex
advising clients, but OSI isn't my client, so I also had to
made clear the org would need to keep its own counsel.
There _was_ a tinge of self-interest:  I didn't want to
appear, on a public mailing list, as a lawyer leading a
non-profit into touching a rail non-lawyers may not
recognize as hot.

At the same time, in private correspondence on L0-R, I
received messages asking how I couldn't be brought up on
legal-ethics charges for proposing L0-R.  That wasn't
pleasant, but I didn't read too much into it.  I don't now.

In the end, my work is words, and I want to take full
responsibility for my part in any painful miscommunication.
I sincerely apologize if I caused anxiety, especially for
those with unpleasant prior experience of legal disputes.

-- 
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933