lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ