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: <14243FE7-A0A6-4C0C-AEFB-95F19C8898E3@gmail.com>
Date:	Fri, 22 Mar 2013 11:53:54 -0400
From:	Ben Collins <benmcollins13@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	afleming@...escale.com, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] net: Add support for handling queueing in hardware


On Mar 22, 2013, at 11:41 AM, David Miller <davem@...emloft.net> wrote:

> From: Ben Collins <benmcollins13@...il.com>
> Date: Fri, 22 Mar 2013 11:39:20 -0400
> 
>> If your company had hardware going to production, you'd want it
>> supported in mainline too, I suspect.
> 
> But never against the wishes of the author of the code.
> 
> This has firm and strict precedence, for example one of the
> implementations block layer encryption was not wanted to be merged by
> the author, and Linus reverted it.
> 
> So if the person who wrote the code doesn't want it upstream, you can't
> bypass them against their wishes, ever.  It's their code not your's.

They never made such a statement. The commit (which is publicly available in Freescale's git repo) makes no mention of it being "good enough for our SDK, but don't send upstream". Freescale wants this upstream, but doesn't have the resources because they are embedded focused and gear more toward SDKs to support their SoCs (currently that means a 3.0.x kernel).

Don't accuse me of something I didn't do. Also, if there's a patch that makes my hardware work, but I can't use it because (even though it's open source licensed) the author doesn't want it in mainline, then that is effectively squatting.

We are a hardware company. We've been provided with a driver for the platform we designed by the SoC vendor. It's GPL licensed. We've attempted to get this done by them, but they haven't been able to, so we are exercising prudence and making sure our platform is supported in mainline. I don't see where that's any different than tons of other patches that go into the kernel.

If it makes everyone feel better, I'll limit attribution in the patches to just an Originally-By: line.

--
Servergy  : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu    : http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ