On Tue, Mar 19, 2019 at 5:35 PM VanL <van.lindb...@gmail.com> wrote:
> [Initially replied just to Henrik; resending to whole list. Thanks,
> Henrik, for catching that!]
> Two points. First, and as I hope will become clearer after this email, the
> CAL and GDPR have different scopes, so it is appropriate to have a
> different instrument. Second, *you* may have some rights under GDPR, but
> *I* don't.
>
>
Sure. And it is only this most recent reply that has helped me understand
what your intended scope was in the first place.
> That said, I think I better understand your point. You suggest that, due
> to my phrasing and the consistent interpretation clause, I am suggesting
> that User Data == Personal Data, leading to some of the ambiguities you
> identify below. I have updated the language as follows:
>
> *To the extent allowable under the Applicable Jurisdiction, provision of
> User Data in compliance with the conditions in section 2.3(a) and 2.3(b)
> shall be interpreted consistently with the formatting and transmission
> requirements of General Data Protection Regulation (EU) 2016/679 ("GDPR")
> Arts. 15(3) and 20(1). The number of copies of User Data provided in
> compliance with the conditions in section 2.3(b) shall be at least the same
> number needed to comply with GDPR Art. 15(3).*
>
> This provision makes clear that the consistency provision makes reference
> to the number and format of User Data to be provided, and does not invite a
> comparison between User Data and Personal Data.
>
It's clearer. Thanks.
It's IMO regrettable that the goal of the CAL isn't to protect the entire
scope of GDPR personal data (in addition to copyrighted ebook data),
because that would have been really cool, but since I am not your client in
this project, I will have to settle with the victory that the above is at
least clearer now.
Btw, it will probably continue to be a source of confusion that people
commonly say - and think of "user data" - when they mean GDPR personal
data. No matter how clear you make the license itself, calling out this
difference seems like a good FAQ entry. (Even I started out googling with
"user data", and google was smart enough to point me in the right direction
anyway.)
>
>
>> Those merely prevent licensee from preventing me from circumventing DRM.
>> GPLv3 says I'm entitled to have the keys. Big difference.
>>
>
> See 2.3(a) and 2.3(c). You have to provide the keys. The Recipient of the
> ebook software has a Lawful Interest in the ebook as User Data. So you
> can't lock it up.
>
This is clearer now. I think the remaining weakness is what has been
pointed out by Bruce, that DRM measures, especially restricting
installation of software itself, is often not a property of the software,
rather controlled by OS or other outside mechanism.
To my layman understanding it seems this would be improved if you flipped
the order and causality to: "You may not use crypographic [things] to
control the Software..." Or possibly the license needs both the current
sentence and also this.
>>>
>>
>> Even in the legal field,
>>
>> 1. What precedent is there to talk about public performance *for
>> software??? *I'm not denying that the law wouldn't cover this, just that
>> we have no context to predict the outcomes of walking down this path, and
>> that makes such a license the copyright version of Russian roulette!
>>
>
> You are correct. Public performance in software is not well defined. You
> are also correct that for some people that may increase the perceived risk
> of using the license (either as a licensor or licensee). I believe that the
> definitions provided - and incorporated directly into the license as a
> defined term (CAL 6(m)), significantly ameliorate that risk.
>
>
Well, it's of course true that people can choose to use this license or
not. The relevance of discussing this now is that if you intended to submit
this license later for OSI approval, issues like "nobody can predict what
this license will mean in practice" and "developers and users are likely to
get sued" tend to become obstacles. And it's an entirely avoidable obstacle
since the issue is merely with language rather than the goals of the
license.
If we again compare to the GPL, merely to draw from existing history and
practice, it always explicitly didn't restrict "unlimited permission to run
the unmodified Program". In my understanding this is motivated by making it
absolutely certain that a user can never get sued for anything. This
approach of course also self-imposes some limits to the GPLs powers, and
I'm not saying other licenses should do the same, but the principle of
protecting users and non-lawyered developers should be given similar
priority as the FSF has done.
6m seems to be written broadly, so that it *does* include all possible
interpretations of "public performance". Even if you tried to limit the
scope of public performance in CAL, I don't see that you can simply
redefine public performance to mean something else than it already means
for music and other types of work, rather you would have to explicitly
exempt some types of public performance by saying that they are not limited
but permitted. And since the scope of public performance is a bit unknown,
and music industry (among others) is actively working to broaden it, the
CAL would probably need to explicitly say what type of public performance
is governed by the license, and then say that "any other" public
performance is allowed without any limitations or obligations.
Famously, the Eiffel tower is still considered a public performance in
France <https://en.wikipedia.org/wiki/Freedom_of_panorama>. This issue has
been bitterly fought for 5 years (and beyond) and aligning yourself on the
copyright maximalist side of that discussion seems like an odd approach for
a new open source license.
>
>> Links are welcome, including to your blog, which I didn't read, because
>> the intro didn't give me confidence it would answer these questions.
>>
>
> Well, I did say that the blog post was long and possibly boring. So I
> don't blame you for not reading it. However, I have an entire section
> addressing the question of public performance of software. (
> https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#copyleftandthepublicperformanceofsoftware
> )
>
>
Thanks! Your blog did quickly become very US centric, and since my primary
interest in this was my being a EU "data subject", I had stopped reading at
that point. But that was a concise and well referenced explanation well
worth reading.
In addition to concerns I already raised above and in previous email,
reading this reminds me of an email Bruce sent in January
<https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020261.html>.
I realize now it may have been motivated by the CAL all along? Key point:
"In addition, I think there's a principle here. Extension of copyright is
bad for Open Source, even if it helps us enforce our licenses more
effectively."
I'm myself always open to discuss ways of making copyleft stronger, but
Bruce has a valid point. In the case of CAL my argument is that you can
achieve the same goals by using legal tools already existing in the
software industry, so pioneering the use of public performance has only
downsides (for users of CAL, but also all of us) but little benefits.
>
>> (Restricting based on type of business or use would not be OSD compliant).
>>>
>>>
>> You seem to be under the impression that this license is about SaaS use.
> That is not so. While it is intentionally written to be useful for the SaaS
> use case, the purpose of this license is to maximize user freedom in a
> distributed system. Again, as I wrote in my blogpost:
>
>
I use SaaS broadly as you have marketed this as "network copyleft". We can
use "Remote Network Interaction" (from AGPL) or any other term if you
prefer.
That said, the fact that Holochain is more peer-to-peer than a typical SaaS
application is indeed architecturally interesting. For now I will resist
the temptation to analyze CAL from that perspective, but hopefully that
will also be discussed at some point!
> You are missing my point. A link in the GUI, such as a Help > About box,
>> or a link in the website footer, does not suffice. It will not be visible
>> on the screen in the park, nor can the passers by grab a mouse and navigate
>> to it. So they will have been recipients of a public performance, and it's
>> now your responsibility to run around the park to hand each of them a paper
>> slip with the download url, but also all the necessary attributions.
>>
>
> This is incorrect. A link, just as with the AGPL case, provides sufficient
> compliance for this use case. Passers-by have no User Data, no legal
> relationship, etc.
>
Passers by have been recipients of a public performance. These examples are
straight out of existing case law and money exchanges hands every month
based on this being legally established. Licensees have fought these cases
in court and lost and now they're paying.
> I now see that the preamble actually specifies 2 different long form
>> names, the other one being "with exception". That is a good start. But it
>> would still be cleaner if I could omit ยง2.4 completely, if I don't want to
>> offer the exception.
>>
>
> I understand your preference, but I think it is more useful to keep as-is
> and allow people to use it or not as they wish.
>
>
My thinking here is that once software is published without exception, it
is never again possible for later contributors or forks to choose that
exception (for that software). So the text is unnecessary when not applied.
But the existence of that text in the license file can lead people to think
it's an option for them to choose. Experience with copyleft licenses
educates us that people are strongly biased to believe they can do whatever
they desire to do, and the copyleft requirements really only applies to
someone else.
henrik
--
henrik.i...@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
_______________________________________________
License-discuss mailing list
License-discuss@lists.opensource.org
http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
