[License-discuss] For Discussion: Cryptographic Autonomy License (CAL) Beta 2

Bruce Perens bruce at perens.com
Tue Aug 13 21:27:18 UTC 2019


On Tue, Aug 13, 2019 at 12:50 PM VanL <van.lindberg at gmail.com> wrote:

> This is a completely fair point, and I apologize for the tone.
>

Well spoken, and accepted of course!


> The CAL does require that a licensee make available the user's data to the
> user, but it does not impose restrictions on how the data is used, nor do
> any obligations persist after any transfer of the data. Thus, the CAL has a
> condition on the license, but not an encumbrance on the data.
>

Please excuse me for repeating previous discussion, it's obviously
necessary to discuss this new version.

You are attempting to extend the reciprocal licensing paradigm, to require
that the licensee distribute the data to a specific party (the user). It's
my contention that neither Free Software nor Open Source contain or allow
this specific requirement.

But looking at what was written, use "in a business" or "for genetic
> research" clearly refer to overriding purposes of the use, and not to any
> particular tactics.
>

Those are examples. They don't restrict "field of endeavor" to exclude all
of the very many decisions necessary to carry out your business. It's
really obvious that SaaS providers have lock-in strategies as a major part
of their business, otherwise it would not be a an explicit goal of the CAL,
and apparently this version's sole remaining significant difference from
accepted Open Source licenses, to *defeat* lock-in terms. The businesses
that use such terms are fields of endeavor, and would be different fields
of endeavor if they operated differently.

I sympathize with the goal of CAL, while still not believing that the
implementation of that goal is well-placed as a software license term. It
belongs in law regarding online business. This seems to me to be the same
as all of the discussions of license additions to achieve an ethical
purpose - which we've just iterated again. They attempt to extend the Open
Source paradigm to address some other issue.


> any restriction can be cast as a violation of OSD #6 because it could
> potentially interfere with a hypothetical licensee's permission to do the
> opposite.
>

I have to differ with Richard's theorizing, which I think Pam has also
commented that she shares. We have the restrictions that achieve the
purpose of Open Source, as stated by the definition, and we have *all other
restrictions.* The OSD specifically says that distribution of source code
must be allowed. The OSD implicitly provides you with a way to separate
restrictions into two categories, one that achieves the purpose of Open
Source as defined, and one that does not. Having made that separation,
there is no *reducto ad absurdum. *There are simply permitted restrictions,
and those not permitted.

The CAL does not prohibit (or even mention) any purposes for which the
> software can be used; it is completely agnostic in that fashion.
>

It just tells me I can't make the user data trade secret, or simply
sequester it and thwart the user's desire to see it returned. And my
business may succeed or fail over that one thing. I'm not saying that it's
nice.

So I would challenge you: What is an articulable, non-gerrymandered rule
> that says "you may use this for any field of endeavor" that allows current
> licenses, but disallows the CAL?
>

I would simply say "You may use the software for any purpose" is a
sufficient filter. I would say that OSD #6 states this same rule, in
different language.

    Thanks

    Bruce


-- 
Bruce Perens - Partner, OSS.Capital.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190813/d6ad054c/attachment-0001.html>


More information about the License-discuss mailing list