[License-review] [License-discuss] For approval: The Cryptographic Autonomy License (Beta 2)

[VanL]

Hi Bradley,

I appreciate your sharing here, especially as I have used the AGPL as both
a comparison point and a foil for the CAL.

A few brief points in response.

On Wed, Aug 28, 2019 at 3:49 PM Bradley M. Kuhn <bkuhn at ebb.org> wrote:

> Affero GPL was a huge leap and a big change in copyleft policy.  The FSF
> authorized a third-party fork for experimentation when the idea was new in
> 2002 -- precisely because the FSF (as a license steward dedicated to
> software
> freedom) was cautious about expanding copyleft requirements in novel
> directions.  That GPL fork (i.e., AGPLv1) was explored in the wild for
> years
> before the FSF made it officially theirs (in 2007) and recommended it.


There is a big difference between the existence of a license and the
adoption of the license as one of a very few officially supported licenses
by the FSF. Simply put, the FSF is in a different position vis-a-vis
software freedom than anyone else in the community. You say it yourself:
the AGPL was an authorized fork, and so it presented a new "policy"
direction *from the FSF.* That does not apply to any other license or
license steward.

While I would be thrilled if the FSF officially supported the CAL, I am
under no illusions that such a thing - if it happened - would happen
quickly.



> Even once the license became officially GNU, the FSF *still* kept it a
> fork of the
> "main license" (i.e., GPL) because loud voices in the community were still
> saying: "This is just too radical to be a 'default' copyleft policy."  As I
> said in a post on the MongoDB thread last year: the rules shouldn't change
> overnight in any culture (be it FOSS or anything else); that creates chaos.
> FSF knows this and is therefore careful and deliberate when proposing new
> copyleft requirements.  The many new license stewards that have cropped up
> in
> the last year should follow their well-set example.
>

This again conflates the FSF with all other possible license stewards. But
I would address a subtler, but more meaningful point: The SSPL discussions
were launched simultaneously with the license being changed by MongoDB for
all customers and all releases going forward. As you say, "the rules
shouldn't change overnight," and that was a significant issue.

In contrast, the CAL had public and private feedback, was launched first on
-discuss, moved to -review, and we are now going through this entire
process a second time after having made significant changes to respond to
feedback. This entire process has been done in the open, ahead of time.
There is no chaos, and no one will be disadvantaged in any way by the
approval of the CAL. It will become a new option among the others. It could
be that it achieves success, or it could not. But no one is suddenly being
subjected to an overnight rule change.



> But new leaps in copyleft policy shouldn't happen quickly, nor (IMO) be
> driven

by companies.  In particular, going from "nascent license with radical new
> policies"

to "OSI-approved" in just a few months is a mistake no matter who wrote the
> license.
>

This is unfair. Why shouldn't a company be able to participate, especially
if the manner in which they have chosen to do so is explicitly trying to be
maximally respectful of the process?

More broadly, though, what you are advocating is bad policy for the OSI -
and irrespective of the CAL, I would strongly advise against it.

I am a supporter of the OSI. I think the OSI is important, and that it
serves an important function. But I can also see that some people are
already choosing to bypass the OSI for various reasons. Having the OSI
explicitly take a "wait and see, we won't decide until five years from now,
once the license is established" makes it certain that the OSI will not be
a participant in any significant licensing discussions. It also removes the
possibility of significant discussion and analysis of licenses (such as is
happening with the CAL). If the CAL was already widely established, there
would be a strong argument that it could not effectively be changed, due to
the installed license base.

Thanks,
Van
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190828/536fef25/attachment.html>