netdev - Re: [net-next RFC 6/7] i40evf: init code and hardware support

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>] [day] [month] [year] [list]

Date:	Tue, 27 Aug 2013 14:44:08 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	john.ronciak@...il.com
Cc:	bhutchings@...arflare.com, jeffrey.t.kirsher@...el.com,
	mitch.a.williams@...el.com, netdev@...r.kernel.org,
	gospo@...hat.com, sassmann@...hat.com
Subject: Re: [net-next RFC 6/7] i40evf: init code and hardware support

From: John Ronciak <john.ronciak@...il.com>
Date: Tue, 27 Aug 2013 11:39:03 -0700

>> I wonder why this is thought to be necessary.  I've never heard of
>> copyright assignment conditions being accepted in the Linux kernel.
> 
>> Some Linux drivers are dual-licenced under a permissive licence and GPL,
>> and all contributions to them presumably also have to be dual-licenced.
>> It seems like that would allow you to retain the ability to reuse the
>> core hardware code on other operating systems and under proprietary
>> licences, even with copyrightable contributions from others.
> 
> The problem here is that it's a legal issue.  The Intel lawyers (and I've
> heard form other companies on this as well) say that just because we
> release code under a dual license does not mean that any changes (patches)
> that come back are also under a dual license.  That cannot be assumed.  So
> all changes would require us to ask that the patches in question are being
> supplied under the same dual license.  This can get unmanageable fairly
> quickly.  There is also long term tracking of those requests/responses.  So
> using a dual license isn't the same thing unfortunately.

I think it's pretty anti-social to not accept changes made outside of
your group.

I don't want Intel ethernet drivers to go the way of ACPI where nobody
outside of you guys can make changes to the code.

I guarentee I will want to make changes to your drivers if an interface
is changed and I have to touch your code to keep the tree building when
a function signature changes.

To say that I am upset about this would be an understatement, it blocks
normal smooth development of networking infrastructure.
--
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