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).

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
-- 
2.45.2

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

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

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

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

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

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: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 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

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

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

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,

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,

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

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