Migrate to BSL instead of MIT license? about open-gpu-kernel-modules HOT 26 CLOSED

You could just attribute them?

from open-gpu-kernel-modules.

https://pdimov.github.io/blog/2020/09/06/why-use-the-boost-license/

Good thing this is not C++ nor a library then.

from open-gpu-kernel-modules.

why not just say you used nvidia code???

https://pdimov.github.io/blog/2020/09/06/why-use-the-boost-license/

from open-gpu-kernel-modules.

Not all organizations can put attributions in binaries, for various reasons. Microsoft for example cannot use MIT licensed code as part of its standard library (because that would obligate anyone who compiles the standard library into their executable to show attribution in the binary).

from open-gpu-kernel-modules.

At least, the title should be like "migrate to Boost Software License?" IMO.

from open-gpu-kernel-modules.

That license isn't going to work for that.

That isn't quite right though. The Boost Software License is a drop-in replacement for any project which currently uses the MIT License. It is applicable in exactly the same scenarios that the MIT License is applicable. To put it in different terms, regardless of the specifics of the project - if it is currently using the MIT License, then it is better off using the Boost Software License. Switching costs nothing (I'm making a big assumption here that there are not already a bunch of contributors who submitted code under the MIT License, so apologies if that is not correct) and the potential benefits are greater than zero.

from open-gpu-kernel-modules.

why not just say you used nvidia code???

from open-gpu-kernel-modules.

why not just say you used nvidia code???

https://pdimov.github.io/blog/2020/09/06/why-use-the-boost-license/

Doesn't really answer the question of why you can't simply include the attribution.

from open-gpu-kernel-modules.

this code is for a Linux kernel module, it has to be GPL/MIT, why would you be reusing it somewhere else?

from open-gpu-kernel-modules.

Good thing this is not C++ nor a library then.

Yep, Peter's blog post is specified to C++ but the BSL is applicable to any software (and better than the MIT license). Going with the BSL allows it to be used in more contexts, so if the goal is to make the source code as widely available as possible (which, I am assuming it is) - then BSL is better.

from open-gpu-kernel-modules.

this code is for a Linux kernel module, it has to be GPL/MIT, why would you be reusing it somewhere else?

The BSL is more permissive. And the reason for nVIDIA to use the BSL is to use its prominence as a large company to promote the more permissive license, and raise awareness of it.

from open-gpu-kernel-modules.

That isn't the goal. The goal is to have software that is a driver for the Linux kernel. That license isn't going to work for that. This isn't a library you are going to reuse in userspace. I think you are confused on what this project actually is.

from open-gpu-kernel-modules.

because that would obligate anyone who compiles the standard library into their executable to show attribution in the binary

And why is that an issue? Especially here, this is primarily intended for use in the Linux kernel which is GPL licensed.
Not to mention that Microsoft uses MIT licensed code and this has yet to be an issue for them.

from open-gpu-kernel-modules.

@vinniefalco these organizations need to get their shit together then.

from open-gpu-kernel-modules.

Not all organizations can put attributions in binaries, for various reasons.

Such as? I'm genuinely curious as to when such circumstances arise. I can't think of any

from open-gpu-kernel-modules.

That's an interesting question.

Where do you put the required MIT attribution in a kernel module?
Do you print it to the kernel log?
For each module separately if multiple are loaded?
Or does it suffice to put it in the module description that modinfo would show?

The main argument against these clauses that require attribution in some specific form is that the attribution list grows ad absurdum over time as number of contributors grows and you are not legally allowed to move it somewhere where it is reasonably available to the user but does not get in the way.

Arguably requiring attribution in binaries may become unwieldy over time because there isn't always a convenient place to stuff really long list of attributions.

On the other hand, with carefully worded contributor agreement and tight control over what code gets into the project you may be able to avoid the attribution explosion problem.

Using a license that prevents it entirely might be preferable to some but it is more important for some projects than others.

from open-gpu-kernel-modules.

requiring attribution in binaries

MIT does not require that, and almost no one is doing that, including copyright holders (authors). A copy of a software can contain more than one files. You just need to put the licence text in a separate file when you distribute it.

from open-gpu-kernel-modules.

Is it OK to build a ramdisk that contains the nVidia module then, and put it on an installation medium?

That medium may not have the full copy of the binary distribution of the driver, mind you.

from open-gpu-kernel-modules.

You can place the licence text in the installation medium alongside the ramdisk image.

from open-gpu-kernel-modules.

But then you have to go out of your way to examine the license of the modules needed for a particular system, find that it requires that the license text be placed on the medium, fish it from somewhere when building the medium, and place it there.

Not that it's not doable but avoiding such minefield would be preferable.

from open-gpu-kernel-modules.

fish it from somewhere when building the medium, and place it there

That's the feature, not a bug! If the author licences something under MIT then you should assume they want to be attributed. They want you to put their name in your medium.

from open-gpu-kernel-modules.

There is a distinction between 'accompany it' as required by GPL for sources and 'included in all copies or substantial portions' as required for the MIT notices.

from open-gpu-kernel-modules.

You can argue over the wording of a licence for as long as you have money to pay lawyers. Nonetheless, the reality is that all of the richest tech companies employing the most expensive lawyers regularly use MIT-licenced dependencies without embedding the licence in their binary distributions, nor do they embed the licence in binaries of their own software. I really don't think anyone can win in court against you for having the licence placed alongside the binary.

from open-gpu-kernel-modules.

Where are the court cases or at least legal analyses supporting your claim?

from open-gpu-kernel-modules.

Microsoft for example cannot use MIT licensed code as part of its standard library (because that would obligate anyone who compiles the standard library into their executable to show attribution in the binary).

That's valid for standard libraries and I would maybe even consider this argument valid for libc implementations.
But this is not a valid argument for this project, I can't imagine any scenario where it would be moral to use Nvidia code and not attribute anyone. The Nvidia driver is not a STL, so your point does not apply here (noone will compile the Nvidia driver into their own binary).

Also your blog post is an absolute shit tier take, the only morally correct thing would be to license everything with GPL /s 🤡

from open-gpu-kernel-modules.

Thank you for your interest in this driver. The license will remain as stated in COPYING for now.

from open-gpu-kernel-modules.