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

[Henrik Ingo]

Larry, if it makes you feel any better, I always think of you during each
of these email threads!

henrik

On Thu, Mar 19, 2020 at 11:29 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
> <http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.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
>


-- 
henrik.ingo at avoinelama.fi
+358-40-5697354        skype: henrik.ingo            irc: hingo
www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20200319/3756928e/attachment.html>