[License-discuss] Extending copyleft and out-of-the-box compliance

[McCoy Smith]

Or RPL 1.0 et seq 

> On Mar 19, 2020, at 2:28 PM, Lawrence Rosen <lrosen at rosenlaw.com> wrote:
> 
> I'm tired of everyone forgetting OSL 3.0, as if AGPL is the only license
> worth considering. Licensing bigots! /Larry
> 
> 
> -----Original Message-----
> From: License-discuss <license-discuss-bounces at lists.opensource.org> On
> Behalf Of Florian Weimer
> Sent: Thursday, March 19, 2020 1:19 PM
> To: license-discuss at lists.opensource.org
> Subject: [License-discuss] Extending copyleft and out-of-the-box compliance
> 
> I was a bit surprised to learn that the CAL was accepted, given that its
> copyleft extensions have the same major problem as the AGPL.
> 
> With that I do not mean the predominant use of the AGPL as a GPL variant for
> open-core business models, but that the AGPL requires to provide source code
> access over the network even if the software itself does not provide a means
> for accessing it.
> 
> Curiously, the GPL has already dealt with a similar issue.  Version 1 says
> this:
> 
>    c) If the modified program normally reads commands interactively when
>    run, you must cause it, when started running for such interactive use
>    in the simplest and most usual way, to print or display an
>    announcement including an appropriate copyright notice and a notice
>    that there is no warranty (or else, saying that you provide a
>    warranty) and that users may redistribute the program under these
>    conditions, and telling the user how to view a copy of this General
>    Public License.
> 
> This was changed in version 2:
> 
>    c) If the modified program normally reads commands interactively
>    when run, you must cause it, when started running for such
>    interactive use in the most ordinary way, to print or display an
>    announcement including an appropriate copyright notice and a
>    notice that there is no warranty (or else, saying that you provide
>    a warranty) and that users may redistribute the program under
>    these conditions, and telling the user how to view a copy of this
>    License.  (Exception: if the Program itself is interactive but
>    does not normally print such an announcement, your work based on
>    the Program is not required to print an announcement.)
> 
> Note the new exception.  I think this makes a lot of sense because it
> ensures that anyone can make unrelated modifications to the program and
> distribute them, without adding the startup notification first.
> Some GPL programs have such notifications (Emacs, GDB, Guile), but a lot do
> not or only print a subset of the notifications (ed, jshell, CLISP, GCL,
> Maxima etc.).
> 
> Unfortunately, this exception was not carried over into the AGPL.  As a
> result, use of most programs licensed under the AGPL become non-compliant
> once local modifications are made because the source code access requirement
> is not met.  In most cases, I don't think this is because the party who made
> the modification wants to keep the modifications secret, but rather due to
> oversight or the cumbersome nature of manual source code publishing (the
> usual reasons for copyleft non-compliance).  Hence the need for out-of-the
> box compliance.
> 
> I think the change from GPL version 1 to GPL version 2 shows one way to
> ensure that: Copyleft extensions should only be in force if the work
> contains built-in mechanisms that enable automatic compliance with such
> extensions.  This means that activating these extensions needs a conscious
> decision by the authors, and also a clarification of the scope of the
> extension and its concrete impact on use.
> 
> What do you think?  Could that be adopted as an informal guidance for future
> license reviews?
> 
> One problem is that a feature that cannot be legally removed again once it
> has been added looks a lot like DRM.  But I think it would still be
> preferable to have feature-conditional license elements rather than the same
> elements unconditionally, potentially without a compliance mechanism built
> into the work.
> 
> _______________________________________________
> The opinions expressed in this email are those of the sender and not
> necessarily those of the Open Source Initiative. Official statements by the
> Open Source Initiative will be sent from an opensource.org email address.
> 
> License-discuss mailing list
> License-discuss at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensourc
> e.org
> 
> 
> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address.
> 
> License-discuss mailing list
> License-discuss at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org