Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sponsorship, signed driver and license ideas and challenges #105

Closed
nefarius opened this issue Feb 7, 2025 · 1 comment
Closed

Sponsorship, signed driver and license ideas and challenges #105

nefarius opened this issue Feb 7, 2025 · 1 comment

Comments

@nefarius
Copy link

nefarius commented Feb 7, 2025

@vadimgrn If you think this topic should be a discussion, feel free to migrate it!

Hello there!

After lurking and following this project with great interest I have a few questions, suggestions and recommendations regarding the topics mentioned in the issue title.

Signed driver

regarding #13

Let's start with the most juicy one first: my company (and potentially a partner) would be willing to dance the "Microsoft Partner Portal Submission and Driver Attestation Signing" dance for the Windows kernel components of the solution, meaning making a production-signed copy available that would support Windows 10/11 x64/AMD64 with or without SecureBoot enabled. I see a lot of potential and use-cases in this project and among the forks out there appears to be the most well-maintained and thought-through.

However, next to the topics that are in the way of this adventure.

Use of the GPL-3 license

From my understanding by browsing the projects, the entire repository and all sub-components (Windows/Linux userland libraries, Windows device driver(s)) follow the GPL-3. This is problematic for a multitude of reasons.

Incompatibility with the Windows Driver Ecosystem

Windows device drivers are technically incompatible with the GPL (2 and 3) since their strong copyleft restrictions would demand, that components of the Windows kernel that have to be linked against are available to the public as well. This is an unavoidable and unsolvable conflict, since no matter which device driver architecture you build your driver with (WDM, KMDF, UDE, ...) you have to link against the closed-source DDIs or your binary would basically be non-functioning.

Unfortunately this is not really well-known and the closest public statement to demonstrate this is found in the last paragraph of virtio-win/kvm-guest-drivers-windows. This means that Microsoft even actively rejects WHQL submissions of GPL'ed drivers.

To my knowledge, the attestation signing procedure is blind to this flaw, but just because it works doesn't mean it is correct 😬

Now, for the hobbyist and private individual this may seem like boring nit-picky details, and nobody may ever raise an eyebrow and turn it into problem, but that is unfortunately not what company lawyers like to hear 😅 ("No plaintiff, no judge.").

I ran into this with my own FOSS driver a long time ago too, I since settled on the 3-Clause BSD License although Apache 2 and MPL are a compatible choice too.

Incentive for contributions constrained

The GPL tries its best to turn users of free work into contributors so the balance between those creating and those merely taking without giving back is more or less maintained.

Imagine the following (fairly common) scenario now: a company would love to build upon this project and is willing to contribute back code whenever there's a need for change (bug fixes as a prime example). Their core app/product is designed as proprietary/closed-source and they simply interface via e.g. the provided libusbip with the driver. The GPL would now demand that - even if we link dynamically, not even static - the product interfacing the (unmodified and publicly available) would need to be open-source too. This is in many (most?) cases neither possible nor desired and would also ultimately not benefit this project, since it forces opening up code that isn't really relevant or beneficial to the project.

This will immediately drive away any potential contributor that aims for integrating into non-FOSS applications, we now have no winner in this scenario; the contributor may be willing to join forces with the project and provide enhancements, but in return can not even use it themselves? Everyone lost.

Ideas and potential solutions

As you can see, we orbit around the chosen license doing more harm than good, for hobbyists and corporate entities alike. Now not all is lost though, there are multiple ways forward, although none are entirely without obstacles.

Re-license under more compatible license(s)

Someone feel free to correct me but as far as my research got me, there is no way to rectify the shortcomings laid out above without a license change. This is unfortunately not done in one afternoon, the following points need to be covered/resolved:

  • a CLA (Contributor License Agreement) was not used, therefore all past contributors, not just the current core maintainer, would need to be contacted to agree to a change since parts of their work have been added without them "signing away" the copyright of their work (however tiny it may have been). Contributions from authors that do not respond or deny the license change would need to be removed or rewritten.
  • A suitable new license that both covers the WHQL restrictions and the needs and visions of the maintainers needs to be chose. The non-kernel components could make use of either the same new license or a different one, that doesn't force copyleft to bleed over into proprietary apps. Suggestions:
    • Driver components: BSD-3-Clause, Apache 2, MPL 2 (technically even GPL-2, but...)
    • Other userland components: Lesser GPL variants or more permissive like MIT, BSD, etc.

Offer a dual-license model for commercial projects

It is quite common to dual-license to allow commercial use under a separate commercial license. This is only possible if the licencor owns the majority of the code, since without a CLA one single person couldn't just make this decision for all other contributors.

If both of the above fail, only a rewrite from scratch of the affected components under a more permissive license would be an alternative.

A quick git-fame run shows we would have to get at least the top 4 contributors into this discussion:

Total commits: 1681
Total ctimes: 16445
Total files: 310
Total loc: 85864
| Author                 |   loc |   coms |   fils |  distribution   |
|:-----------------------|------:|-------:|-------:|:----------------|
| Vadym Hrynchyshyn      | 58646 |    921 |    242 | 68.3/54.8/78.1  |
| KyungWoon Cho          | 13888 |    228 |     21 | 16.2/13.6/ 6.8  |
| cpeacock               | 12054 |     11 |      2 | 14.0/ 0.7/ 0.6  |
| vadimgrn               |  1193 |    397 |     26 | 1.4/23.6/ 8.4   |
| arjanmels              |    25 |      4 |      1 | 0.0/ 0.2/ 0.3   |
| matt mooney            |    24 |     12 |      6 | 0.0/ 0.7/ 1.9   |
| George Hopkins         |    11 |     12 |      1 | 0.0/ 0.7/ 0.3   |
| Nathan Raggett         |     7 |      1 |      3 | 0.0/ 0.1/ 1.0   |
| Vadym                  |     4 |      9 |      2 | 0.0/ 0.5/ 0.6   |
| Jan Kubalek            |     4 |      8 |      2 | 0.0/ 0.5/ 0.6   |
| Alexandre Demers       |     4 |     16 |      2 | 0.0/ 1.0/ 0.6   |
| Brandon Ros            |     2 |      4 |      1 | 0.0/ 0.2/ 0.3   |
| lepton-wu              |     2 |     24 |      1 | 0.0/ 1.4/ 0.3   |
| Bartlomiej Cieszkowski |     0 |      2 |      0 | 0.0/ 0.1/ 0.0   |
| Bartłomiej Cieszkowski |     0 |      2 |      0 | 0.0/ 0.1/ 0.0   |
| Daniel Mitchell        |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| Dejan Milic            |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| Marc Capdevielle       |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| Martin Drab            |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| Paul Peavyhouse        |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| Peter Dons Tychsen     |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| Rex Han                |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| Richard Pasek          |     0 |      3 |      0 | 0.0/ 0.2/ 0.0   |
| Samo Pogačnik          |     0 |     10 |      0 | 0.0/ 0.6/ 0.0   |
| SiLeader               |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| StoyanDimitrov         |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| Sven Luebke            |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| Wqrld                  |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| chenfayu               |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| rgsilva                |     0 |      2 |      0 | 0.0/ 0.1/ 0.0   |
| rogermiranda1000       |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| svirot                 |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |
| 謝致邦 (XIE Zhibang)    |     0 |      1 |      0 | 0.0/ 0.1/ 0.0   |

Prologue

Man, that was a lot, sorry in advance 😅 What do you fine folks think?

Cheers

@vadimgrn
Copy link
Owner

vadimgrn commented Feb 8, 2025

Hello, thank you for your interest in my project.

  • About legacy and authors/commits. This information is irrelevant. The repo was indeed cloned from https://github.com/cezanne/usbip-win. But there is no legacy code left. WDM driver was ditched. These projects were written from scratch: usbip2-ude and usbip2-filter drivers, resources, libusbip, usbip and devnode utilities, GUI, installer. libdrv was completely overhauled, its name is the only legacy. If you find inherited code somewhere, it must be libdrv only. In such case I will rewrite it. Use 'git blame' for real information and don't use number of commits to reveal authors.
  • I don't mind to change the license for the project, absolutely. But how can I do that? Is it legal to change the license by simply replacing it to a less restrictive one? I am not sure about that. Why smartphones manufacturers must release modified versions of Linux kernels if they can just clone a kernel and change its license. They can't do that, neither can I.

Repository owner locked and limited conversation to collaborators Feb 8, 2025
@vadimgrn vadimgrn converted this issue into discussion #106 Feb 8, 2025

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants