[Numpy-discussion] New package to speed up ufunc inner loops

[Robert Kern]

On Wed, Nov 4, 2020 at 5:55 PM Aaron Meurer <asmeurer at gmail.com> wrote:

> On Wed, Nov 4, 2020 at 3:02 PM Robert Kern <robert.kern at gmail.com> wrote:
> >
> > On Wed, Nov 4, 2020 at 4:49 PM Aaron Meurer <asmeurer at gmail.com> wrote:
> >>
> >> I hope this isn't too off topic, but this "fair play" NEP reads like
> >> it is a set of additional restrictions on the NumPy license, which if
> >> it is, would make NumPy no longer open source by the OSI definition. I
> >> think the NEP should be much clearer that these are requests but not
> >> requirements.
> >
> >
> > FWIW, I don't read the NEP like that. Aside from the trademark on the
> name "NumPy", which _are_ enforceable requirements but are orthogonal to
> the copyright license, I see enough "request-like" language on everything
> else.
>
> To be clear, I don't read it like that either. But I also implicitly
> understand that this is the intention of the document, because I know
> that NumPy wouldn't actually place restrictions like these on its
> license. My point is just that the document ought to be clearer about
> this, as I can easily see someone misinterpreting it, especially if
> they aren't close enough to the community that they would implicitly
> understand that it is only a set of guidelines.
>
> > There is no language of forced restriction.
>
> The language you quoted reads ambiguously to me. It isn't forced, but
> it also isn't obviously nonforced. "Please talk to us first" is the
> sort of language I would expect to see for software that is
> commercially licensed and can only be used with permission. All the
> bullet points say "do not", which sounds forced to me. And the
> trademark thing makes it even more confusing because even if you read
> the rest as "only guidelines", it isn't clear if this is somehow an
> exception.
>

If you pick out an individual sentence and consider it in isolation, sure.
But there's a significant amount of context in the Abstract, Motivation,
and Scope sections that preface the rules. And the discussion of many of
the rules explicitly discusses ways to "break" the rules if you have to. We
use "rule" language in many contexts besides legally-enforceable contracts
and licenses.

Again, *I* understand the purpose of this document, but I think the
> way it is currently written it could easily be misinterpreted by
> someone else.
>

I'm willing to wait for someone to actually misinterpret it.

That's not to say that there isn't clearer language that could be drafted.
The NEP is still in Draft stage. But if you think it could be clearer,
please propose specific edits to the draft. Like with unclear
documentation, it's the person who finds the current docs
insufficient/confusing/unclear that is in the best position to recommend
the language that would have helped them. Collaboration helps.

-- 
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20201104/d0531892/attachment-0001.html>