[License-review] For Approval: The Cryptographic Autonomy License

[Henrik Ingo]

On Fri, Apr 26, 2019 at 6:14 PM VanL <van.lindberg at gmail.com> wrote:
> On Fri, Apr 26, 2019 at 9:49 AM Henrik Ingo <henrik.ingo at avoinelama.fi> wrote:
>> I was not very clear about it, but indirectly I was inviting you to
>> justify why you think it is *necessary* to use the concept of Public
>> Performance in CAL. What problem - other than just maximizing the
>> power of copyright law - does it solve for you that wasn't adequately
>> solved without it?
>
>
> There are a couple reasons. First, when dealing with a network copyleft, there aren't a lot of options - only the AGPL. Thus the analysis started with "would the AGPL work" and proceeded from there. In this case, the AGPL was not considered a sufficient vehicle because:
>
> 1. The network aspect of the AGPL only applies to network interaction with a modified version. There are issues with this:
>    - It doesn't clearly provide attribution or source code for unmodified versions
>    - Network interaction is gameable to avoid providing source (Just put a proxy in place - I have seen this happen many times)
>    - In the context of protecting access to User Data, the AGPL's "network interaction with a modified version" would only be effective in the cases where the software was modified - a minority of the time.

So, I definitively agree that alternatives to AGPL are welcome. The
proxy-loophole incarnates into a lot of different variations. More
generally I would say the problem with the AGPL is that it inherits
from the GPL the mindset that the covered work is executed as a single
process in a single computer, into which there exists a network
connection.

> 2. The AGPL is ambiguous in its application in a corporate context. For example, if a modified version of an AGPL program is used within a company, and not provided to any outsider, do employees have rights to the code to the modified version? I would argue that they do, and that the employer cannot prevent the spread of trade secret AGPL programs because to do so would be an additional restriction.
>

Good point. (Without deciding whether I agree with the above...) An
AGPL user is not the same as a recipient of a copy.

> Finally, I personally think that grounding the network interaction in a clearly articulated existing right, already written into copyright law, is superior to defining a new term like "network interaction" that is unique.
>

This is really just were we disagree. I think public performance
applied to software is completely uncharted territory. (And partly as
a consequence...) the license in both cases would have to spend some
effort in describing what exactly is protected or burdened with
requirements. Your current proposal doesn't bound "public performance"
at all, which feels very hazardous. (Thread on license discuss
enumerated several scenarios of unintended legal hazard.)

The AGPL inherits from GPL the sentence "This License explicitly
affirms your unlimited permission to run the unmodified Program." The
way I read FSFs motivations, this is to explicitly ensure that a
regular user can not infringe and get into any legal trouble. Which is
great, but contributes to why the AGPL is implemented in a somewhat
awkward way: It describes functionality that the Program must have,
rather than just saying that when you offer the Program (as a
service'ish) to other users, you are required to offer corresponding
source. (Among other things, this may limit the usefulness of AGPL to
software with unusual user interfaces.)

There's no requirement for all open source licenses to follow down
this same awkward path. We obviously remain concerned about minimizing
legal burden and risk to an ordinary user, but I would argue that
simple and clear legal terms can also contribute to that goal! In this
case, the existing tradition of copyright licenses for software
already gives you virtually unlimited powers to put restrictions on
someone executing CAL-licensed software on a network server. The
invocation of a public performance right only adds uncertainty, but
little practical value.

Note btw, that "network interaction" needn't be defined in those terms
either. Any user interacting with the software probably should have
those rights, whether using it via a network, on some kind of kiosk,
or whatever interface. It seems to me there's a more generic
definition out there that is both simpler than focusing on the special
case of "network interaction" and would also benefit a broader user
base than users of SaaS or P2P (networked) software.

>> > If you take a look at the exact text, the text is very close to the GPLv3. There was quite a bit of "borrowing" in exactly the way you suggest.
>> >

Thanks for the specific GPL extracts and mapping.

This thread is maybe hard to pursue now that it turned out my memory
was stuck on a GPL sentence that didn't survive the drafting process.

Regardless of the GPL, I wanted to point out a common kind of DRM that
doesn't seem fully addressed by the CAL. Possibly it could be a
loophole.

But in any case it's of course also true that loopholes - this one, at
least - aren't a violation of the OSD. So this issue doesn't stand in
the way of OSI approval for CAL.

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