[License-discuss] Private modification

[Diane Peters]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190809/2148497f/attachment.html>