[License-discuss] For Discussion: Cryptographic Autonomy License (CAL) Beta 2

[Henrik Ingo]

On Thu, Aug 15, 2019 at 3:00 PM VanL <van.lindberg at gmail.com> wrote:

> Hi Henrik,
>
> On Thu, Aug 15, 2019, 6:16 AM Henrik Ingo <henrik.ingo at avoinelama.fi>
> wrote:
>
>>
>> Forgive me, but that is just a redundant statement that is legal weasel
>> wording. You're essentially still saying that if an API could be protected
>> by copyright, in some jurisdiction, then the CAL would still claim those
>> rights. In my understanding, the previous review round was fairly strongly
>> against this.
>>
>
> I would have you know that I am 1/16 weasel. On my mother's side.
>
>
:-)


> More seriously, the CAL goes right up to the border of copyright, whatever
> that may be. I don't apologize for that. I understood the policy concern
> resulting from appearing to push the boundaries, so I removed that.[1] But
> the CAL makes the same bargain as other reciprocal licenses - and if I am
> correct about where the law will end up, has exactly the same scope.
>
>
Ah. Thanks for this. It helps me be clearer:

I think in your previous review, there were two distinct objections:

1. Assuming that APIs are or should be copyrightable goes against policy
goals of OSI / open source community
2. Even if APIs are - perhaps one day in the future - copyrightable in some
jurisdiction, an open source license shouldn't assert those rights. At most
it could be mentioned to grant such a right explicitly.

So I agree that you have addressed the first objection and was raising a
concern about the second. Not all reviewers supported the second objection.
I don't. Even then, I wouldn't support a license proposal that tries to
sneak by such a significant new issue without being very explicit about it.
In effect, that makes even myself opposed to asserting API copyright *at
this point in time*, since I don't think it can be done explicitly (1) yet,
and certainly wouldn't support a license trying to do it vaguely, like this
version of CAL attempts to do.

So to make progress with CAL now, you would have to clearly retract any
previous attempts to also have it cover APIs.

Also, we must be vary of the possibility that if we end up in a future
where APIs can violate copyrights, then very likely there can exist
software that is "Unrelated software" in the OSD sense, yet infringes
copyright by law. An open source license cannot assert rights against such
unrelated software.


> [1] My thinking here was motivated in part by some of my old writings
> criticizing the GPL FAQ for its interpretations that very much do push the
> boundaries of copyright, but are quoted as near-scripture and taken as
> authoritative.
>
>
In fact, this remark is totally relevant. Like many, I agree that the FSF
can be criticized for how it has expanded the reach of GPL by trying to
expand the legal meaning of a derived work. While that wasn't a great idea,
I do think that:

 - It worked. Majority of open source users conform with the FSFs
assertions, because they want to avoid legal risk, PR risk or "hassle".
 - We/Me tolerate it, because we support and find the underlying goal
reasonable, AND
 - It's less of an issue because the same objective* could have been
achieved by a different language which doesn't depend on the legal
definition of a derived work.
 - We may be more forgiving of such games when done by a non-profit for
ideological reasons.

...so in essence the real problem is just an imperfection in GPL license
text. (In reality of course it's a more complex issue. But also in reality
this behavior from FSF is tolerated.)

*) By same objective I mean things like unambiguously requiring that
dynamically linked libraries, or PNG files in Wordpress, are covered by the
copyleft obligations, regardless of whether those are derived works of the
GPLd code.

In your case...

 - The risk is that being vague in the license and aggressive outside the
license will also work!
 - I don't support the underlying goal of making money and attacking
competing implementations.
 - I don't think your objective can be achieved with any text and also
conform to "OSD and software freedom"
 - See second point

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190815/4c76df06/attachment.html>