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

VanL van.lindberg at gmail.com
Wed Aug 14 14:35:22 UTC 2019


Hi Henrik,

Thanks for your comments.

On Wed, Aug 14, 2019 at 8:02 AM Henrik Ingo <henrik.ingo at avoinelama.fi>
wrote:

> Data autonomy
>
> Wrt the discussion of not encumbering mere use / private use with any
> obligations, I notice there's first of all a very explicit carve out for
> "your private purposes". Also the first paragraph of 4.2 is in the same
> spirit I think. But I think 4.2.1 still falls a bit short of drawing the
> right boundary. I think the reasonable boundary is: 1) If the software you
> received includes functionality for the user to download his data, you
> cannot remove or encumber this functionality. 2) When you add functionality
> that causes more data to be stored, it must be available through the same
> or similar functionality.
>

[snip]

I see where you are going by this, but I don't think that works.

First, as you note, your proposed modification would have the result of
making certain parts of the software un-modifiable, which I think is a
no-go.

Second, it doesn't seem proper to me to dictate the structure of someone's
program. I want to identify the policy that needs to be upheld, not the
mechanism.[1] There are a million ways to be compliant with the CAL; I
don't want to bake something in where it would not be appropriate. For
example, even "I tar up the files and email them to you" may not be
efficient, but it would be compliant.

Third, there are examples of later-added "user data download" functionality
(e.g., Google Takeout) that would be hypothetically compliant with the CAL.
So it doesn't seem unreasonable to say that functionality could be added to
assist with compliance, if necessary.

Fourth, termination is not immediate; termination due to non-compliance
only occurs if the licensee does not comply within 60 days of being
notified of non-compliance. That gives adequate time for even inefficient
measures, and prevents this from being a "submarine" issue.





>
> API copyleft
>
> You no longer make any references to "public performance", so the issue of
> pioneering a new evil copyright power is avoided. Similarly there doesn't
> appear to be a direct claim on API copyright.
>
> *"4. If You exercise any permission granted by this License, such that the
> Work, or any part, aspect, or element of the Work, is distributed,
> communicated, made available, or made perceptible to a non-Affiliate third
> party (a “Recipient”), either via physical delivery or via a network
> connection to the Recipient, You must comply with the following conditions"*
>
> There is no question that a software license can claim rights in all of
> the above things. Also, since you are granting these rights, there's no OSD
> issue as such.
>
> While this is narrower than the previous version, I think my practical
> questions still remain: If the work is "made perceptible" via a video
> screen in the park, do the photons emitted by the screen still fall within
> "physical delivery"?
>

I thought very hard about your "public park" example, and that is why I
chose those specific words. I don't think a walk-by would result in
"physical delivery" of the software under any reasonable standard. If this
ended up being the only issue, I would consider "tangible physical
delivery," but I don't think it is necessary.



>
> Rather than nit picking on that, let's go to the real issue: Since you
> didn't say anything about APIs or interfaces, it seems to me words like
> "aspect", "perceptible" and maybe "elaborate" remain in the license because
> the goal of your client clearly still remains to assert copyleft on an
> independent work implementing a compatible API.
>

This depends. If the independent work contained protectable, licenseable
portions of the CAL-licensed work, then it is not "independent," it is
derivative.

If the independent work did not contain any protectable, licenseable
portions of the CAL-licensed work, then I don't think the CAL could reach
it under any standard.



> I think 5.3 would benefit from following clarification: " In the event of
> termination due to litigation initiated by You,"
>

Done.

Thanks,
Van



[1] For the old-timers, yes, this is in deliberate contrast to X11. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190814/2c72d58b/attachment-0001.html>


More information about the License-discuss mailing list