Licensing: proposed addition with an Apache 2.0 with LLVM runtime exception about scipy HOT 21 CLOSED

But I want it to be clear in the conversation record why it's fine, so if points are being raised to support that position that I don't think accomplish that, I'm going to comment on them.

Yes agreed, this is valuable. We can simply discard the NVIDIA-legal part of this conversation as not relevant.

To recap the reasons:

1. For binary artifacts: after reviewing the LLVM runtime exception clause, it seems clear that that does address the GPLv2 compatibility issue, so there is no problem there.
2. For source-level licensing: after review, there does not seem to be an issue here. We are shipping Apache licensed code in the sdist already, an entry in LICENSES_bundled.txt should suffice. No one has suggested a concrete reason for why this isn't fine. The initial concern was mine, and I'm happy after considering it more closely.

I do agree that it's fine to start including Apache-2.0 WITH LLVM-exception code.

Great. I suggest we consider this resolved then. Final outcome:

1. Using Apache 2.0 + LLVM runtime exception licensed header-only code in SciPy is fine.
2. Using Apache 2.0 licensed code in SciPy is unchanged (still not allowed), but can be addressed/reconsidered once we have a compelling need for it.

from scipy.

As a rule, I consider the actions of large corporations to provide almost no information about what's legally good for us. Legal advice is provided in a context specific to the individual asking (and paying) for that advice. We do not know the actual details of the question given to the NVIDIA legal team, we do not know the details of their response, we do not know what NVIDIA's risk profile is (except that it surely isn't ours), we do not know the goals of NVIDIA. Legal advice is only sometimes a clearcut, universal "this is okay for anyone to do" but usually more "given what you want and ignoring what you don't care about, and given the amount of money you are willing to put at risk in future legal battles, this is okay for you to do."

We already knew that we could mix Apache 2.0 and our BSDish code (i.e. that there isn't a specific incompatibility of terms between the two like there is between plain Apache 2.0 and GPLv2), and that's probably the extent that I'd trust NVIDIA's examination of the matter. I don't think that we can take that as an answer to "did we miss anything else".

from scipy.

i am no longer involved in packaging scientific modules for Debian, so im afraid i cant provide any input.

from scipy.

I think @rgommers covered everything I can think of. The LLVM Exceptions cover the GPLv2 incompatibility that has mostly been our hard objection to Apache 2.0 code. I think it works, from a layman's reading, but it's entirely possible actual lawyers have opinions on whether or not that precise language actually has any real effect. Given its provenance, I'd wager that it's fine, but that's all I'm basing that on.

from scipy.

Thanks @rgommers, @rkern, and @tupui for discussing and considering this. I do think it is a worthwhile thing to pursue.

In the short term, I've written my own poor man's implementation of mdspan to unblock the gufunc PR. I'll be checking that in very soon. I still think it's worth pursuing this licensing discussion, as the Apache 2.0 (now with LLVM exception) has come up before and I'd really much prefer to use the reference implementation.

from scipy.

@leofang confirmed in #20320 (comment) that the situation we're considering here - which is essentially the same for CuPy (Apache 2.0 with LLVM exception + MIT) aside from GPLv2 concern - was reviewed by NVIDIA's legal team and found to be okay.

One thing I'd say is that another NumFOCUS project I work on recently went through a license change process and it was pretty brutal, like emailing every committer.

There is no relicensing involved on our side, only adding an entry in LICENSES_bundled.txt. For kokkos/mdspan it'd be a relicensing, but that'd be a single entity signing off on it, not a ton of individuals.

NumFOCUS can provide this service (it's one the service we are paying for). Might be worth asking them so that it also cover more the project's liability if we do move forward with the proposal.

Last time we asked it took a few months to get an answer, and it seems like the NVIDIA legal guidance is the one we need here. It'll anyway be a "xxx is true, yyy is very likely fine but note that it isn't tested in court". Given that it would also cost NumFOCUS a fair amount of money, I'd say let's not ask.

If we do have a license support question, we should make it a more substantial one I'd say. E.g., it would make a lot of sense to construct full SPDX expressions for all the distributable artifacts we have (including redistributions like on conda-forge), because I suspect that there are multiple little inconsistencies and gaps that have crept in over the years.

The suggestion made in #20320 (comment) was to not use kokkos/mdspan but the CCCL::libcudacxx. If that's judged a better route, the request to the Kokkos team can be closed.

In the short term, I've written my own poor man's implementation of mdspan to unblock the gufunc PR.

Thanks for doing that!

I still think it's worth pursuing this licensing discussion, as the Apache 2.0 (now with LLVM exception) has come up before and I'd really much prefer to use the reference implementation.

Yes, that makes sense.

from scipy.

What relicensing is required from them?

From the issue description: "@steppi opened kokkos/mdspan#321 upstream to inquire about relicensing, which may be possible but isn't a fast decision apparently."

If the answer to that had been yes, there would have been no need for this whole discussion.

from scipy.

Just want to mention that the CCCL::libcudacxx mdspan is the kokkos/mdspan,

Extended/updated for better CUDA support I assume, right? If it's identical, there would be no need for the suggestion. My point was that if it's extended by NVIDIA and then we use that version, then the original kokkos/mdspan being relicensed wouldn't have helped us.

from scipy.

Well, that's docs, and as far as the GPL is concerned, that file would be "mere aggregation" with the GPL code that imported scipy. I'd expect dumb scanners to trip, maybe, but in my experience, the only people that use those and report that upstream without thinking it through are hunting for GPL code to expunge, not vice versa.

I promise I'm not trying to side-track us. I do agree that it's fine to start including Apache-2.0 WITH LLVM-exception code. But I want it to be clear in the conversation record why it's fine, so if points are being raised to support that position that I don't think accomplish that, I'm going to comment on them.

from scipy.

Thanks @rgommers and @rkern. I wasn't sure if we'd come to a final resolution. I understand now @rkern, it does make sense to point out that the conclusions from NVIDIA's lawyers aren't necessarily relevant to SciPy, and make that part of the conversational record.

@ev-br, @izaid, it looks like we can start using either Kokkos' or NVIDIA's mdspan in SciPy. I guess we just need to add an entry for mdspan to https://github.com/scipy/scipy/blob/main/LICENSES_bundled.txt.

from scipy.

Yeah, Robert usually has licensing insights I don't think of. One thing I'd say is that another NumFOCUS project I work on recently went through a license change process and it was pretty brutal, like emailing every committer. Hopefully it wouldn't be that intrusive if we needed to change something.

from scipy.

NumFOCUS can provide this service (it's one the service we are paying for). Might be worth asking them so that it also cover more the project's liability if we do move forward with the proposal.

from scipy.

Proposed resolution here:

1. Using Apache 2.0 + LLVM runtime exception licensed header-only code in SciPy is fine.
2. Using Apache 2.0 licensed code in SciPy is unchanged (still not allowed), but can be addressed/reconsidered once we have a compelling need for it.

from scipy.

The suggestion made in #20320 (comment) was to not use kokkos/mdspan but the CCCL::libcudacxx. If that's judged a better route, the request to the Kokkos team can be closed.

Just want to mention that the CCCL::libcudacxx mdspan is the kokkos/mdspan, see https://github.com/NVIDIA/cccl/blob/2889c3c79c53e4db6394ca86bf09d60ff1fb4897/libcudacxx/include/cuda/std/detail/libcxx/include/__mdspan/mdspan.h#L45

This kokkos/mdspan reference implementation has gone into most compilers and libraries, so far as I can see.

from scipy.

For kokkos/mdspan it'd be a relicensing, but that'd be a single entity signing off on it, not a ton of individuals.

Using Apache 2.0 + LLVM runtime exception licensed header-only code in SciPy is fine.

I don't understand how these two statements gel with the response from kokkos:

Note that we are under Apache-2 with LLVM Exceptions. Thus no attribution is required in binary code, and you just need to not delete our license notice in headers you copy.

What relicensing is required from them?

EDIT: ah, you meant 'if we weren't to accept their current license, then we would want them to relicense. However, given that we can accept their current license, that isn't needed'. Apologies for the noise 👍

from scipy.

By the way, if it is going to be too much of an issue we can get it from the backported C++ version. This is really not a central component for our code. We are really not bound to use any of this if push comes to shove but would be nice if we can.

from scipy.

Just want to mention that the CCCL::libcudacxx mdspan is the kokkos/mdspan,

Extended/updated for better CUDA support I assume, right? If it's identical, there would be no need for the suggestion. My point was that if it's extended by NVIDIA and then we use that version, then the original kokkos/mdspan being relicensed wouldn't have helped us.

Ah, ok, I'm with you now. Yes, indeed.

from scipy.

@leofang confirmed in #20320 (comment) that the situation we're considering here - which is essentially the same for CuPy (Apache 2.0 with LLVM exception + MIT) aside from GPLv2 concern - was reviewed by NVIDIA's legal team and found to be okay.

Just trying to be cautious and clear: the case that our legal checked was CuPy (MIT) vendoring CCCL (Apache 2.0 with LLVM exception). CuPy unlike SciPy does not have any GPLv2 code so the situation was simpler. Any use case beyond that was not covered in the case study and I would advise for seeking legal advices, as I obviously can't speak for our legal 🙂

from scipy.

Sure, I understand, thanks @leofang. That's why I said "essentially the same ... aside from GPLv2 concern". I was more concerned about the other parts (source level redistribution, and "did we miss anything else").

CuPy unlike SciPy does not have any GPLv2 code so the situation was simpler.

SciPy itself also doesn't have any GPLv2 code anywhere. The constraint is more about the ability of a third party to mix in GPLv2-licensed code and distribute SciPy together with a binary built from that other code. Which is not fine with plain Apache 2.0, but fine with the LLVM exception.

from scipy.

Has anyone followed up to ask NumFocus for legal advice on this matter? The immediate concern is resolved, because @izaid wrote his own minimal implementation for use in special, but it would be nice to have the full implementation available for use in C++ code in SciPy more generally.

from scipy.

Has anyone followed up to ask NumFocus for legal advice on this matter?

I have not, since I don't see the need. My proposed resolution posted above (#20396 (comment)) is fine I think.

The few comments on the relevance of what NVIDIA legal thinks side-tracked us a bit, but I think the situation is clear either way. As an extra data point not mentioned before: we have been shipping Apache 2.0-licensed code (no LLVM runtime exception, plain old Apache 2.0) in our sdist and repo for many years (namely in doc/source/_static/scipy-mathjax) and we've never had a complaint. So I don't think there's anything new here, the question is resolved for me.

from scipy.