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

Henrik Ingo henrik.ingo at avoinelama.fi
Fri Mar 20 08:14:50 UTC 2020


On Fri, Mar 20, 2020 at 1:06 AM Florian Weimer <fw at deneb.enyo.de> wrote:

> * Henrik Ingo:
>
> > On Thu, Mar 19, 2020 at 10:22 PM Florian Weimer <fw at deneb.enyo.de>
> wrote:
> >
> >> 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.
> >
> > Note that the CAL specifically does not share this problem. It simply
> > requires you to provide a copy of the source and user data, but doesn't
> > mandate a specific user interface or other mechanism for doing so.
>
> The CAL has the *exact same problem* if it is applied to software that
> lacks a built-in mechanism for identifying the relevant sources and
> the user data (let alone providing a built-in downloading mechanism).
>

We discussed this last year when reviewing the CAL. It is true that this
can be an issue for some software. However arguably this is the exact
opposite problem to what you point out in the AGPL.

In case the licensed software doesn't have relevant functionality for
delivering the corresponding source, then...

In the AGPL the recipient is either excused from providing source or
alternatively it is unclear how exactly the recipient should fulfill this
obligation.

In the CAL it is clear that the recipient still has this obligation and can
freely choose how best to fullfil this obligation. You are however correct
that for some software at least providing the user data may require some
work from the licensee, if the software doesn't include a feature to do
this automatically. But importantly it is NOT unclear *what* is required.


> My problem with these licenses is *not* that the requirements are
> particularly onerous (maybe they are in practice, but so is the
> notification requirement in the HPND licenses, it seems), but that the
> license is so vague in what is actually required.  A typical example
> is a library licensed under the AGPL that does not handle anything
> network-related.  What are the source code distribution requirements
> for a program that happens to have a network-related component?  (This
> is where the “GPL for open core” part comes from—any serious
> commercial user will pay for different, clearer license terms.)
>
>
In my experience selling GPL and AGPL licensed software, this is rarely the
motivation to pay for a commercial license. Maybe less than 1% of customers
would have blanket policies to not use GPL.

Also note that for many cases where the share of such customers was the
main income for some vendor - say early Qt or early MySQL - the reason
customers would pay for a non-GPL license was not that it was unclear what
the GPL required but rather because it was very clear what the GPL required.


> If these programs had a built-in compliance mechanism, it would at
> least become clear what the author intended.
>
> But even if a program licensed under the CAL had all those built-in
> facilities, using the software would still not be automatically
> compliant, because any user must make arrangements for complying with
> the license *after* any use of the software has ended (where any
> built-in access mechanisms have stopped working, of course).
>
> Not sure why people keep bringing up the CAL.  I did not mention it.
>

The very first words in your very first email to this thread were "I was a
bit surprised to learn that the CAL was accepted,"

henrik


-- 
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/20200320/38d935de/attachment.html>


More information about the License-discuss mailing list