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

Pamela Chestek pamela.chestek at opensource.org
Fri Mar 6 19:45:20 UTC 2020

Moving to license-discuss since the license has been approved.


Pamela Chestek
Chair, License Review Committee
Open Source Initiative

On 3/4/2020 11:00 AM, Ian Kelling wrote:
> VanL <van.lindberg at gmail.com> writes:
>> Hello Ian,
>> Thanks for chiming in. A couple responses:
>> On Thu, Feb 13, 2020 at 8:50 AM Ian Kelling <ian at iankelling.org> wrote:
>>> What is providing a service?
>> Providing a service is defined in terms of communicating the Work to
>> another person - the essential human-to-human communication. It is
>> encompassed in Section 4:
>> "Exercis[ing] any permission granted by this License, such that the Work,
>> or any part, aspect, or element of the Work, is distributed, communicated,
>> made available, or made perceptible to a non-Affiliate third party (a
>> “Recipient”), either via physical delivery or via a network connection to
>> the Recipient."
>> Speaking broadly as to Mailman, preferences and your specific messages
>> would be considered User Data. But your worry about a bug preventing the
>> use of Mailman is unfounded. The CAL doesn't specify the particular
>> mechanism of compliance, so "bug-free" export code is not required.
> Your argument seems to be that noncompliance is fine because the license
> doesn't specify a compliance mechanism. But copyright law does, and it
> doesn't make any sense to consider a license open source when
> noncompliance is the natural result of free software development with
> the best intentions.
> Its not just about requiring bugs be fixed. As far as I can tell,
> anytime you run a gratis service which stores user data (as defined by
> CAL), its reasonable to expect that some people will input data then
> request their user data (and CAL requires you give it to them), so to
> reasonably expect that to be in compliance, it requires there to exist
> software functionality to get that data, call it an export or
> whatever. Almost all free software I know of that is used for gratis
> services does not expose all user data it stores back to the user or
> have that functionality, and thus would expect to be in noncompliance if
> run under this license. I can list off 10 common ones easily, many are
> in debian and developed with the best intentions around user data. Its
> easy to say "software should do X", until you are the one writing it. It
> just doesn't make sense to call a license open source if normal free
> software can't comply because it lacks specific functionally.
> Here's more concrete examples. For Mailman, you've said that CAL would
> require users to be able to get their emails. Mailman stores email in a
> raw form called mbox on the server. But mailman only exposes it to users
> in html form which is derived from the raw form and missing some user
> data, and can't work correctly with another instance of Mailman. Users
> would need the mbox data. So if Mailman was under CAL, running it would
> lead to noncompliance. And Mailman is a an extremely simple example. A
> better one would be Mediawiki, or CiviCRM where admin users can define
> and change fields at runtime, making things quite complicated, and
> making the burden of tracking user data not just on the developer, but
> also users. It could easily take months or years of full time
> development to write functionality to export user data and track it. In
> the rationale document by the OSI, it says compliance can already be
> hard, so its fine that this is hard too. There has to be a limit
> somewhere, and this should clearly be beyond it. For compliance with
> existing licenses, you can follow a general principle of treating users
> like fellow developers and there's essentially no burden, but this is
> completely different.
> To argue against this using the OSD: #3 says "allows modification", and
> in the annotated version "For rapid evolution to happen, people need to
> be able to experiment", it implies at least allowing any modification
> that is typical in free software development, and implies allowing
> running that software, and of course, being in compliance while doing
> it. Well, the user data requirement does not allow that for software
> meant to run as gratis internet services that stores user data. It would
> be one thing if that was already a common practice in but its not at
> all.

More information about the License-review mailing list