[License-review] For approval: The Cryptographic Autonomy License (Beta 2)
VanL
van.lindberg at gmail.com
Fri Aug 23 14:39:55 UTC 2019
Hi Pam,
You bring up a number of points across a couple email messages. I am going
to try to consolidate my response.
On Fri, Aug 23, 2019 at 8:04 AM Pamela Chestek <pamela at chesteklegal.com>
wrote:
> Van, saying that an extreme interpretation of the AGPL is what your
> software's intended scope is doesn't win you any points in my book. Some
> people hold the view that the AGPL goes too far already, so saying that
> your license bakes that extreme view in only works against you IMO.
>
This is a fair point. But:
1) We are making worst-case assumptions about the CAL in this forum. That
is understood, it is for the purpose of stress-testing the license. But
then is it not fair when comparing to the AGPL - the closest analogue - to
show how the same assumptions would play out?
2) More generally, I can make a number of simplifying assumptions about
your use, or the Twitter widget, that would reduce or eliminate the
compliance burden. For example, if your Twitter widget only worked on your
server, and it didn't communicate any aspect of itself to a visitor to your
website, the CAL wouldn't reach it. You would have no compliance burden at
all. I can even argue that such an implementation might even be more
probable.
But that is fighting the hypothetical. I would submit that any copyleft
license, regardless of the scope, has hard cases. The goal here is to
analyze the cases as they are presented, in the light most unfavorable to
the CAL, and present the results transparently. I don't flinch away from
the hard cases, and I have tried to write the CAL so as to minimize them to
the greatest extent possible.
>
> On 8/22/2019 9:12 PM, Bruce Perens via License-review wrote:
>
> But would it not be sufficient in this case to simply tell folks where you
> got the source, given that it's a public repository? You didn't modify it
> yourself.
>
> Not necessarily. The source code obligation says that the repository must
> persist as long as I am using the software and for a year after that. So do
> I keep checking the original source and make sure they haven' t changed it
> and it's still the same software that I used? What if they update and I
> don't? And to have to do that for a year after I'm not even using the
> software? This avenue for compliance is pretty burdensome.
>
This is roughly equivalent to the "offer of source" in the A/GPL, and that
has to persist for three years. By my reading, the CAL is less burdensome
in that regard.
> You pointed out the difference, it has to be modified, plus it must be
> software that involves remote interaction. That suggests at least some
> degree of familiarity with software beyond simple use, so the compliance
> obligation perhaps isn't as unreasonable. You seem to be suggesting that
> an "aircraft-carrier-sized escape hatch" is a bad thing, but I assume
> it's for people like me. I don't have any compliance requirement for my
> Twitter widget, for two reasons, I didn't modify the software and it's
> not interactive. It's the exclusion that makes the AGPL consistent with
> a foundational aspect of the GPL licenses, the act of running the
> software is not restricted.
>
I'd disagree with your characterization here. By the standards of the AGPL,
the twitter widget is "Interactive." Under an equivalent reading of the
license, it is also modified. Thus, I would suggest that the compliance
burdens are the same (or, as I point out with regard to the offer of
source, actually less burdensome).
Thanks,
Van
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190823/464f7c50/attachment.html>
More information about the License-review
mailing list