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

Mon May 13 16:33:34 UTC 2019

I have been sympathetic with Van's attempt - clearly genuine - at
providing user freedom also for user data. Because of this I was
previously silent on the question whether this conforms with the OSD.
On its face it doesn't (more on that below), but it's clearly a good
faith proposal, so warrants at least a fair discussion.

Previously on license-review the License Zero license proposed a
requirement to publish anything *created with* the licensed software.
(https://licensezero.com/licenses/reciprocal §5) I didn't read all of
that thread, but I understand this was at least one reason it was
rejected. Josh Berkus' position is that this doesn't fail any clause
in the current OSD, but is clearly against long standing consensus and
should be added as a new OSD clause.
(https://twitter.com/fuzzychef/status/1122204342113558528) OTOH a
broad interpretation of OSD6 could apply. In either case there clearly
is precedent in the community for discussing this: Software created
with GCC is not required to be GPL licensed, and I wouldn't expect to
have to publish every text I wrote with OpenOffice. Maybe the only
reason OSD doesn't have such a clause is that it was too obvious and
non-contentious, even back in 1998?

While the OSD remains unamended, I think the License Zero outcome can
be used as precedent. I wanted to add it to the discussion, in
addition to Bruce's invocation of FSF Freedom 0.

Within the background set by both of those then... It still seems to
me that CAL has scoped this requirement in a way that is rather well
justified:

"“User Data” means any data that is either a) an input to, or b) an
output from, the Workor a Modified Work, in which a third party other
than the Licensee has a Lawful Interestin the data."

- It is not unreasonable that a user has the right to access data that
is theirs. (e.g. a photo that I own copyright in) This doesn't require
the user to give away rights to the data (as License Zero did).
- The 21st century problem addressed here is that we still want to
protect user rights. Historically the operator WAS the user, and
therefore this was an easier question to solve. In SaaS this is not
the case. We must now decide whether software freedom gives the
operator rights against the user, or vice versa.
- Since the CAL limits User Data to something that is an input or
output of the system, it's also not unreasonable burden to expect the
software to provide an easy to use option to exercise this right.
(E.g. access logs incidentally created by a user don't apply.)

When I look at this, it seem Van has a quite strong argument that on
this part, the CAL is a net positive contribution to software freedom.
BUT, to arrive at this conclusion, we have to interpret "Freedom to
run the program for any purpose" as the operator here is running the
program *on behalf* of the user. The whole idea of network copyleft is
IMO justified by this same view though! I fully get that not everyone
is ready to agree with me there.

While it seems Van has succeeded in scoping CAL in a way that is quite
defensible, I also agree with Bruce that this whole topic is a can of
worms. Also, if I were to imagine a future OSD clause that rejects
licenses that restrict data/input/output of the software, maybe (in my
imagination) proposed by Josh Berkus, it may be hard to craft a
sentence that would still allow for what CAL is carving out.

So it seems after so many words, I still don't have a strong opinion
one way or another.

One more thought though: Maybe one reason we currently see so many
proprietary SaaS platforms hoarding user data, is that the software
world is dominated by permissive open source and proprietary software.
(And in a SaaS context, anything from GPL down are permissive
licenses!) Maybe if there were more network copyleft licenses
available, and most importantly, projects used the ones that are
available, and finally, users preferred such SaaS services, then maybe
this would also create a dynamic where federated services empowering
users was a norm, and Van wouldn't need to propose a license forcing
such a fix? Maybe the User Data sections of CAL are a knee jerk
reaction to a symptom that would go away but just focusing on the more
fundamental proplem: From SaaS to IaaS, most of today's services are
just proprietary, period.

> "Obviously I don't have the Freedom to run the program without hardware"

I look forward to reviewing your "Free Iphones for Everyone License" :-)

The key here really is that the CAL responsibilities are limited to
data that user already has an ownership interest in. Anything beyond
that would clearly be unacceptable and not deserving a discussion.

> Obviously I have many other problems with the license.

As do I, for some small value of "many".

henrik

On Fri, May 10, 2019 at 7:38 AM Bruce Perens via License-review
<license-review at lists.opensource.org> wrote:
>
> Van,
>
> It seems to me that you have re-defined the Free Software Foundation's version of Software Freedom, arbitrarily, to encompass data rights. It doesn't seem that this should be your task alone, or that of your customer. Perhaps the Free Software Foundation would want to be involved :-)
>
> The problem with the way you have done it is that it provides your newly-defined Data Freedom to people at the expense of someone else, who loses the Freedom to run the program as they like under the FSF version of Freedom to which the OSI signed on.
>
> I could play this game too, by extending the definition of Freedom in other arbitrary ways. Perhaps by adding hardware rights. And then when anyone asked me why having to provide others with hardware wasn't removing their freedom, I would say  "Obviously I don't have the Freedom to run the program without hardware".
>
> The point here is that it's an arbitrary re-definition. Each different arbitrary extension of Freedom probably would be at someone else's expense, and reducing their Freedom under the classical FSF definition of Freedom.
>
>     Thanks
>
>     Bruce
>
> On Thu, May 9, 2019 at 8:44 PM VanL <van.lindberg at gmail.com> wrote:
>>
>> The CAL and the GPL preserve freedom in exactly the same way. You are not being precise enough in your reading. The CAL does not prevent anyone from running the program as they wish. There are no use restrictions in the CAL, except those that, in the words of the GPL:
>>
>> "To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others."
>>
>> This statement applies perfectly to the CAL. If I were to update the GPL preamble for the CAL, I would only say:
>>
>> "The CAL is designed to make sure that you have the freedom to use and distribute copies of free software (and charge others for services you provide or source code if you wish), that you receive your data and the source code from those who provide the software to you, or can get those things if you want them, that you can change the software or use pieces of it in new free programs, that you can run the software to process your data in the context of your choice, and that you know you can do these things.
>>
>> To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you provide the software to others, or if you modify it: responsibilities to respect the freedom and the autonomy of others."
>>
>> The CAL doesn't restrict freedom zero. It just curtails the economic incentive for others to act in ways that restrict other's freedoms by also requiring them to also turn over those things that grant them exclusivity and thus, power.
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org

-- 
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