[License-discuss] Private modification

[Bruce Perens]

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 <diane at 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.smith at intel.com> wrote:
>
>> *>>From:* License-discuss [mailto:
>> license-discuss-bounces at lists.opensource.org] *On Behalf Of *Brendan
>> Hickey
>> *>>Sent:* Thursday, August 8, 2019 5:20 PM
>> *>>To:* license-discuss at 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 at lists.opensource.org
>>
>> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>


-- 
Bruce Perens - Partner, OSS.Capital.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190809/c52fc0fa/attachment.html>