[License-review] For Approval: The Cryptographic Autonomy License

[Luis Villa]

I'm a big advocate of simplified drafting, but... I've got to register a
strong objection to the complaint that CAL is too complex.

On Fri, May 10, 2019 at 11:47 AM Bruce Perens via License-review <
license-review at lists.opensource.org> wrote:

>
>
> On Fri, May 10, 2019 at 7:59 AM VanL <van.lindberg at gmail.com> wrote:
>
>> I assume that most of the content of this message is deliberate
>> overstatement in the service of either humor or sarcasm.
>>
>
> Not at all. It illustrated from the non-programmer, non-lawyer's
> perspective just how impossible compliance is. *They can't do it on their
> own. *The way I wrote that is exactly what they would face.
>
>
>> With reference to the substantive assertion that the GPL is
>> uncomplicated, I will just note that there are still corner cases in terms
>> of GPL compliance that are subject to debate.
>>
>
> This may be, but we do have a really large non-lawyer community who
> identify with its goals and are reasonably confident in their understanding
> of it, and who have committed a really large body of property to be managed
> under its terms.
>

"who have committed a really large body of property to be managed under its
terms." - I'm going to ignore this, since if this is the test, OSI can...
only approve long-existing licenses (or trivial permissives). (If that's
the board's intent I'd love to hear it; we can all unsubscribe from this
list and call it a day!)

Objectively, CAL and (A)GPLv3 are fairly similar in reading complexity when
scored using objective reading tests, and all three are more complex than
the median open source license. To elaborate: Libreoffice is making it a
giant PITA to create reasonably labeled graphs, so you'll have to trust me
that (A)GPL v3 and CAL are in the same or adjacent histogram buckets when
you score CAL with style(1) on Kincaid and Flesch scores, add it to this
data <https://gondwanaland.com/mlog/2013/09/22/license-readability/> on
existing licenses, and partition the data following Rice's Rule (which
suggests using either twelve or thirteen buckets). This is not to say that
they are simple licenses - none are in the central buckets of the histogram
- and CAL is definitely slightly more complex than (A)GPLv3 by these
measures.But against the background of existing open source licenses,
they're basically similar, and many approved licenses are more complex than
CAL. (GPL v2 is slightly simpler than either CAL or (A)GPLv3, but still
more complex than the median OSI-approved license by Kincaid and nearly as
complex as the median by Flesch.)

Subjectively, several of us on this list have built lucrative, or at least
very steady, careers out of explaining (A)GPL to other very smart people,
and there is a whole cottage industry of things like tldrlegal.com, twenty-five
chapter interpretive guides <https://copyleft.org/guide/>, and 100+ page
documents just to explain what linking means. All these things suggest that
the *GPL* family are extremely complicated, a complexity made manageable
only by two decades of Talmudic meditation.

None of this complexity inherently makes (A)GPL (v2 or v3) a *bad* license.
I have my quibbles with some of their drafting, but fundamentally they are
complex licenses because they are trying to solve complex problems.

The same with CAL. There is no good, objective or subjective,
non-goalpost-moving, non-"no true scotsman" line you can draw between CAL
and the *GPL* family on the complexity dimension. The board could reject
CAL on these grounds and say *GPL* is grandfathered in, but if that's the
board's position it'd be good to get that written down so that future
copyleft license drafters can stop wasting their time.

Luis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190510/4ab2c9ed/attachment-0001.html>