You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@vadimgrnIf 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.
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:
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:
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
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
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.
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:
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:Prologue
Man, that was a lot, sorry in advance 😅 What do you fine folks think?
Cheers
The text was updated successfully, but these errors were encountered: