[License-review] For Approval: License Zero Reciprocal Public License

[Carlo Piana]

On 26/09/2017 04:07, Kyle Mitchell wrote:

[...]
> On to your questions.
Thank you for adding this level of clarity. Unfortunately, this only
reinforces my views.
>
> "Use in the execution and development of any computer program" is written in technical terms, not legal terms.  Court I'm familiar with will see those word choices, gather that they are technical terms, rather than legal ones, and ask, "What would software people mean by 'execution and development'?".  The court would ask for evidence from software people, not lawyers.
>
> You gave a specific example.  As a software person, I _would_ read the language to apply to programs compiled with an L0-R compiler.  Yes, that's new.  And intentional.

Besides it being against the OSD, I find this concept fairly
overreaching on general policy grounds.
>
> As for the Definition, I'm afraid I can't read it as you do.  OSD criterion number 6 prohibits limits on use of software in "fields of endeavor", not all limits on use, flat-out.  It gives two examples, business and genetic engineering, that are broad reasons for using software, not choices about how to license software.  And we all know a famous counterexample, the JSON License's prohibition on use for evil, very broad indeed.  OSI's annotations describe the major intent of the criterion to exclude noncommercial use limitations.  Commercial use of L0-R code is very possible.

Again, this is plainly wrong. It means that you cannot *use* (mind: not
distribute, just use) this software in a legal way if the software you
are interacting with is not under a license that allows you sharing the
code either on legal or material grounds (e.g., it's BSD, but you didn't
receive the source). That limits the field of endeavor very much indeed.
The examples are just examples. "Genetic research" is no different from
"Proprietary software development and/or consumption". You may find a
confirmation in #9 as well: the same rationale applies here.

JSON limitation, besides being rather vague and undefined and ultimately
probably inapplicable, is not AFAICT an OSI approved license, and you
can read many comments online criticizing (I seem to remember discussing
it here or maybe in other licensing discussion fora, sorry, can't recall
it precisely).

>
> We know from the choice of words, from the examples, from the annotation, and from the approval of licenses like AGPL, that the criterion does not prohibit all possible limits on use.  Modifying an AGPL program and using it in such a way that users interact with it remotely, without any opportunity to receive source, is not permitted.  But AGPL meets the Definition, including criterion 6, even if users over the network never receive any copy of any part of the software.  Often they don't.

AGPL limits the use of the software as well, but only insofar as you
provide public access to the software you are running. If you use it
privately, then you can modify it at leisure. The example is way way
different.

The fact that people would not use of their right is immaterial, the
license sets copyright conditions, and these conditions by no means
WHATSOEVER limit your use if this use does not involve network access.

I agree that AGPL stretches a bit the Definition, but not on the right
to use, rather on the right to MODIFY the software, and only if you aim
this in a situation which is functionally equivalent to distribution.

[...]


All the best.


Carlo