[License-review] For approval: The Cryptographic Autonomy License (Beta 4)

[Nigel T]

On Fri, Dec 13, 2019 at 2:53 AM Henrik Ingo <henrik.ingo at avoinelama.fi>
wrote:

> On Thu, Dec 12, 2019 at 11:30 PM Nigel T <nigel.2048 at gmail.com> wrote:
>
>> On Thu, Dec 12, 2019 at 3:17 PM VanL <van.lindberg at gmail.com> wrote:
>>
>>> The hypothetical then expanded again to user accounts, memberships,
>>> badges, user content, etc - the whole WordPress ecosystem. I can't say that
>>> the whole WordPress ecosystem would be able to easily comply. But you
>>> yourself identify that the information is stored in the database or the
>>> filesystem, and it is accessible, so compliance is possible. I would also
>>> note plugins like WP-all-export.
>>>
>>
>> These specifics were provided to refute Henrik's assertion that WordPress
>> has been 4.2 compliant for years.  These are not "expanded hypotheticals"
>> but counter-examples.
>>
>
> Just to be clear, I of course agree that there can exist software that
> would not allow easy export of user data in a CAL compliant manner.
>

If software CAN exist that is not CAL compliant and licensed under CAL then
it's a compliance time bomb for every downstream user.  Why should this be
approved?


> But I did feel compelled to point out that the initial Wordpress examples
> given by you and Bruce are in fact compliant! Only on your third attempt
> did you manage to present a sufficiently complicated scenario that it
> plausibly might not be compliant out of the box. Yet even then Van pointed
> out that there could exist and a user could easily install a plugin
> specifically designed to export all data of a given user, regardless of
> what arbitrary set of other plugins you had activated.
>

Could exist and does exist are not the same.  There is nothing in CAL that
requires the original software to provide even rudimentary export
capabilities.

Van insists that doing SQL queries is sufficient (even good) to meet CAL
requirements and you believe that simply having the data appear as HTML
somewhere fulfills the requirement.  Of course, nothing is written in the
license terms that indicates these are acceptable so we'd have to find out
in a court of law if that's actually true.  This would be in conflict with
Bruce's opinion that "The open source definition means that you shouldn't
need a lawyer just to be a user".

But lets say that it is...then 4.2 is relatively easy to be compliant with
for professional service providers (folks actually likely to attempt user
data lock in) so has very little value in terms of data portability and 4.2
can be safely removed because its a huge burden for non-technical OSS users.

But I think the intent is for 4.2 to be hard to be compliant with and I'll
get to that below.


> So I think this discussion - which raised a very valid question - has
> shown that in practice the current language in CAL will work well and while
> problematic cases can be constructed, they seem to be the exception and
> users should simply avoid such software, should they actually exist in the
> future.
>

I think we should simply avoid approving this license because the
problematic cases are very common for SaaS software.  You assert that these
cases are "an exception".  What is your evidence that they are exceptions
and not the norm?

There is are a vast amount of OSS software that would not be CAL compliant
that the original authors could relicense under CAL if they wanted to.
Nothing in CAL precludes them from doing so and they would be non-compliant
out of the box for downstream users.

All the vendors of SaaS software that have long wanted an OSI approved
license for their product marketing where no one could actually legally use
their software without a lot of refactoring effort would be quite happy.
After all, they don't care about non-compliance...they are the original
authors and you can use their "open source product released under an OSI
approved open source license" on their own servers all day without any
issues.

That's interesting isn't it?  I can release CAL licensed software as "open
source" that no one but me can use without a lot of work because of
non-compliance with 4.2.  Someone like Amazon or Microsoft would have to
decide between not competing with my cloud product, buying a commercial
license from me or spending engineering resources to become 4.2 compliant
and hope they got it right every time I released a new version.  Not just
my product but probably all of their cloud infrastructure that used my
product as well.  Oh and naturally all that infrastructure code has to get
released too.  If normal OSS users get locked out...well that's a shame,
but it's just the cost of doing business.  They weren't likely to be using
my enterprise cloud product anyway.

Gosh, I wonder what companies might want an OSI approved license like that?

A little asymmetry in an OSS license can be okay but you need to carefully
look at how that asymmetry can be abused before approval.

henrik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20191213/9cb74a38/attachment.html>