Lothar sent me an interesting paper yesterday: Nobody Owns Data https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3123957
On Fri, Aug 9, 2019 at 4:22 PM Diane Peters <di...@creativecommons.org> wrote: > Perhaps useful as a point of reference: CC 4.0 ND > <https://wiki.creativecommons.org/wiki/version_4#Private_adaptations_expressly_authorized_under_4.0_ND_licenses> > licenses allow private modifications. This feature is included to support > text and data mining activities and similar. As long as what is ultimately > shared publicly isn't a derivative of the original, rare in the TDM world > particularly, the ND restriction is not violated. > > Diane > > > > Diane > > Diane M. Peters > General Counsel, Creative Commons > > > On Fri, Aug 9, 2019 at 1:15 PM Smith, McCoy <mccoy.sm...@intel.com> wrote: > >> *>>From:* License-discuss [mailto: >> license-discuss-boun...@lists.opensource.org] *On Behalf Of *Brendan >> Hickey >> *>>Sent:* Thursday, August 8, 2019 5:20 PM >> *>>To:* license-discuss@lists.opensource.org >> *>>Subject:* [License-discuss] Private modification >> >> >> >> >>What are some good policy arguments in favor of restrictions on >> private modification? My own impression is that these licenses are so >> onerous as to discourage any serious use. Are there any significant >> projects using the RPL or similar licenses? >> >> >> >> I’m a lawyer, not a policy person or philosopher (at least not >> professionally), but I can think of at least 3: >> >> >> >> 1. Onerousness (as you have identified). If you have to make >> public or disclose all your private modifications, when and how often one >> must publish the modifications, and what modification quantum triggers the >> obligation, introduces compliance burdens and complications for the user. >> >> 2. Privacy. There may be many changes which as a user you may not >> wish to be made public; forcing you to do so when you have not otherwise >> made those modifications visible to the public in general or others >> specifically forces you to give up some of that privacy. >> >> 3. Proliferation of bad, incomplete or nonuseful code. During >> code development, there is a reasonable amount of modified code which is >> undeveloped, untested, bad, or incomplete (pre-beta). If this code is >> required to be made public, it potentially increases the ratio of bad to >> good code accessible to the public. >> >> >> >> There are probably other reasons others on the list can enumerate; those >> just come off the top of my head. >> >> >> >> IMHO, AGPL and other licenses like it draw a boundary which reduce these >> factors (and don’t touch true private modification), by only triggering >> obligations once the user has given access to their modifications to >> others. Some of the more recent submissions to the license approval list >> don’t draw that boundary in such a way, and do indeed reach toward true >> private modifications (and push against the concept of Freedom Zero). >> _______________________________________________ >> 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 > -- Bruce Perens - Partner, OSS.Capital.
_______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
