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]
Message-ID: <20071202204356.GN15974@stusta.de>
Date:	Sun, 2 Dec 2007 21:43:56 +0100
From:	Adrian Bunk <bunk@...nel.org>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	Ben Greear <greearb@...delatech.com>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	Mark Lord <lkml@....ca>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, containers@...ts.osdl.org
Subject: Re: namespace support requires network modules to say "GPL"

On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote:
> Ben Greear wrote:
>> Stephen Hemminger wrote:
>>>>
>>>> Naw, enterprise (or any other) distro vendors shouldn't have any issues 
>>>> here,
>>>> since they can just patch their kernels around any issues.
>>>>
>>>> But it looks like Eric has this one thought out well enough.
>>>>     
>>>
>>> So you are saying all this is not a problem, fine.
>>> Any affected parties can certainly lobby for themselves. But I suspect
>>> they all think the kernel community is a bunch of ... and will just 
>>> ignore
>>> the problem.   
> >
>> I have a binary module that uses dev_get_by_name...it's sort of a 
>> bridge-like thing and
>> needs user-space to tell it which device to listen for packets on...
>>
>> This code doesn't need or care about name-spaces, so I don't see how it 
>> could really
>> be infringing on the author's code (any worse than loading a binary driver 
>> into the kernel
>> ever does).
>>
>> I would certainly prefer to not have to patch around any problems with 
>> calling dev_get_by_name
>> from a non-gpl module, but if required, I can probably figure something 
>> out...
>
>
> For all I care binary modules can break, but frankly I don't see
> how encapsulating a couple of structures and pointers in a new
> structure and adding a new argument to existing functions shifts
> the decision about how a function should be usable to the namespace
> guys. IMO all functions should continue to be usable as before,
> as decided by whoever actually wrote them.
>...

Even ignoring the fact that it's unclear whether distributing modules 
with not GPLv2 compatible licences is legal at all or might bring you in 
jail, your statement has an interesting implication:

Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the 
EXPORT_SYMBOL_GPL stuff.

Who is considered the author of this code?

And when should he state whether he prefers to use EXPORT_SYMBOL_GPL 
but wasn't able to use it at that when he wrote it since his code 
predates it and is glad to be able to decide this now?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ