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

[Nigel T]

Who knows if this will be seen but I brought all this up and the board said no big deal.

Sent from my iPhone

> On Mar 6, 2020, at 2:46 PM, Pamela Chestek <pamela.chestek at opensource.org> wrote:
> 
> Moving to license-discuss since the license has been approved.
> 
> Pam
> 
> 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.
>> 
>> 
> 
> 
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org