Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
signature.asc
Description: PGP signature
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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 signature.asc Description: PGP signature
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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-0e76514c5...@tuxedocomputers.com/)
and then returned on working on the code rewrite for upstream (
https://lore.kernel.org/all/8847423c-22ec-4775-9119-de3e0ddb5...@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 ac
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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-0e76514c5...@tuxedocomputers.com/)
> and then returned on working on the code rewrite for upstream (
> https://lore.kernel.org/all/8847423c-22ec-4775-9119-de3e0ddb5...@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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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-0e76514c5...@tuxedocomputers.com/)
> and then returned on working on the code rewrite for upstream (
> https://lore.kernel.org/all/8847423c-22ec-4775-9119-de3e0ddb5...@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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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-0e76514c5...@tuxedocomputers.com/)
and then returned on working on the code rewrite for upstream (
https://lore.kernel.org/all/8847423c-22ec-4775-9119-de3e0ddb5...@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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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-...@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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
Re: [PATCH 0/2] module: Block modules by Tuxedo from accessing GPL symbols
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
