[License-review] AGPL timeline & why cautious processes with real-world testing are better (was Re: For approval: The Cryptographic Autonomy License (Beta 4))

VanL van.lindberg at gmail.com
Fri Jan 3 18:22:06 UTC 2020


Hi Bradley,

I appreciate your response, and I recognize that I didn't get all the
details quite right. I see your point. But I think you missed mine:

On Fri, Jan 3, 2020 at 11:48 AM Bradley M. Kuhn <bkuhn at ebb.org> wrote:

> VanL wrote today:
> >    So regardless of whether the AGPL was "accepted" or "endorsed" by the
> >    FSF, it benefitted from Bradley's official relationship with the FSF.
>
> ... and I'm sure your license will benefit from your official relationship
> with its drafting authority too.
>

The issue is not the relationship with the *drafting* authority. The issue
is the relationship with the *certifying* authority. The FSF
accepted/authorized/recognized AGPLv1 essentially immediately. The AGPL
benefited from being recognized as a Free Software license, allowing it to
gain community uptake. Thus the AGPL avoided the chicken-and-egg situation
that any other license would have. Moreover, there have been at least a
couple people stating on this list that they are interested in using the
CAL as soon as it is approved. Is that not a sign of interest by non-Holo
licensors?

The delay vis-a-vis OSI approval is not the issue. If the FSF were to
immediately recognize the CAL as a Free Software license, but in return I
had to wait five years for OSI approval, I would take that deal in a
second. This is why the AGPL process is not equivalent; I don't think that
path is available to anyone else.

The argument that people should not submit licenses until years after they
are used undermines the OSI's role as a license authority. This policy
explicitly means that people should "ignore the OSI until some undefined
point in the future."

You compare the CAL to the SSPL. Let's look at that comparison. The CAL
wasn't sprung on anyone as a surprise. It has gone through a very public
discussion phase, with significant changes. It wasn't designed to be a
license that forces commercial licensing. It may not have been perfect, but
the effort behind the CAL has been to do everything the "right" way.

In contrast, let's look at the SSPL. MongoDB, Inc is successfully ignoring
the OSI. The SSPL now has a significant installed base. Some projects are
getting released by non-MongoDB licensors under the SSPL. Those releases
may be "unwilling" and due to the terms of the license - but that is true
of any copyleft license. Is this the vision of success that the OSI wants
to encourage?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20200103/afc9a913/attachment-0001.html>


More information about the License-review mailing list