Message-ID: <h5q36ajuzgwf5yrjmqv46x62evifcgoi5imxhcvsv7oxauvxak@sj54oisawqnf>
Date: Fri, 15 Nov 2024 08:29:51 +0100
From: Uwe Kleine-König <u.kleine-koenig@...libre.com>
To: Werner Sembach <wse@...edocomputers.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, 
	Luis Chamberlain <mcgrof@...nel.org>, tux@...edocomputers.com, Petr Pavlu <petr.pavlu@...e.com>, 
	Sami Tolvanen <samitolvanen@...gle.com>, Daniel Gomez <da.gomez@...sung.com>, 
	linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Thorsten Leemhuis <linux@...mhuis.info>
Subject: 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-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

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists