[License-review] Some notes for license submitters

Wed Jun 13 05:04:46 UTC 2018

I came back to the license-review committee after a 10-year hiatus
specifically to address *your *license. I think after you included me in an
email. Thus OSI can not have been expected to have warned you about my
weight :-) I don't think it would have been approved without me there.

We have had previous quite obnoxious and unambiguous proposers of legal
action against OSI. Perhaps that has primed people for any trigger, I
haven't been around to know.

I don't remember the specifics of the ethics issue in question, but I would
not suggest that simple proposition of a license to this list would trigger
any issue. I am concerned in general about the impact of this group's
choices on the law-naive Open Source developer. Someone like Bob Jacobsen
(v. Katzer) who I think initially used the original Artistic License and
saw the lower court say it was a dedication to the public domain. Does this
group create risk for that developer that the developer won't understand?
When someone admitted to the Bar promotes his own license to a developer
who is not his client, what is the lawyer's responsibility in law, and in
ethics?

    Thanks

    Bruce

On Tue, Jun 12, 2018 at 8:17 PM, Kyle Mitchell <kyle at kemitchell.com> wrote:

> 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
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-
> review_lists.opensource.org
>

-- 
Bruce Perens K6BP - CEO, Legal Engineering
Standards committee chair, license review committee member, co-founder,
Open Source Initiative
President, Open Research Institute; Board Member, Fashion Freedom
Initiative.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20180612/beeb213e/attachment-0001.html>