| Message ID | 20241114103133.547032-4-ukleinek@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | module: Block modules by Tuxedo from accessing GPL symbols | expand |
Hello, Am 14.11.24 um 11:31 schrieb Uwe Kleine-König: > Hello, > > the kernel modules provided by Tuxedo on > https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers > are licensed under GPLv3 or later. This is incompatible with the > kernel's license and so makes it impossible for distributions and other > third parties to support these at least in pre-compiled form and so > limits user experience and the possibilities to work on mainlining these > drivers. > > This incompatibility is created on purpose to control the upstream > process. See https://fosstodon.org/@kernellogger/113423314337991594 for > a nice summary of the situation and some further links about the issue. > > Note that the pull request that fixed the MODULE_LICENSE invocations to > stop claiming GPL(v2) compatibility was accepted and then immediately > reverted "for the time being until the legal stuff is sorted out" > (https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427). As already being implied by that commit message, this is sadly not an issue that can be sorted out over night. We ended up in this situation as MODULE_LICENSE("GPL") on its own does not hint at GPL v2, if one is not aware of the license definition table in the documentation. It was and is never our intention to violate neither GPL v2 nor GPL v3 and we are working on it. Kind regards, Werner Sembach > > Best regards > Uwe > > Uwe Kleine-König (2): > module: Put known GPL offenders in an array > module: Block modules by Tuxedo from accessing GPL symbols > > kernel/module/main.c | 56 +++++++++++++++++++++++++++++++++++++------- > 1 file changed, 47 insertions(+), 9 deletions(-) > > base-commit: 28955f4fa2823e39f1ecfb3a37a364563527afbc
Hello, On 11/14/24 11:49, Werner Sembach wrote: > Am 14.11.24 um 11:31 schrieb Uwe Kleine-König: >> the kernel modules provided by Tuxedo on >> https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers >> are licensed under GPLv3 or later. This is incompatible with the >> kernel's license and so makes it impossible for distributions and other >> third parties to support these at least in pre-compiled form and so >> limits user experience and the possibilities to work on mainlining these >> drivers. >> >> This incompatibility is created on purpose to control the upstream >> process. See https://fosstodon.org/@kernellogger/113423314337991594 for >> a nice summary of the situation and some further links about the issue. >> >> Note that the pull request that fixed the MODULE_LICENSE invocations to >> stop claiming GPL(v2) compatibility was accepted and then immediately >> reverted "for the time being until the legal stuff is sorted out" >> (https://gitlab.com/tuxedocomputers/development/packages/tuxedo- >> drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427). > > As already being implied by that commit message, this is sadly not an > issue that can be sorted out over night. > > We ended up in this situation as MODULE_LICENSE("GPL") on its own does > not hint at GPL v2, if one is not aware of the license definition table > in the documentation. That statement isn't consistent with you saying to pick GPLv3 as an explicitly incompatible license to control the mainlining process. So you knew that it's legally at least questionable to combine these licenses. The only thing I could accept here is that you were surprised that the incompatibility has some technical enforcement resulting in your modules to become nonfunctional. But that's like a thieve in a supermarket who asks for forgiveness because while he was aware that steeling is not allowed, wasn't aware there is video surveillance that might actually catch him. So I'd claim MODULE_LICENSE("GPL") not being explicit to not apply for GPLv3 code is not a valid excuse. (Which doesn't mean the kernel couldn't improve here.) Best regards Uwe
Hello, Am 14.11.24 um 12:14 schrieb Uwe Kleine-König: > Hello, > > On 11/14/24 11:49, Werner Sembach wrote: >> Am 14.11.24 um 11:31 schrieb Uwe Kleine-König: >>> the kernel modules provided by Tuxedo on >>> https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers >>> are licensed under GPLv3 or later. This is incompatible with the >>> kernel's license and so makes it impossible for distributions and other >>> third parties to support these at least in pre-compiled form and so >>> limits user experience and the possibilities to work on mainlining these >>> drivers. >>> >>> This incompatibility is created on purpose to control the upstream >>> process. See https://fosstodon.org/@kernellogger/113423314337991594 for >>> a nice summary of the situation and some further links about the issue. >>> >>> Note that the pull request that fixed the MODULE_LICENSE invocations to >>> stop claiming GPL(v2) compatibility was accepted and then immediately >>> reverted "for the time being until the legal stuff is sorted out" >>> (https://gitlab.com/tuxedocomputers/development/packages/tuxedo- >>> drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427). >> >> As already being implied by that commit message, this is sadly not an issue >> that can be sorted out over night. >> >> We ended up in this situation as MODULE_LICENSE("GPL") on its own does not >> hint at GPL v2, if one is not aware of the license definition table in the >> documentation. > > That statement isn't consistent with you saying to pick GPLv3 as an explicitly > incompatible license to control the mainlining process. So you knew that it's > legally at least questionable to combine these licenses. Put in the time-dimension and you can figure out where this isn't inconsistent. > > The only thing I could accept here is that you were surprised that the > incompatibility has some technical enforcement resulting in your modules to > become nonfunctional. But that's like a thieve in a supermarket who asks for > forgiveness because while he was aware that steeling is not allowed, wasn't > aware there is video surveillance that might actually catch him. > > So I'd claim MODULE_LICENSE("GPL") not being explicit to not apply for GPLv3 > code is not a valid excuse. (Which doesn't mean the kernel couldn't improve > here.) I can not tell anything else than I wrote above so I probably can't gain your trust that it was an honest mistake. Thing is we are working on rewriting the driver bit by bit directly for upstream under GPL v2, e.g. https://lore.kernel.org/all/20241001180658.76396-2-wse@tuxedocomputers.com/ And we don't stop anyone else from doing so and actively involve ourself in the process, giving advice where we can from our experience with the devices, e.g. https://github.com/Wer-Wolf/uniwill-laptop/issues/1 And tuxedo-drivers got code in the past from external contributors under GPL v3 that also weren't aware of the correct definition of MODULE_LICENSE("GPL") which needs to be sorted out. And no tuxedo-drivers module would get accepted upstream as is at the moment, because the focus of the driver package is mainly to get support for new devices out as quickly as possible, while upstream rightfully has way stricter guidelines on code quality (not implying that tuxedo-drivers has bad code quality, it's a spectrum after all). What I want to say: If the end goal is upstream support for our devices nothing is speed up by the relicensing, arguably it's slowed down because someone now has to sort out legal stuff. If you want to take on the actual coding work yourself, please do so, I will give you advice as I did with Armins uniwill laptop driver and several times on the mailing list. Kind regards, Werner Sembach > > Best regards > Uwe
On Thu Nov 14, 2024 at 11:31 AM CET, Uwe Kleine-König wrote: > Hello, > > the kernel modules provided by Tuxedo on > https://protect2.fireeye.com/v1/url?k=2f239e82-70bfb7a8-2f2215cd-000babe598f7-32952349600b722d&q=1&e=9535a8fa-5a9d-4d94-a12d-ff39b9d3b9cf&u=https%3A%2F%2Fgitlab.com%2Ftuxedocomputers%2Fdevelopment%2Fpackages%2Ftuxedo-drivers > are licensed under GPLv3 or later. This is incompatible with the > kernel's license and so makes it impossible for distributions and other > third parties to support these at least in pre-compiled form and so > limits user experience and the possibilities to work on mainlining these > drivers. > > This incompatibility is created on purpose to control the upstream > process. See https://protect2.fireeye.com/v1/url?k=12fa0a06-4d66232c-12fb8149-000babe598f7-5be6d19feac11441&q=1&e=9535a8fa-5a9d-4d94-a12d-ff39b9d3b9cf&u=https%3A%2F%2Ffosstodon.org%2F%40kernellogger%2F113423314337991594 for > a nice summary of the situation and some further links about the issue. > > Note that the pull request that fixed the MODULE_LICENSE invocations to > stop claiming GPL(v2) compatibility was accepted and then immediately > reverted "for the time being until the legal stuff is sorted out" > (https://protect2.fireeye.com/v1/url?k=80a9845b-df35ad71-80a80f14-000babe598f7-b5ddbbaedbccb553&q=1&e=9535a8fa-5a9d-4d94-a12d-ff39b9d3b9cf&u=https%3A%2F%2Fgitlab.com%2Ftuxedocomputers%2Fdevelopment%2Fpackages%2Ftuxedo-drivers%2F-%2Fcommit%2Fa8c09b6c2ce6393fe39d8652d133af9f06cfb427). This commit did not remove the license boilerplate as this other one [1] upstream did. So I think the license was still inconsistent. [1] 1a59d1b8e05ea6ab45f7e18897de1ef0e6bc3da6 ("treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 15"). > > Best regards > Uwe > > Uwe Kleine-König (2): > module: Put known GPL offenders in an array > module: Block modules by Tuxedo from accessing GPL symbols > > kernel/module/main.c | 56 +++++++++++++++++++++++++++++++++++++------- > 1 file changed, 47 insertions(+), 9 deletions(-) > > base-commit: 28955f4fa2823e39f1ecfb3a37a364563527afbc
On Thu, Nov 14, 2024 at 11:49:04AM +0100, Werner Sembach wrote: > Hello, > > Am 14.11.24 um 11:31 schrieb Uwe Kleine-König: > > Hello, > > > > the kernel modules provided by Tuxedo on > > https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers > > are licensed under GPLv3 or later. This is incompatible with the > > kernel's license and so makes it impossible for distributions and other > > third parties to support these at least in pre-compiled form and so > > limits user experience and the possibilities to work on mainlining these > > drivers. > > > > This incompatibility is created on purpose to control the upstream > > process. See https://fosstodon.org/@kernellogger/113423314337991594 for > > a nice summary of the situation and some further links about the issue. > > > > Note that the pull request that fixed the MODULE_LICENSE invocations to > > stop claiming GPL(v2) compatibility was accepted and then immediately > > reverted "for the time being until the legal stuff is sorted out" > > (https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427). > > As already being implied by that commit message, this is sadly not an issue > that can be sorted out over night. > > We ended up in this situation as MODULE_LICENSE("GPL") on its own does not > hint at GPL v2, if one is not aware of the license definition table in the > documentation. That's why it is documented, to explain this very thing. Please don't suggest that documenting this is somehow not providing a hint. That's just not going to fly with any lawyer who reads any of this, sorry. greg k-h
Hi, Am 15.11.24 um 05:43 schrieb Greg KH: > On Thu, Nov 14, 2024 at 11:49:04AM +0100, Werner Sembach wrote: >> Hello, >> >> Am 14.11.24 um 11:31 schrieb Uwe Kleine-König: >>> Hello, >>> >>> the kernel modules provided by Tuxedo on >>> https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers >>> are licensed under GPLv3 or later. This is incompatible with the >>> kernel's license and so makes it impossible for distributions and other >>> third parties to support these at least in pre-compiled form and so >>> limits user experience and the possibilities to work on mainlining these >>> drivers. >>> >>> This incompatibility is created on purpose to control the upstream >>> process. Seehttps://fosstodon.org/@kernellogger/113423314337991594 for >>> a nice summary of the situation and some further links about the issue. >>> >>> Note that the pull request that fixed the MODULE_LICENSE invocations to >>> stop claiming GPL(v2) compatibility was accepted and then immediately >>> reverted "for the time being until the legal stuff is sorted out" >>> (https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427). >> As already being implied by that commit message, this is sadly not an issue >> that can be sorted out over night. >> >> We ended up in this situation as MODULE_LICENSE("GPL") on its own does not >> hint at GPL v2, if one is not aware of the license definition table in the >> documentation. > That's why it is documented, to explain this very thing. Please don't > suggest that documenting this is somehow not providing a hint. That's > just not going to fly with any lawyer who reads any of this, sorry. You are right, that's why when I became aware of the situation this Monday https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/9db67459510f18084694c597ff1ea57ef1842f4e I got the gears to resolve this into moving (me playing devils advocate here is directly related to this https://lore.kernel.org/all/17276996-dcca-4ab5-a64f-0e76514c5dc7@tuxedocomputers.com/) and then returned on working on the code rewrite for upstream ( https://lore.kernel.org/all/8847423c-22ec-4775-9119-de3e0ddb5204@tuxedocomputers.com/ is directly related to that), because I'm a developer not a lawyer. Then I get called a liar and hit with the nuclear option not even full 3 days later, while I'm working on resolving the issue and in parallel working on improving the code for it to be actually accepted by upstream. If you want prove of my blissful ignorance from just last week please take a look at my comment here: https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/merge_requests/21#note_2201702758 Now trying to be constructive: Can you give me a timeframe to resolve the license issue before this is merged? Kind regards, Werner Sembach > greg k-h
On Fri, Nov 15, 2024 at 07:09:49AM +0100, Werner Sembach wrote: > Hi, > > Am 15.11.24 um 05:43 schrieb Greg KH: > > On Thu, Nov 14, 2024 at 11:49:04AM +0100, Werner Sembach wrote: > > > Hello, > > > > > > Am 14.11.24 um 11:31 schrieb Uwe Kleine-König: > > > > Hello, > > > > > > > > the kernel modules provided by Tuxedo on > > > > https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers > > > > are licensed under GPLv3 or later. This is incompatible with the > > > > kernel's license and so makes it impossible for distributions and other > > > > third parties to support these at least in pre-compiled form and so > > > > limits user experience and the possibilities to work on mainlining these > > > > drivers. > > > > > > > > This incompatibility is created on purpose to control the upstream > > > > process. Seehttps://fosstodon.org/@kernellogger/113423314337991594 for > > > > a nice summary of the situation and some further links about the issue. > > > > > > > > Note that the pull request that fixed the MODULE_LICENSE invocations to > > > > stop claiming GPL(v2) compatibility was accepted and then immediately > > > > reverted "for the time being until the legal stuff is sorted out" > > > > (https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427). > > > As already being implied by that commit message, this is sadly not an issue > > > that can be sorted out over night. > > > > > > We ended up in this situation as MODULE_LICENSE("GPL") on its own does not > > > hint at GPL v2, if one is not aware of the license definition table in the > > > documentation. > > That's why it is documented, to explain this very thing. Please don't > > suggest that documenting this is somehow not providing a hint. That's > > just not going to fly with any lawyer who reads any of this, sorry. > > You are right, that's why when I became aware of the situation this Monday https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/9db67459510f18084694c597ff1ea57ef1842f4e > I got the gears to resolve this into moving (me playing devils advocate here > is directly related to this https://lore.kernel.org/all/17276996-dcca-4ab5-a64f-0e76514c5dc7@tuxedocomputers.com/) > and then returned on working on the code rewrite for upstream ( https://lore.kernel.org/all/8847423c-22ec-4775-9119-de3e0ddb5204@tuxedocomputers.com/ > is directly related to that), because I'm a developer not a lawyer. I would strongly suggest you work with your lawyers now as they are the ones that need to resolve this properly. thanks, greg k-h
Hello Werner, On Fri, Nov 15, 2024 at 07:09:49AM +0100, Werner Sembach wrote: > Am 15.11.24 um 05:43 schrieb Greg KH: > > On Thu, Nov 14, 2024 at 11:49:04AM +0100, Werner Sembach wrote: > > > Am 14.11.24 um 11:31 schrieb Uwe Kleine-König: > > > > the kernel modules provided by Tuxedo on > > > > https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers > > > > are licensed under GPLv3 or later. This is incompatible with the > > > > kernel's license and so makes it impossible for distributions and other > > > > third parties to support these at least in pre-compiled form and so > > > > limits user experience and the possibilities to work on mainlining these > > > > drivers. > > > > > > > > This incompatibility is created on purpose to control the upstream > > > > process. Seehttps://fosstodon.org/@kernellogger/113423314337991594 for > > > > a nice summary of the situation and some further links about the issue. > > > > > > > > Note that the pull request that fixed the MODULE_LICENSE invocations to > > > > stop claiming GPL(v2) compatibility was accepted and then immediately > > > > reverted "for the time being until the legal stuff is sorted out" > > > > (https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427). > > > As already being implied by that commit message, this is sadly not an issue > > > that can be sorted out over night. > > > > > > We ended up in this situation as MODULE_LICENSE("GPL") on its own does not > > > hint at GPL v2, if one is not aware of the license definition table in the > > > documentation. > > That's why it is documented, to explain this very thing. Please don't > > suggest that documenting this is somehow not providing a hint. That's > > just not going to fly with any lawyer who reads any of this, sorry. > > You are right, that's why when I became aware of the situation this Monday https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/9db67459510f18084694c597ff1ea57ef1842f4e We should differentiate two situations here: The one is from Monday when you realised that a non-GPL2 compatible kernel module is unable to use many functions. The other (and IMHO more relevant) is when GPLv3 was chosen knowing it's incompatible with the kernel's license. I would argue that you were aware of that since at least March this year (https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/issues/137#note_1807179414). And in my opinion https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427 was a wrong reaction. I received this as a statement that your company's goals are important enough to not adhere to the kernel's license and the open source spirit. This was what triggered me to create the patch under discussion. > I got the gears to resolve this into moving (me playing devils advocate here > is directly related to this https://lore.kernel.org/all/17276996-dcca-4ab5-a64f-0e76514c5dc7@tuxedocomputers.com/) > and then returned on working on the code rewrite for upstream ( https://lore.kernel.org/all/8847423c-22ec-4775-9119-de3e0ddb5204@tuxedocomputers.com/ > is directly related to that), because I'm a developer not a lawyer. I agree that it's unlucky that MODULE_LICENSE("GPL") doesn't apply for GPLv3. Not sure if it's sensible to deprecate "GPL" and mandate "GPL v2" though. > Then I get called a liar I guess you mean me here saying "That statement isn't consistent with you saying to pick GPLv3 as an explicitly incompatible license to control the mainlining process. So you knew that it's legally at least questionable to combine these licenses."? If so: I understand that this is discomfortable suggestion. However with my current understanding it's true. If this is a problem with my understanding, please point out where I'm wrong. > and hit with the nuclear option not even full 3 days later, For now we're in the discussion period for this "option". I would expect that this patch doesn't go in before 6.12. So 6.13-rc1 should be the earliest broken ("enforcing") kernel which probably starts to affect your users starting with 6.13 final. The actual decision if and when to apply this patch isn't mine though. But you should have at least a few weeks to work on resolving the licensing. > while I'm working on resolving the issue This is good. You have my support to revert the patch under discussion as soon as this is resolved. > and in parallel working on improving the code for it to be actually > accepted by upstream. > > If you want prove of my blissful ignorance from just last week please take a > look at my comment here: https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/merge_requests/21#note_2201702758 I indeed wondered about your reaction. > Now trying to be constructive: Can you give me a timeframe to resolve the > license issue before this is merged? I would wish that in people's mind open source licensing would be taken as serious as for example fiscal laws. If my company was caught as tax evader the officials would rather shut down the company's operation than to allow another month with unclean bookkeeping. So if you ask for my opinion, the right thing to do would be to stop distributing tuxedo-drivers until this is resolved. Then I'd guess it's your company's officials who would tell you about a time frame. But I'm aware that I'm on the strong side of the spectrum of possibilities here. Best regards Uwe
Hello Uwe, Am 15.11.24 um 08:29 schrieb Uwe Kleine-König: > Hello Werner, > > On Fri, Nov 15, 2024 at 07:09:49AM +0100, Werner Sembach wrote: >> Am 15.11.24 um 05:43 schrieb Greg KH: >>> On Thu, Nov 14, 2024 at 11:49:04AM +0100, Werner Sembach wrote: >>>> Am 14.11.24 um 11:31 schrieb Uwe Kleine-König: >>>>> the kernel modules provided by Tuxedo on >>>>> https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers >>>>> are licensed under GPLv3 or later. This is incompatible with the >>>>> kernel's license and so makes it impossible for distributions and other >>>>> third parties to support these at least in pre-compiled form and so >>>>> limits user experience and the possibilities to work on mainlining these >>>>> drivers. >>>>> >>>>> This incompatibility is created on purpose to control the upstream >>>>> process. Seehttps://fosstodon.org/@kernellogger/113423314337991594 for >>>>> a nice summary of the situation and some further links about the issue. >>>>> >>>>> Note that the pull request that fixed the MODULE_LICENSE invocations to >>>>> stop claiming GPL(v2) compatibility was accepted and then immediately >>>>> reverted "for the time being until the legal stuff is sorted out" >>>>> (https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427). >>>> As already being implied by that commit message, this is sadly not an issue >>>> that can be sorted out over night. >>>> >>>> We ended up in this situation as MODULE_LICENSE("GPL") on its own does not >>>> hint at GPL v2, if one is not aware of the license definition table in the >>>> documentation. >>> That's why it is documented, to explain this very thing. Please don't >>> suggest that documenting this is somehow not providing a hint. That's >>> just not going to fly with any lawyer who reads any of this, sorry. >> You are right, that's why when I became aware of the situation this Monday https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/9db67459510f18084694c597ff1ea57ef1842f4e > We should differentiate two situations here: The one is from Monday > when you realised that a non-GPL2 compatible kernel module is unable to > use many functions. The other (and IMHO more relevant) is when GPLv3 was > chosen knowing it's incompatible with the kernel's license. I would > argue that you were aware of that since at least March this year > (https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/issues/137#note_1807179414). Yes I was aware of this for in-tree modules, I was not aware of this for out of tree modules: https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/issues/137#note_2066858305 Sadly I did not get corrected on my mistake back then, otherwise I would have started then to get things moving and not only last Monday. > > And in my opinion > https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427 > was a wrong reaction. I received this as a statement that your company's > goals are important enough to not adhere to the kernel's license and the > open source spirit. This was what triggered me to create the patch under > discussion. The revert was done not to block the release of the fan control for the Sirius, and as already mentioned in the commit: It is a temporary action. I hoped to gain more time. TBH I feel a little bit of regret doing this experimentation in public now, as I would have had probably more time if i didn't (no offense). > >> I got the gears to resolve this into moving (me playing devils advocate here >> is directly related to this https://lore.kernel.org/all/17276996-dcca-4ab5-a64f-0e76514c5dc7@tuxedocomputers.com/) >> and then returned on working on the code rewrite for upstream ( https://lore.kernel.org/all/8847423c-22ec-4775-9119-de3e0ddb5204@tuxedocomputers.com/ >> is directly related to that), because I'm a developer not a lawyer. > I agree that it's unlucky that MODULE_LICENSE("GPL") doesn't apply for > GPLv3. Not sure if it's sensible to deprecate "GPL" and mandate "GPL v2" > though. > >> Then I get called a liar > I guess you mean me here saying "That statement isn't consistent with > you saying to pick GPLv3 as an explicitly incompatible license to > control the mainlining process. So you knew that it's legally at least > questionable to combine these licenses."? If so: I understand that this > is discomfortable suggestion. However with my current understanding it's > true. If this is a problem with my understanding, please point out where > I'm wrong. It's about that second sentence "So you knew that it's legally [...]" which I explicitly stated that I was not e.g. https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/issues/137#note_2066858305 from back in august. > >> and hit with the nuclear option not even full 3 days later, > For now we're in the discussion period for this "option". I would expect > that this patch doesn't go in before 6.12. So 6.13-rc1 should be the > earliest broken ("enforcing") kernel which probably starts to affect > your users starting with 6.13 final. The actual decision if and when to > apply this patch isn't mine though. But you should have at least a few > weeks to work on resolving the licensing. Knowing the issue tracker too well, I know that day one of 6.13-rc1 release a discussion will might break loose that binds resources not invested in other stuff. Also can you guarantee that it's not landing in 6.12(.0)? That's why I asked for a clear timeframe to work with but I don't know if I can get one. > >> while I'm working on resolving the issue > This is good. You have my support to revert the patch under discussion > as soon as this is resolved. > >> and in parallel working on improving the code for it to be actually >> accepted by upstream. >> >> If you want prove of my blissful ignorance from just last week please take a >> look at my comment here: https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/merge_requests/21#note_2201702758 > I indeed wondered about your reaction. > >> Now trying to be constructive: Can you give me a timeframe to resolve the >> license issue before this is merged? > I would wish that in people's mind open source licensing would be taken > as serious as for example fiscal laws. If my company was caught as tax > evader the officials would rather shut down the company's operation than > to allow another month with unclean bookkeeping. > > So if you ask for my opinion, the right thing to do would be to stop > distributing tuxedo-drivers until this is resolved. Then I'd guess it's > your company's officials who would tell you about a time frame. But I'm > aware that I'm on the strong side of the spectrum of possibilities here. This would break linux installations on many devices and not only fall back on TUXEDO I honestly fear. I was not around when the decision to license tuxedo-drivers (back then called tuxedo-cc-wmi) under GPL v3 was made, but I trust the people here that is was not done knowingly violating the GPL v2. And you did agree above that MODULE_LICENSE("GPL") is somewhat unluckily named. I guess what I try to convince you and others is that we _are_ taking Open Source licenses seriously, but still there are mistakes to be made, especially with complex projects like the Linux kernel, e.g. I'm not aware of any other project that uses a similar construct to EXPORT_SYMBOL_GPL()/MODULE_LICENSE(). Best regards, Werner Sembach > > Best regards > Uwe
On Fri, Nov 15, 2024 at 10:00:23AM +0100, Werner Sembach wrote: > I guess what I try to convince you and others is that we _are_ taking Open > Source licenses seriously, but still there are mistakes to be made, > especially with complex projects like the Linux kernel, e.g. I'm not aware > of any other project that uses a similar construct to > EXPORT_SYMBOL_GPL()/MODULE_LICENSE(). The Linux kernel is very simple from a license point of view, your code has to be GPLv2 compatible. That's it, nothing complex or odd about that at all. thanks, greg k-h
Am 15.11.24 um 10:18 schrieb Greg KH: > On Fri, Nov 15, 2024 at 10:00:23AM +0100, Werner Sembach wrote: >> I guess what I try to convince you and others is that we _are_ taking Open >> Source licenses seriously, but still there are mistakes to be made, >> especially with complex projects like the Linux kernel, e.g. I'm not aware >> of any other project that uses a similar construct to >> EXPORT_SYMBOL_GPL()/MODULE_LICENSE(). > The Linux kernel is very simple from a license point of view, your code > has to be GPLv2 compatible. That's it, nothing complex or odd about > that at all. Then why does the proprietary NVIDIA driver exist? > > thanks, > > greg k-h
On Fri, Nov 15, 2024 at 10:40:56AM +0100, Werner Sembach wrote: > > Am 15.11.24 um 10:18 schrieb Greg KH: > > On Fri, Nov 15, 2024 at 10:00:23AM +0100, Werner Sembach wrote: > > > I guess what I try to convince you and others is that we _are_ taking Open > > > Source licenses seriously, but still there are mistakes to be made, > > > especially with complex projects like the Linux kernel, e.g. I'm not aware > > > of any other project that uses a similar construct to > > > EXPORT_SYMBOL_GPL()/MODULE_LICENSE(). > > The Linux kernel is very simple from a license point of view, your code > > has to be GPLv2 compatible. That's it, nothing complex or odd about > > that at all. > Then why does the proprietary NVIDIA driver exist? You will have to discuss that with that company's lawyers. That was their business decision to make, and in my opinion, the contracts they wrote around that thing were a mastery of license law in "how to pass the liability onto someone else." Luckily we now have open drivers for almost all of that hardware, so it's not so much of an issue anymore. Again, talk about this with your company lawyers, they can explain it all much better than I can. thanks, greg k-h
Hello Werner,
On Fri, Nov 15, 2024 at 10:40:56AM +0100, Werner Sembach wrote:
> Then why does the proprietary NVIDIA driver exist?
Please don't use NVIDIA's behaviour as a blueprint for your actions.
INAL, but I would not recommend to deduce from "NVIDIA does it and
wasn't tried to stop" (for any value of "it") that "it" is legal, honest
and in line with the open source spirit.
Best regards
Uwe
Am 15.11.24 um 11:22 schrieb Greg KH: > On Fri, Nov 15, 2024 at 10:40:56AM +0100, Werner Sembach wrote: >> Am 15.11.24 um 10:18 schrieb Greg KH: >>> On Fri, Nov 15, 2024 at 10:00:23AM +0100, Werner Sembach wrote: >>>> I guess what I try to convince you and others is that we _are_ taking Open >>>> Source licenses seriously, but still there are mistakes to be made, >>>> especially with complex projects like the Linux kernel, e.g. I'm not aware >>>> of any other project that uses a similar construct to >>>> EXPORT_SYMBOL_GPL()/MODULE_LICENSE(). >>> The Linux kernel is very simple from a license point of view, your code >>> has to be GPLv2 compatible. That's it, nothing complex or odd about >>> that at all. >> Then why does the proprietary NVIDIA driver exist? > You will have to discuss that with that company's lawyers. That was > their business decision to make, and in my opinion, the contracts they > wrote around that thing were a mastery of license law in "how to pass > the liability onto someone else." But you see where there is complexity, and where my misconception stems from? > > Luckily we now have open drivers for almost all of that hardware, so > it's not so much of an issue anymore. > > Again, talk about this with your company lawyers, they can explain it > all much better than I can. > > thanks, > > greg k-h
Am 15.11.24 um 11:51 schrieb Uwe Kleine-König: > Hello Werner, > > On Fri, Nov 15, 2024 at 10:40:56AM +0100, Werner Sembach wrote: >> Then why does the proprietary NVIDIA driver exist? > Please don't use NVIDIA's behaviour as a blueprint for your actions. > INAL, but I would not recommend to deduce from "NVIDIA does it and > wasn't tried to stop" (for any value of "it") that "it" is legal, honest > and in line with the open source spirit. Ofc I don't want to use NVIDIA's behavior as a blueprint, it was just to show where my misconception stems from. > > Best regards > Uwe
On Fri, Nov 15, 2024 at 11:59:47AM +0100, Werner Sembach wrote: > > Am 15.11.24 um 11:22 schrieb Greg KH: > > On Fri, Nov 15, 2024 at 10:40:56AM +0100, Werner Sembach wrote: > > > Am 15.11.24 um 10:18 schrieb Greg KH: > > > > On Fri, Nov 15, 2024 at 10:00:23AM +0100, Werner Sembach wrote: > > > > > I guess what I try to convince you and others is that we _are_ taking Open > > > > > Source licenses seriously, but still there are mistakes to be made, > > > > > especially with complex projects like the Linux kernel, e.g. I'm not aware > > > > > of any other project that uses a similar construct to > > > > > EXPORT_SYMBOL_GPL()/MODULE_LICENSE(). > > > > The Linux kernel is very simple from a license point of view, your code > > > > has to be GPLv2 compatible. That's it, nothing complex or odd about > > > > that at all. > > > Then why does the proprietary NVIDIA driver exist? > > You will have to discuss that with that company's lawyers. That was > > their business decision to make, and in my opinion, the contracts they > > wrote around that thing were a mastery of license law in "how to pass > > the liability onto someone else." > But you see where there is complexity, and where my misconception stems from? No, not at all. nvidia adds complexity in their contracts with vendors in order to attempt to circumvent the very simple license rules that we have. Again, talk to your lawyers about this, they are the ones that know this type of thing. greg k-h
Hello, On Thu, Nov 14, 2024 at 12:14:16PM +0100, Uwe Kleine-König wrote: > On 11/14/24 11:49, Werner Sembach wrote: > > Am 14.11.24 um 11:31 schrieb Uwe Kleine-König: > > > the kernel modules provided by Tuxedo on > > > https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers > > > are licensed under GPLv3 or later. This is incompatible with the > > > kernel's license and so makes it impossible for distributions and other > > > third parties to support these at least in pre-compiled form and so > > > limits user experience and the possibilities to work on mainlining these > > > drivers. > > > > > > This incompatibility is created on purpose to control the upstream > > > process. See https://fosstodon.org/@kernellogger/113423314337991594 for > > > a nice summary of the situation and some further links about the issue. > > > > > > Note that the pull request that fixed the MODULE_LICENSE invocations to > > > stop claiming GPL(v2) compatibility was accepted and then immediately > > > reverted "for the time being until the legal stuff is sorted out" > > > (https://gitlab.com/tuxedocomputers/development/packages/tuxedo- > > > drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427). > > > > As already being implied by that commit message, this is sadly not an > > issue that can be sorted out over night. > > > > We ended up in this situation as MODULE_LICENSE("GPL") on its own does > > not hint at GPL v2, if one is not aware of the license definition table > > in the documentation. > > That statement isn't consistent with you saying to pick GPLv3 as an > explicitly incompatible license to control the mainlining process. So you > knew that it's legally at least questionable to combine these licenses. When I wrote this mail I missed the possibility that while Werner knew GPLv3 isn't ok for in-kernel code might still have considered GPLv3 ok for external modules anyhow. So I take back what I said and excuse me for my words. They were not intended as harsh as Werner obviously took them, but still I regret having written my reply with this suggestion. I'm sorry, Uwe
Hello Uwe, Am 16.11.24 um 18:49 schrieb Uwe Kleine-König: > Hello, > > On Thu, Nov 14, 2024 at 12:14:16PM +0100, Uwe Kleine-König wrote: >> On 11/14/24 11:49, Werner Sembach wrote: >>> Am 14.11.24 um 11:31 schrieb Uwe Kleine-König: >>>> the kernel modules provided by Tuxedo on >>>> https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers >>>> are licensed under GPLv3 or later. This is incompatible with the >>>> kernel's license and so makes it impossible for distributions and other >>>> third parties to support these at least in pre-compiled form and so >>>> limits user experience and the possibilities to work on mainlining these >>>> drivers. >>>> >>>> This incompatibility is created on purpose to control the upstream >>>> process. See https://fosstodon.org/@kernellogger/113423314337991594 for >>>> a nice summary of the situation and some further links about the issue. >>>> >>>> Note that the pull request that fixed the MODULE_LICENSE invocations to >>>> stop claiming GPL(v2) compatibility was accepted and then immediately >>>> reverted "for the time being until the legal stuff is sorted out" >>>> (https://gitlab.com/tuxedocomputers/development/packages/tuxedo- >>>> drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427). >>> As already being implied by that commit message, this is sadly not an >>> issue that can be sorted out over night. >>> >>> We ended up in this situation as MODULE_LICENSE("GPL") on its own does >>> not hint at GPL v2, if one is not aware of the license definition table >>> in the documentation. >> That statement isn't consistent with you saying to pick GPLv3 as an >> explicitly incompatible license to control the mainlining process. So you >> knew that it's legally at least questionable to combine these licenses. > When I wrote this mail I missed the possibility that while Werner knew > GPLv3 isn't ok for in-kernel code might still have considered GPLv3 ok > for external modules anyhow. > > So I take back what I said and excuse me for my words. They were not > intended as harsh as Werner obviously took them, but still I regret > having written my reply with this suggestion. > > I'm sorry, > Uwe Thank you very much for these words. I hope that in my replies I wasn't too harsh from my side and if so, I too want to apologize for it. No more bad feelings going forward. Best regards, Werner Sembach
Hi All, On 14-Nov-24 11:31 AM, Uwe Kleine-König wrote: > Hello, > > the kernel modules provided by Tuxedo on > https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers > are licensed under GPLv3 or later. This is incompatible with the > kernel's license and so makes it impossible for distributions and other > third parties to support these at least in pre-compiled form and so > limits user experience and the possibilities to work on mainlining these > drivers. > > This incompatibility is created on purpose to control the upstream > process. See https://fosstodon.org/@kernellogger/113423314337991594 for > a nice summary of the situation and some further links about the issue. > > Note that the pull request that fixed the MODULE_LICENSE invocations to > stop claiming GPL(v2) compatibility was accepted and then immediately > reverted "for the time being until the legal stuff is sorted out" > (https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427). I know I'm a bit late to this discussion. Still I want to point out that Tuxedo and especially Werner has always been a good upstream actor and I do not believe that they are operating in bad faith here, but rather that the GPL v3 licensing is just an unfortunate mistake which is hard to fix after the fact. As maintainer of drivers/platform/x86 I have worked quite a bit with Tuxedo/Werner and their contributions there are much appreciated. They have also helped a lot with sorting out issues with the PS/2 keyboard driver on Clevo barebones covering not only their own models but all models and helping out with cleaning up the quirk code there which was getting a bit messy. Also as you know Werner has already relicensed all the out of tree drivers which Tuxedo could easily relicense to GPL v2 to GPL v2. TL;DR: I do not believe that Tuxedo/Werner are acting in bad faith here and IMHO it would be good to give them some leeway here while they sort this out. Regards, Hans