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

[Henrik Ingo]

On Wed, Aug 14, 2019 at 5:35 PM VanL <van.lindberg at gmail.com> wrote:

> 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.
>
>
>
This is all fair counter arguments. As you've seen in other threads, I'm
not the biggest fan of AGPLv3 either, where the license all but assumes a
Graphical UI. (To be clear: I am a fan of copyleft and the AGPL, I just
think there's room for alternatives.) Otoh through the discussions this
year I've also learned to respect the value of crafting open source
licenses that don't burden use of unmodified versions of the software.

I don't want to debate whether my suggestion is better than your current
position. I expect that others will be more resistant to this idea as a
whole anyway. I wanted to address the arguments about not burdening "mere
use" with legal requirements and risk. Should that become the primary
argument of your opposition, you can always reconsider whether you want to
seek shelter at my proposal after all.

(I will silently consider to what extent I could approve of your current
text if you submit it to license review. It's certainly improved from last
time, but the idea remains problematic even to me.)



>
>> 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.
>
>
I agree. I'm splitting hairs and clarifying the issue here and maybe in a
FAQ example is sufficient. The real issue is the ambition to claim rights
to competing API compatible implementations.


> 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.
>
>
Forgive me, but that is just a redundant statement that is legal weasel
wording. You're essentially still saying that if an API could be protected
by copyright, in some jurisdiction, then the CAL would still claim those
rights. In my understanding, the previous review round was fairly strongly
against this.


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/20190815/2dc3a0b3/attachment.html>