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]
Message-Id: <20130827.144408.632457019633507990.davem@davemloft.net>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ