From: Dave Airlie <airlied@gmail.com>
To: Greg KH <greg@kroah.com>
Cc: Dmitry Torokhov <dtor_core@ameritech.net>,
linux-kernel@vger.kernel.org,
Norbert Preining <preining@logic.at>,
Andrew Morton <akpm@osdl.org>
Subject: Re: 2.6.10-mm1, class_simple_* and GPL addition
Date: Sat, 30 Oct 2004 21:44:22 +1000 [thread overview]
Message-ID: <21d7e99704103004445605730d@mail.gmail.com> (raw)
In-Reply-To: <20041029205505.GB30638@kroah.com>
>
> So we can change things, little things like this can help everyone out,
> even if I'm going to get a ton of nvidia user hate mail directed to me
> after the next kernel comes out...
>
> Remember, binary kernel modules are a leach on our community.
True, but now with this code change, you have (acceptable or not) made
binary modules second class citizens of the kernel, they cannot use
the hotplugging or any of the new device model type code, they are
always going to be second best and more of a problem for users, udev
for binary modules is now probably not possible, if you take Linus's
view that binary modules that are not derived from the kernel are not
necessarily GPL then we've made them not able to be as good as other
kernel modules, I don't think we'll annoy any binary module vendors
we'll just piss off users...
personally I thought the whole _GPL thing was meant to denote
interfaces that showed that code was derived from the kernel so should
be under the GPL, interfaces that all drivers should use to work with
Linux are not IMHO proving the code is derived from the kernel, they
still could be derived from another project but just want to be a 2.6
device driver and use hotplug or sysfs.... so they can without fear
lie about their status to use these interfaces... as Linus has said
previously these interfaces are advisory, only lawyers/judges can
decide if they are enforceable....
Dave.
next prev parent reply other threads:[~2004-10-30 11:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-27 13:50 2.6.10-mm1, class_simple_* and GPL addition Norbert Preining
2004-10-27 15:37 ` Greg KH
[not found] ` <1098890583.6990.20.camel@laptop.fenrus.org>
2004-10-27 17:08 ` Norbert Preining
2004-10-27 19:17 ` Petr Vandrovec
2004-10-27 19:55 ` Arjan van de Ven
2004-10-27 21:21 ` Petr Vandrovec
2004-10-28 1:12 ` Dmitry Torokhov
2004-10-29 20:55 ` Greg KH
2004-10-29 22:06 ` Petr Vandrovec
2004-10-30 11:44 ` Dave Airlie [this message]
2004-10-30 14:44 ` Fabio Coatti
2004-11-01 22:31 ` Greg KH
2004-11-09 23:12 ` Luke Maurer
2004-11-10 10:32 ` Fabio Coatti
2004-12-16 17:50 ` Chris Wright
2004-12-16 18:57 ` Greg KH
2004-10-27 21:30 ` Dave Airlie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=21d7e99704103004445605730d@mail.gmail.com \
--to=airlied@gmail.com \
--cc=akpm@osdl.org \
--cc=dtor_core@ameritech.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=preining@logic.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox