[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e95eb45e-8bc6-ec81-fbd2-913f22c4224a@newmedia-net.de>
Date: Wed, 8 May 2019 14:28:21 +0200
From: Sebastian Gottschall <s.gottschall@...media-net.de>
To: David Laight <David.Laight@...LAB.COM>,
'Jiri Kosina' <jikos@...nel.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Andy Lutomirski <luto@...nel.org>,
Greg KH <gregkh@...uxfoundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Rik van Riel <riel@...riel.com>,
"H. Peter Anvin" <hpa@...or.com>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>,
Nicolai Stange <nstange@...e.de>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
"x86@...nel.org" <x86@...nel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end()
export
Am 07.05.2019 um 12:31 schrieb David Laight:
> ...
>> So I don't really see a problem with Andy's patch. If we want to annoy
>> external non-GPL modules as much as possible, sure, that's for a separate
>> discussion though (and I am sure many people would agree to that).
>> Proposal to get rid of EXPORT_SYMBOL in favor of EXPORT_SYMBOL_GPL would
>> be a good start I guess :)
> As a writer on an external non-GPL module I'd point out:
> 1 - Even if we wanted to 'upstream' our code it is very specific
> and wouldn't really be wanted/accepted.
> Even if accepted it would always be excluded from builds.
> 2 - It would take man-years to make it meet the kernel code guidelines
> and to make it portable (from x86).
> It also contains conditionals because it gets build for windows.
> I don't like a lot of it.
> 3 - Almost all the calls to kernel functions are through a 'wrapper'
> file that is compiled on the target system.
> About the only functions that are directly called are ones like memcpy().
> 4 - It wouldn't be that hard, and would still be GPLv2 if we built
> two loadable modules, one GPL and one non-GPL and put all our
> wrapper functions in the GPL one.
> We'd still need a small wrapper for the non-GPL module, but while
> Non-GPL modules are supported at all it wouldn't be much work.
> 5 - The continual tweaks for new kernel versions keep us in a job!
>
> Some of the _GPL exports are a PITA:
> - we can't reference count network namespaces (without creating a socket).
> - we can't reference count 'pid' structures making sending signals tricky.
> - I thing the PCIe error handling functions that we ought to be using
> are GPL.
>
> At the moment we've not needed the fpu :-)
>
> David
unfortunatly some does like ZFS which is opensource, but just licensed
under the wrong copyleft license which cannot be changed that easy.
but its a big loss for the community if such projects get blocked or
limited by a singe linux developer. but thats just my own oppinion (even
if not intentionally targeted here of course).
not every project on his planet is a nvidia driver blob. whats most
important for me is not if its GPL or not. most important is that its
opensource and copyleft.
so the question is if it isnt possible to create a EXPORT_SYMBOL variant
which includes acceptable license models, but still restricts
unacceptable licenses
Sebastian
Powered by blists - more mailing lists