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.ches...@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.lindb...@gmail.com> writes: >> >>> Hello Ian, >>> >>> Thanks for chiming in. A couple responses: >>> >>>> On Thu, Feb 13, 2020 at 8:50 AM Ian Kelling <i...@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@lists.opensource.org > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org _______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
