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

Mon May 13 17:21:30 UTC 2019

#9 would work for GCC (although it doesn't seem to be your intended
use case) but not for OpenOffice.

I think OSD works quite well as a constitution and should remain
short. I'm quite comfortable with OSI justifying decisions with there
existing an obvious community consensus. (And other reasons, not even
requiring consensus. Including the lack of consensus!)

henrik

On Mon, May 13, 2019 at 7:58 PM Bruce Perens <bruce at perens.com> wrote:
>
> The closest clause to what you are thinking of is #9. But this brings up a problem. There are an infinite variety of somewhat pernicious terms, but an OSD which restricted all of them would be unbounded in size. Similarly, if we turned the OSD around and made it state the allowed terms, rather than the prohibited ones; as I might have done 21 years ago, had I experience I had not yet acquired; simply encompassing the already-approved licenses might result in something quite large.
>
> Think of some of the oddball terms that were not necessarily in the interest of the community, but would be difficult to disallow simply from the OSD text, especially with an assumption that #5 and #6 should not be broadly applied. For example, the Bitkeeper license term which required that you connect to their log server and log your activities. The NASA license term that applies contractual restrictions to the public domain. The Open Hardware licenses that attempt to apply copyright to hardware designs still considered the exclusive domain of patent, and thus help to drive a creeping expansion of copyright that would be turned against us.
>
>     Thanks
>
>     Bruce
>
>
>
> On Mon, May 13, 2019 at 9:33 AM Henrik Ingo <henrik.ingo at avoinelama.fi> wrote:
>>
>> 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

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