[License-discuss] Private modification

Diane Peters diane at creativecommons.org
Fri Aug 9 23:21:41 UTC 2019

Perhaps useful as a point of reference: CC 4.0 ND
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 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>

More information about the License-discuss mailing list