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

[Smith, McCoy]

>>From: License-review [mailto:license-review-bounces at lists.opensource.org] On Behalf Of Luis Villa
>>Sent: Friday, May 10, 2019 11:24 PM
>>To: License submissions for OSI review <license-review at lists.opensource.org>
>>Subject: Re: [License-review] For Approval: The Cryptographic Autonomy License

>>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.

I’m with Luis on this.  I laid out a test at CopyleftConf on how I personally think the decision process should go:


1.      Licenses should be evaluated solely on their fidelity to the standards of freedom/openness, and the quality of their drafting in meeting those standards

a.      Experimentation is not necessarily a bad thing

b.      Even failed experimentation

2.      The business model, much like their philosophy, of the drafter should be immaterial to evaluating the merit of their license

Several in that audience disagreed with proposition 2; some disagreed with proposition 1, in various ways, including under the old issue of license proliferation (an issue which I’ve become less concerned about in the 15+ years since I was on the first license proliferation committee).  On CAL, some seem to be objecting on the basis of business model, some seem to be objecting on the basis of not meeting the OSD, some seem to be objecting based on not meeting Freedom Zero.

Complexity that results in ambiguity is, in my opinion, a valid reason to decline approval of a license (as does simplicity that results in ambiguity).  Complexity qua complexity is, again in my opinion, not.

I do think it ought to be made clear, though, whether Freedom Zero is part of the OSD. I think we’ve had some debate in the past as to whether it was (I think it is inherently so, but I don’t see that the OSD makes that explicitly clear).  If it is not, I don’t see how that’s a valid reason to reject any license.

I also agree with Luis to require a license to come in first and say “I’ve already got a huge community using the license” before making a compelling case for approval is a syllogism.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190511/9e957d30/attachment.html>