linux-kernel - Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

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: <4581595C.7080508@redhat.com>
Date:	Thu, 14 Dec 2006 09:02:04 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Greg KH <gregkh@...e.de>
CC:	Jonathan Corbet <corbet@....net>, Andrew Morton <akpm@...l.org>,
	Martin Bligh <mbligh@...igh.org>,
	"Michael K. Edwards" <medwards.linux@...il.com>,
	Linus Torvalds <torvalds@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches
 for 2.6.19]

Greg KH wrote:

> It's just that I'm so damn tired of this whole thing.  I'm tired of
> people thinking they have a right to violate my copyright all the time.

Pretty much every license under the sun is getting violated,
and people are getting away with it. The GPL is not special
in this regard.

> And yes, it is crap that I deal with every day due to the lovely grey
> area that is Linux kernel module licensing these days.  I have customers
> that demand we support them despite them mixing three and more different
> closed source kernel modules at once and getting upset that I have no
> way to help them out.

However, users do not like running unsupportable software
when the shit hits the fan - which it will always do with
any piece of software, eventually :)

Maybe we should just educate users and teach them to
avoid crazy unsupportable configurations and simply buy
the hardware that has open drivers available?

In the laptop space, I already try to avoid everything
non-Centrino, because chances are a closed source video
or network driver would be needed with something else[1].

Judging from how much vendor drivers tend to get improved
when they get merged upstream, I don't see how vendors
think they can get away with not merging their code upstream.

I'm not talking about this from a legal standpoint (millions
of people get away with blatantly illegal stuff every day),
but from a technical and market point of view.

Why would users buy a piece of hardware that needs a binary
only driver that's unsupportable, when they can buy a similar
piece of hardware that has a driver that's upstream and is
supported by every single Linux distribution out there?

Sure, the process of getting drivers merged upstream[2] can
take some time and effort, but the resulting improvements in
driver performance and stability are often worth it.  It's
happened more than once that the Linux kernel community's
review process turned up some opportunities for a 30% performance
improvement in a submitted driver.

Hardware companies: can you afford to miss out on the stability
and performance improvements that merging a driver upstream tends
to get?

Can you afford to miss out when your competitors are getting these
benefits?

[1] other vendors: fix your stuff, so I can recommend your hardware too!
[2] http://kernelnewbies.org/UpstreamMerge
-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.
-
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/