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 <[email protected]> writes: > >> Hello Ian, >> >> Thanks for chiming in. A couple responses: >> >> On Thu, Feb 13, 2020 at 8:50 AM Ian Kelling <[email protected]> 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 [email protected] http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
