On Mar 22, 2013, at 11:41 AM, David Miller <da...@davemloft.net> wrote:
> From: Ben Collins <benmcollin...@gmail.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
