Linux in a binary world... a doomsday scenario
Arjan van de Ven
What if.. what if the linux kernel developers tomorrow accept that
binary modules are OK and are essential for the progress of linux.
a hypothetical doomsday scenario by Arjan van de Ven
the primary assumption in this scenario is obviously not going to
happen, but all assumptions that follow are based things that are true
in some form or another, but of course the names of the "innocent" have
been omitted.
On December 6th, 2005 the kernel developers en mass decide that binary
modules are legally fine and also essential for the progress of linux,
and are as such a desirable thing. At first, the development process of
the linux kernel doesn't change much other than a bunch more symbols
getting exported, and EXPORT_SYMBOL_GPL removed.
Within 3 weeks, distributions like Red Hat Enterprise Linux and SuSE's
SLES distribution start to include a wide variety of binary modules on
their installation CDs. Debian renounces this and stays pure to the
cause, as do other open distributions like Fedora Core and openSuSE.
The enterprise distros don't just NVidias and ATIs modules, but include
all the OEM vendor "fakeraid" modules and the various wireless,
winmodem, windsl and TCP-offloading modules as well,. However, unlike
NVidia and ATI, most of the binary driver vendors do not provide their
drivers in a "glue layer" source form, they provide only the final
binaries.
Several hardware vendors that have been friendly to open source so far,
see their competitors ship only binary drivers, and internally they
start to see pressure to also keep the IP private, and they know that
they haven't used some features of the hardware because their legal
department didn't want that IP in the public. As a result they perceive
their competitors binary drivers to be at a theoretical advantage, or at
least their own drivers could be at an advantage if they were also
closed, because they then can use those few extra features to be ahead
of the competition. By February 1st 2006, about half the hardware
vendors have refocused their internal linux driver efforts to create
value adds in the binary drivers they will release in addition to the
open drivers that already exist. Some vendors even openly stopped
supporting the open drivers because they don't have enough resources
to do both.
March 1st. All the new server lines from the top tier hardware vendors
come out with the next generation storage and network hardware. This
hardware comes with binary drivers for the last 2 versions of RHEL and
SLES distributions, and these drivers are already integrated into the
February refreshes of these distributions. One of the storage vendors
releases their driver in a .o + glue layer format, the others doesn't
bother and only releases binaries for these two distributions. Two of
the network card manufacturers release an update for their open source
driver to minimally support the new cards, the others don't. Consumer
hardware is largely unaffected; most consumer chipsets standardize on
AHCI for SATA storage and keep the existing feature sets in networking
chipsets.
April 1st. 2 of the consumer chipset makers have upgraded their chipsets
to include a new and exciting audio feature that enables enhanced DVD
playback, but unfortunately this caused them to deviate from the
'standard' i810 audio hardware interface. One of them releases a binary
driver for a handful of distributions, the other doesn't consider linux
relevant for the desktop and hasn't bothered to do a linux driver yet.
May 1st All of the server class hardware you can buy requires at least
one but usually 2 or 3 binary modules to operate. While some of these
modules are available in blob+glue form, several are only available for
RHEL3, RHEL4 and SLES9 and sometimes the newly released SLES10. Linux
users will have the choice of 4 kernels for these servers at this time,
but no hope to run a kernel.org kernel on these servers. The Ubuntu
people are very upset and are trying hard, with varying success, to get
drivers available for their distribution. Due to this lobby success,
about 50% of the servers can be used with the Ubuntu kernel as well.
June 1st. A huge flamewar, the fourth on this topic since January,
happens on the linux-kernel mailing list. Users and some developers are
demanding that the kernel.org kernel adopts either the existing RHEL or
the SLES module ABI. Investigation shows that this is not possible, and
the thread turns into a discussion on designing a new ABI versus
freezing the existing one. Many kernel developers feel that the existing
ad-hoc ABI is not suitable for freezing and that a new ABI and API,
designed such that it can be kept stable more easily is the way to go,
while others say that this takes too much time and then won't help for
the next 2 years until RHEL and SLES have adopted this ABI, and at least
demand an immediate freeze of the kernel.org ABI so that the upcoming
RHEL5 release maybe uses it, and thus gets drivers written for it. Users
generally use RHEL or SLES for production servers, and clones like
CENTOS which have released binary compatible kernels.
July 1st. It's increasingly hard to run linux without binary modules on
most new consumer PCs. While a year earlier people would have to give up
3D acceleration for this often, now even 2D doesn't work without binary
drivers, nor does networking (both fixed wire or wireless) or sound. For
half the machines there is not enough linux support available at all,
while 20% use ndiswrapper like translation layers to run the Windows
sound and networking drivers. The Debian project, unable to run on most
machines now, is losing massive amounts of users to Ubuntu and
Ubuntu-Debian hybrids. Debian-legal and various other project lists are
impossible to read by people not interested in this particular
flame-topic. Most of the vendors who kept their open source drivers at
least somewhat updated have basically stopped doing so.
July 14th. Linus declares the kernel ABI stable but also splits off a
2.7 kernel and declares that the 2.8 kernel will have a different ABI.
In practice, only people who held on to their old machines can assist in
the 2.7 development, since none of the vendor drivers, not even the ones
who still have a blob+glue construct care about the 'too rapid' moving
development tree.
August 21st. A serious security flaw is found in the 2.6 series, which
turns out to be a design flaw in a key sysfs API. Fixing this flaw would
require to break the module ABI and practically all modules out there,
while not fixing this flaw leaves a potential roothole open. A quick fix
is made available under a CONFIG_ option, but users who need binary
drivers have no choice but leave their systems vulnerable. Flamewars on
lkml flare up again that say Linus made a mistake in freezing the
existing ABI rather than creating a new one designed to be frozen. 2.7
development has mostly stagnated and a patch is proposed to have 2.7
have the 2.6 ABI again, reverting several key VM subsystem improvements
and Ingo's realtime patches.
August 26th. A precooked exploit for the security hole hits bugtraq, and
has been sighted in the wild as used by various rootkits. A php exploit
uses it to go from the httpd user to root. Users are putting pressure on
module vendors to release modules for the new ABI, and several actually
do so in the next three weeks. Others, mostly in the consumer area, say
that the hardware in question is no longer sold and that they aren't
going to spend any time or effort on drivers for it.
Now this scenario may sound unlikely to you. And thankfully the main
assumption (the December 6th event) is extremely unlikely.
However, and this unfortunately, several of the other "leaps" aren't
that unlikely. In fact, some of these results are likely to happen
regardless; witness the flamewars on lkml about breaking module API/ABI.
Witness the ndiswrapper effect of vendors now saying "we support linux
because ndiswrapper can use our windows driver". I hope they won't
happen. Some of that hope will be idle hope, but I believe that the
advantages of freedom in the end are strong enough to overcome the
counter forces.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dave Airlie
> see their competitors ship only binary drivers, and internally they
> start to see pressure to also keep the IP private, and they know that
> they haven't used some features of the hardware because their legal
> department didn't want that IP in the public. As a result they perceive
> their competitors binary drivers to be at a theoretical advantage, or at
> least their own drivers could be at an advantage if they were also
> closed, because they then can use those few extra features to be ahead
> of the competition. By February 1st 2006, about half the hardware
> vendors have refocused their internal linux driver efforts to create
> value adds in the binary drivers they will release in addition to the
> open drivers that already exist. Some vendors even openly stopped
> supporting the open drivers because they don't have enough resources
> to do both.
This is pretty much how the 3D drivers has gone down (as I'm sure
Arjan knows) but just to back it up with others, ATI released enough
info to make a basic 3D driver for their hardware to do OpenGL, they
didn't give out any info on the "protected IP" like HyperZ, MPEG
decoder, SmartShader, the list goes on, a lot of this has since been
reverse engineered for the older chips, then NVIDIA didn't release any
open source drivers, then ATI decided to go close source as they
couldn't compete on the feature set they were willing (allowed by
lawyers) to put into the open source drivers. ATI engineers now use
the excuse well NVIDIA have a closed source driver so we have to have
one to compete. Again neither company is willing to put resources into
doing much on the open source scene due to lack of staff, reasons, and
neither company is willing to give info to open source developers
because they need to push it all past their legal departments (despite
this info existing and a number of open source developers having
access to it via $job).
Intel are now starting to think about doing closed source only drivers
from what I heard on the grapevine, and as their open drivers only
provide modesetting via the BIOS, their drivers aren't exactly useful
in many situations..
Its a slippery slippery slope and all you people that bitch and moan
about stable API really don't have a clue what it means, Arjans
scenario is quite practical (it may take longer to happen but I doubt
the future would be much different..)
You'd also have issues with two binary drivers doing things in the
kernel that might affect each other, like bad interrupt sharing or
messing with pci setups for higher speeds, and no chance of getting
them working in any controlled fashion together without vendor
support.
Dave.
William Lee Irwin III
> Now this scenario may sound unlikely to you. And thankfully the main
> assumption (the December 6th event) is extremely unlikely.
> However, and this unfortunately, several of the other "leaps" aren't
> that unlikely. In fact, some of these results are likely to happen
> regardless; witness the flamewars on lkml about breaking module API/ABI.
> Witness the ndiswrapper effect of vendors now saying "we support linux
> because ndiswrapper can use our windows driver". I hope they won't
> happen. Some of that hope will be idle hope, but I believe that the
> advantages of freedom in the end are strong enough to overcome the
> counter forces.
The December 6 event is extraordinarily unlikely. What's vastly more
likely is consistent "erosion" over time. First the 3D video drivers,
then the wireless network drivers, then the fakeraid drivers, and so on.
Each instance degrades Linux' capabilities without such drivers, and
incrementally reduces the userbase of newer releases. I doubt there will
be a "revolutionary" step at all, just progressively more erosion over
time. As things go, Linux gets "flakier" as binary modules break for
people when they upgrade, new versions support less hardware as the
binary modules hobble them, and so on. DRM even threatens to prevent
some machines from booting Linux in the categorical sense.
I expect the closed source IP affairs rather to keep chipping away
until Linux is dead, or they get tired and change strategies to kill it,
versus any sudden changes of course.
-- wli
Pekka Enberg
> I expect the closed source IP affairs rather to keep chipping away
> until Linux is dead, or they get tired and change strategies to kill it,
> versus any sudden changes of course.
Alternatively, take away ndiswrapper and binary-only ATI and NVIDIA
drivers, and perhaps the users will start to care and pressure their
vendor to open up. I know I have become a very disappointed ATI
customer after figuring out that they have zero interest in me using
the hardware I paid for on Linux...
Pekka
Xavier Bestel
> This is pretty much how the 3D drivers has gone down
.. and it doesn't look like the Xorg people are willing/able to do
something against that: witness the current thread named "Official
method for determining modular X module path?" on Xorg's mailing-list
which deals *exactely* with Arjan's theoretical problems of
cross-distributions modules compatibility, with the same pragmatism that
made Linus choose Bitkeeper.
As one can consider Xorg as being a device driver, albeit in userspace,
you see that the 3D part isn't going up any time soon.
Jeff Garzik
You forgot the effect of binary-only on non-x86 arches...
Jeff
Jan-Benedict Glaw
> Arjan van de Ven wrote:
> >Linux in a binary world
>
> You forgot the effect of binary-only on non-x86 arches...
Um, let's write an binary emulator for those archs. It did work for
Alphas executing i386 code, so it'd work for PPC, too :-)
MfG, JBG
--
Jan-Benedict Glaw jbg...@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Andrew Walrond
>
> a hypothetical doomsday scenario by Arjan van de Ven
>
Can I ask what prompted your post?
>
> On December 6th, 2005 the kernel developers en mass decide that binary
> modules are legally fine and also essential for the progress of linux,
Has anyone (influential) actually being toying with this idea? I hope not, but
if they are, I'd like to know who to lobby...
Andrew Walrond
Arjan van de Ven
> On Monday 05 December 2005 10:52, Arjan van de Ven wrote:
> >
> > a hypothetical doomsday scenario by Arjan van de Ven
> >
>
> Can I ask what prompted your post?
I got one too many hatemails from a "nvidia fanboy" who blamed me for
just about anything wrong in the world.... I fear that most of these
people have no idea why open source drivers matter, or at least what the
consequences are for not caring about drivers being open or not.
>
> >
> > On December 6th, 2005 the kernel developers en mass decide that binary
> > modules are legally fine and also essential for the progress of linux,
>
> Has anyone (influential) actually being toying with this idea? I hope not, but
> if they are, I'd like to know who to lobby...
this part of the "story" is fiction. A lot of the rest is not. There are
already several servers that you can only use with binary modules..
modules only available in full binary form for RHEL and SLES kernels for
example.
Alistair John Strachan
> On 12/5/05, William Lee Irwin III <w...@holomorphy.com> wrote:
> > I expect the closed source IP affairs rather to keep chipping away
> > until Linux is dead, or they get tired and change strategies to kill it,
> > versus any sudden changes of course.
>
> Alternatively, take away ndiswrapper and binary-only ATI and NVIDIA
> drivers, and perhaps the users will start to care and pressure their
> vendor to open up. I know I have become a very disappointed ATI
> customer after figuring out that they have zero interest in me using
> the hardware I paid for on Linux...
The problem with this approach is the tiny size of the minority of customers
using ATI's video cards on a non-Windows OS.
I think the only way we can persuade vendors to not take the direction that
Arjan speculates they will, is to increase the Linux userbase (and therefore
ATI customers using Linux) by making "Desktop Linux" increasingly competent.
As easy as it is to be pessimistic about binary vendor lockin, there's still
places in industry, government and inevitably the general public where Linux
is slowly starting to take off as a real desktop alternative to Windows.
When this happens, vendors will just have to solve all the IP nonsense
associated with their hardware, or design hardware to be more dependent on
firmware so that largely open source drivers are more feasible for them.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Gene Heskett
>On Monday 05 December 2005 13:07, Pekka Enberg wrote:
>> On 12/5/05, William Lee Irwin III <w...@holomorphy.com> wrote:
>> > I expect the closed source IP affairs rather to keep chipping away
>> > until Linux is dead, or they get tired and change strategies to
>> > kill it, versus any sudden changes of course.
>>
>> Alternatively, take away ndiswrapper and binary-only ATI and NVIDIA
>> drivers, and perhaps the users will start to care and pressure their
>> vendor to open up. I know I have become a very disappointed ATI
>> customer after figuring out that they have zero interest in me using
>> the hardware I paid for on Linux...
>
>The problem with this approach is the tiny size of the minority of
> customers using ATI's video cards on a non-Windows OS.
Hey, I resemble that remark. I've been using an ATI XTacy 9200SE for
a couple of years now, since an nvidia card crowbared the buss & blew out
a
motherboard. Needless to say, I wasn't happy with nvidia over that.
I bought a faster cpu & more ram on a different mobo for this machine.
But, get this: Another new board, with the same cpu & ram on it, is
now running that cpu 70F degrees cooler, at 200 mhz faster on the cpu
clock. With another nvidia card in it, running my milling machine.
>I think the only way we can persuade vendors to not take the direction
> that Arjan speculates they will, is to increase the Linux userbase
> (and therefore ATI customers using Linux) by making "Desktop Linux"
> increasingly competent.
I'm not a 'gamer' so the last frame per second isn't that important
to me, but its close to 1000 on a small piece of a 1600x1200 screen.
>As easy as it is to be pessimistic about binary vendor lockin, there's
> still places in industry, government and inevitably the general public
> where Linux is slowly starting to take off as a real desktop
> alternative to Windows.
Its been my alternative since 1998, never was windows here, coming in
from the amiga world.
>
>When this happens, vendors will just have to solve all the IP nonsense
>associated with their hardware, or design hardware to be more dependent
> on firmware so that largely open source drivers are more feasible for
> them.
Don't hold your breath, its not healthy in the long view...
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
jme...@ns1.utah-nac.org
Welcome to reality.
Jeff
David Woodhouse
> > modules are legally fine and also essential for the progress of linux,
>
> Has anyone (influential) actually being toying with this idea? I hope not, but
> if they are, I'd like to know who to lobby...
Remember that the only distinction between EXPORT_SYMBOL() and
EXPORT_SYMBOL_GPL() is that the latter is a technological measure to
prevent abuse. The use of EXPORT_SYMBOL_GPL() cannot actually impose any
additional restrictions over and above what the GPL requires of
EXPORT_SYMBOL() -- because any additional restrictions would themselves
violate the GPL.
Thus, the only point in the above-linked patch is to remove a technical
measure which prevents abuse. I feel very strongly that it should be
reverted.
--
dwmw2
Arjan van de Ven
> On Mon, 2005-12-05 at 18:26 +0000, Andrew Walrond wrote:
> > > On December 6th, 2005 the kernel developers en mass decide that binary
> > > modules are legally fine and also essential for the progress of linux,
> >
> > Has anyone (influential) actually being toying with this idea? I hope not, but
> > if they are, I'd like to know who to lobby...
>
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e3c3374fbf7efe9487edc53cd10436ed641983aa
I think you're wrong on this. Not about thinking it should be reverted
per se, but in the big picture it's not linked to the scenario. One
export more or less doesn't matter at all.
David Woodhouse
> I think you're wrong on this. Not about thinking it should be reverted
> per se, but in the big picture it's not linked to the scenario. One
> export more or less doesn't matter at all.
Yeah, I suppose that's true to a large extent, but the fact that Linus
is actively aiding and abetting a licence violator by reverting this
particular symbol from EXPORT_SYMBOL_GPL() to EXPORT_SYMBOL() sends a
very strong message. And it's not one which we should be sending.
Linus chose not to collect copyright assignments; therefore this kind of
decision isn't his to make. We are bound by the GPL and (GPLv3 aside) we
have no practical option to change that -- by royal decree or otherwise.
I think it's time to recognise that there's no difference in licensing
terms between EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(). The _only_
difference is that the latter will lead to harsher punishments for
violators because it needs to be actively circumvented.
We should switch _everything_ to EXPORT_SYMBOL_GPL(). It can't change
the licensing question at all -- if binary-only modules were legal
before they will _still_ be legal, because we're not allowed to impose
additional restrictions anyway. But the change does strengthen the case
against anyone found to be in violation of the licence, because they
have to deliberately circumvent the protection it implies.
--
dwmw2
Bernd Petrovitsch
> On Mon, 2005-12-05 12:18:34 -0500, Jeff Garzik <jga...@pobox.com> wrote:
> > Arjan van de Ven wrote:
> > >Linux in a binary world
> >
> > You forgot the effect of binary-only on non-x86 arches...
>
> Um, let's write an binary emulator for those archs. It did work for
> Alphas executing i386 code, so it'd work for PPC, too :-)
And a few years later the PPC arch is also dead?
SCNR,
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Matthieu CASTET
> Linux in a binary world
>
>
> What if.. what if the linux kernel developers tomorrow accept that
> binary modules are OK and are essential for the progress of linux.
>
[...]
> Now this scenario may sound unlikely to you. And thankfully the main
> assumption (the December 6th event) is extremely unlikely.
>
> However, and this unfortunately, several of the other "leaps" aren't
> that unlikely. In fact, some of these results are likely to happen
> regardless; witness the flamewars on lkml about breaking module API/ABI.
> Witness the ndiswrapper effect of vendors now saying "we support linux
> because ndiswrapper can use our windows driver". I hope they won't
> happen. Some of that hope will be idle hope, but I believe that the
> advantages of freedom in the end are strong enough to overcome the
> counter forces.
And some embedded companies provide the minimal source code to put
in arch and everything else (ethernet, adsl, wifi, ...) is binaries
modules.
Tim Bird
> I think it's time to recognise that there's no difference in licensing
> terms between EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL().
I disagree. I think that has long since become the intent
of EXPORT_SYMBOL_GPL().
If the GPL covers interface linkages (whether static or
dynamic) then EXPORT_SYMBOL_GPL is redundant. If it does
not, in all cases, then EXPORT_SYMBOL_GPL is, as
an extension to GPL, therefore a GPL violation.
I believe there are cases where an interface could
be deemed not coverable by the GPL. Putting
EXPORT_SYMBOL_GPL around it would be an attempt
to extend GPL to where it otherwise might not reach.
DISCLAIMER: I'm not speaking for Sony here. Personally
I don't believe that most drivers are derivative works
of the operating systems they run with, and I don't
believe it helps Linux to assert that they are.
But, hey, it's not my kernel, and not my plan for
world domination. ;-)
To the larger argument about supporting binary drivers,
all Arjan manages to prove with his post is that,
if handled in the worst possible way, support for
binary drivers would be a disaster. Who can disagree
with that?
(I'm really not trolling or trying to start a flame
war here. It's just my 2 cents.)
Regards,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
Dave Airlie
> all Arjan manages to prove with his post is that,
> if handled in the worst possible way, support for
> binary drivers would be a disaster. Who can disagree
> with that?
>
And do you think that given the opportunity, any company is going
spend the extra money required to not do it in the worst possible
way?? Companies want to spend as little as possible on drivers, and
drop support as soon as it makes sense financially to do so, they
aren't going to come to the correct best possible way on their own, or
via consortia of companies ala CEL or OSDL, they require outside
pressure to make them change their mindset from the only example they
have which is developing Windows drivers..
Dave.
Bernd Petrovitsch
[...]
> To the larger argument about supporting binary drivers,
> all Arjan manages to prove with his post is that,
> if handled in the worst possible way, support for
> binary drivers would be a disaster. Who can disagree
> with that?
And it is the to-be-expected way for all companies/corporations/
commercial entities where none-techies are the decision makers (the
condition is a sufficient one but not a necessary one) - ethics and/or
fairness are pretty irrelevant there if there seems to a problem with
sales, stakeholders value, bonuses of management and especially the
deciders themselves etc.
Yes, that may be rude. Sorry, that is reality.
In one word: It will doubtless go that way because only short-term
"success" is relevant (i.e. just to get as much money as possible out of
it *now*) and the devil may care ....
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
-
Tim Bird
>>To the larger argument about supporting binary drivers,
>>all Arjan manages to prove with his post is that,
>>if handled in the worst possible way, support for
>>binary drivers would be a disaster. Who can disagree
>>with that?
>>
> And do you think that given the opportunity, any company is going
> spend the extra money required to not do it in the worst possible
> way??
I meant "handled in the worst possible way by
the kernel developers". It *is* possible to define
stable APIs and have them used successfully.
POSIX is not the greatest example, but it seems
to work OK. I realize that drivers are more
tightly bound to the kernel than are libraries
or applications, but sheesh, this is not rocket
science.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
-
Tim Bird
> I meant "handled in the worst possible way by
> the kernel developers". It *is* possible to define
> stable APIs and have them used successfully.
>
> POSIX is not the greatest example, but it seems
> to work OK.
to refer to the kernel binary API for applications.
David Woodhouse
> dynamic) then EXPORT_SYMBOL_GPL is redundant. If it does
> not, in all cases, then EXPORT_SYMBOL_GPL is, as
> an extension to GPL, therefore a GPL violation.
You seem to be agreeing with me to a certain extent. What I'm saying is
that there _can_ be no difference between EXPORT_SYMBOL() and
EXPORT_SYMBOL_GPL(). We might as well stick to one or the other.
As you say -- if the GPL covers modules, EXPORT_SYMBOL_GPL is redundant.
If it does not, then EXPORT_SYMBOL_GPL in itself is a GPL violation.
The point of EXPORT_SYMBOL_GPL, however, is that it is a technical
restriction which needs to be circumvented in order to load a non-GPL
module. That does affect the outcome of a court case when the licence is
violated, and that's why I think we should it throughout.
However, if your lawyers promise you that the court won't rule that the
GPL covers modules, then you have nothing to fear from EXPORT_SYMBOL_GPL
because (according to your lawyers) the court will rule that it means no
more than EXPORT_SYMBOL does. That's your risk to take; there's no
reason why we should use EXPORT_SYMBOL _anywhere_ until/unless a court
actually makes that ruling.
--
dwmw2
Andrea Arcangeli
> If the GPL covers interface linkages (whether static or
> dynamic) then EXPORT_SYMBOL_GPL is redundant. If it does
> not, in all cases, then EXPORT_SYMBOL_GPL is, as
> an extension to GPL, therefore a GPL violation.
The last time I spoke with Linus about this, what I understood can be
described in two points:
1) EXPORT_SYMBOL_GPL is an hint: if you have to circumvent it, there are
high chances that you're creating a derivative of the linux kernel and
in turn there are high chances that you're illegal
2) The fact you're illegal or not, has nothing to do with the _GPL tag
in the exports, the illegal usage is when the module create a derivative
of the linux kernel.
Now I don't know for sure myself (I'm not a lawyer) what is a derivative
of the linux kernel (don't ask me), but the two above points are quite
clear to me.
I always thought the _GPL tag could have no direct legal implications
and Linus confirmed it. The kernel is GPL so everyone can modify the
exports or re-export symbols as usual, the exports are GPL code too. The
guy who re-exports or remove a _GPL tag is just modifying a GPL code, so
he's ok.
The _GPL tag is useful as an hint to binary only vendors as as such it
makes perfect sense.
Andrea Arcangeli
> The December 6 event is extraordinarily unlikely. What's vastly more
> likely is consistent "erosion" over time. First the 3D video drivers,
> then the wireless network drivers, then the fakeraid drivers, and so on.
I agree about the erosion.
I am convinced that the only way to stop the erosion is to totally stop
buying hardware that has only binary only drivers (unless you buy it to
create an open source driver or to reverse engineer the binary only
driver of course! ;).
For example if a laptop has an embedded wirless or 3d card not supported by
open source drivers, buy a laptop without any wireless card or without
3d, instead of buying one with the not-supported hardware without using
it (I can guarantee there are still laptops that requires no 3d
binary only drivers and no wirless cards drivers, even for the winmodems
you can choose the ones supported by alsa). We literally have to refuse
buying those cards with binary only kernel drivers.
Every time we buy a piece of hardware with binary only drivers we admit
that the binary only driver vendors are doing the right choice for their
stockholders. Only when we refuse to buy it, we can make a slight difference.
When we don't buy hardware without open source drivers, we send the
message to the shareholders that the management is causing them a loss.
It's market forces controlling which drivers are open sources and which
aren't (the risk of being sued and the cost of the laywers is only part
of the more complex equation), and the customers have an huge strength
in controlling those forces (we effectively control 50% of it).
The fact Arjan got the "nvidia fanboy" complaining, is the sign that
some people just don't care. This understandable for a 3d kind of
product which is 90% for entertainment (nobody loses money when it
crashes), and we generally can't expect everyone to care about the long
term kernel development.
But at least for all more business oriented usages of linux, linux users
should understand the erosion they create by funding companies that
requires binary only drivers.
Every time we buy an hardware with a binary only driver, we effectively
increase the erosion, or we give a sound reason to those company to keep
eroding.
I think messages like the one from Arjan are very positive to let people
understand the long term effect of binary only drivers, but this should
be combined with the strategy to use to reduce the erosion (i.e. not to
buy hardware that has binary only drivers).
Perhaps we should add a printk that points to an url on kernel.org
including Arjan's message every time a non-gpl module gets loaded by the
kernel. I think it's a matter of educating the customer too or they can
do mistakes, creating a blacklist would help too.
I don't believe in the breaking of the 3d drivers gratuitously, it
should be market forces deciding which drivers have to be open sources
and which not. But our side of the market (i.e. the buyers) must be
educated properly.
Tim Bird
> On Mon, Dec 05, 2005 at 03:56:06PM -0800, Tim Bird wrote:
>
>>If the GPL covers interface linkages (whether static or
>>dynamic) then EXPORT_SYMBOL_GPL is redundant. If it does
>>not, in all cases, then EXPORT_SYMBOL_GPL is, as
>>an extension to GPL, therefore a GPL violation.
>
> The last time I spoke with Linus about this, what I understood can be
> described in two points:
>
> 1) EXPORT_SYMBOL_GPL is an hint: if you have to circumvent it, there are
> high chances that you're creating a derivative of the linux kernel and
> in turn there are high chances that you're illegal
>
> 2) The fact you're illegal or not, has nothing to do with the _GPL tag
> in the exports, the illegal usage is when the module create a derivative
> of the linux kernel.
>
> Now I don't know for sure myself (I'm not a lawyer) what is a derivative
> of the linux kernel (don't ask me), but the two above points are quite
> clear to me.
This interpretation puts kernel developers in the
position of making the legal decision about which
interfaces cause derivate-work risk and which
do not. That's hardly a recipe for legal clarity.
(Not that legal clarity is a goal of Linux
kernel development... :-)
Different developers are likely to have
different viewpoints on which interfaces pose risks.
I guess Linus gets the last call (as usual),
so there's some possibility of some amount
of uniformity here.
Most kernel developers will naturally tend
towards making more symbols EXPORT_SYMBOL_GPL,
whether there's valid legal basis for it or not.
(Please let me know if there's a lawyer somewhere
reviewing the insertion of EXPORT_SYMBOL_GPLs)
David currently suggests that *all* interfaces
be so designated. I suspect he strongly believes
that any use of a kernel interface creates a
derivative work. I have a different opinion.
...
> The _GPL tag is useful as an hint to binary only vendors as as such it
> makes perfect sense.
Well, if it makes sense to have developers giving out legal
advice, then I guess so.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
-
Andrea Arcangeli
> This interpretation puts kernel developers in the
> position of making the legal decision about which
An hint can hardly defined as a "legal decision".
An hint _only_ means "be careful you _might_ be illegal".
"might be" is hardly a "legal deicision", infact it's not decision at
all.
It's like a "you should check your stuff to be sure you're ok".
This is the way I understood it at least...
> Different developers are likely to have
> different viewpoints on which interfaces pose risks.
The way I understood it, is that you may be breaking the GPL even if you
don't circumvent any _GPL tag. You've to check your stuff yourself, and
if you have troubles because of a _GPL tag, it means you must check it
even more closely because you got an explicit _warning_. A warning isn't
a "legal deicsion", it's just a warning.
> I guess Linus gets the last call (as usual),
> so there's some possibility of some amount
> of uniformity here.
agreed.
> Most kernel developers will naturally tend
> towards making more symbols EXPORT_SYMBOL_GPL,
> whether there's valid legal basis for it or not.
Could be, but then those developers would be wrong. We're not required
to make a symbol as _GPL to make the module illegal. So we should be
reasonable.
> (Please let me know if there's a lawyer somewhere
> reviewing the insertion of EXPORT_SYMBOL_GPLs)
I don't think there is one, and there needs to be no one, because the
_GPL tag is not a legal decision, is an hint given from programmers to
lawyers. Programmers may be totally wrong, but we do our best to help on
the legal side too.
> David currently suggests that *all* interfaces
> be so designated. I suspect he strongly believes
> that any use of a kernel interface creates a
> derivative work. I have a different opinion.
This question I don't want to answer because I'm a programmer, this
requires a lawyer because this is the real _legal_decision_: what is a
derived work of the kernel is the only thing that decides what is legal
and illegal.
> Well, if it makes sense to have developers giving out legal
> advice, then I guess so.
;) Of course I meant it makes perfect sense that it's _only_ an "hint".
Jeff Garzik
> On Mon, Dec 05, 2005 at 05:20:16PM -0800, Tim Bird wrote:
>
>>This interpretation puts kernel developers in the
>>position of making the legal decision about which
>
>
> An hint can hardly defined as a "legal decision".
>
> An hint _only_ means "be careful you _might_ be illegal".
>
> "might be" is hardly a "legal deicision", infact it's not decision at
> all.
Correct. It's largely a demonstration of "intent" -- which is both a
legal and a common sense concept. It's not a legally binding <anything>.
IANAL, of course.
Jeff
Gene Heskett
>> To the larger argument about supporting binary drivers,
>> all Arjan manages to prove with his post is that,
>> if handled in the worst possible way, support for
>> binary drivers would be a disaster. Who can disagree
>> with that?
>
>And do you think that given the opportunity, any company is going
>spend the extra money required to not do it in the worst possible
>way?? Companies want to spend as little as possible on drivers, and
>drop support as soon as it makes sense financially to do so, they
>aren't going to come to the correct best possible way on their own, or
>via consortia of companies ala CEL or OSDL, they require outside
>pressure to make them change their mindset from the only example they
>have which is developing Windows drivers..
>
video card now under development, and I hear its less than 3-4 months
from production status now, and at a competitive, sub $150 USD price.
If 50% of nvidia's currant linux market share were to dissappear a month
after this card becomes available for purchase by those whom one might
categorize as believers, I'd think that would send a message loud enough
to be heard.
Particularly if windows drivers are available, open sourced, and
installable on a winderz box using the normal install wizard, and
promoted as such to the joe six-packs of the world. At the right price,
that would send an even louder message to both nvidia and ati, who so
far, seems to be all hat & no cattle. While the drivers in x.orgs code
seem to be working fairly well, and absolutely stable, I'm sure there
are hardware things in this 9200SE I have here that are not being used
by x.org's code. It works well enough to play tux-racer, but not well,
keyboard response acts like the machine is being hogged by the video.
>Dave.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majo...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Brian Gerst
> On Mon, Dec 05, 2005 at 04:18:51AM -0800, William Lee Irwin III wrote:
>> The December 6 event is extraordinarily unlikely. What's vastly more
>> likely is consistent "erosion" over time. First the 3D video drivers,
>> then the wireless network drivers, then the fakeraid drivers, and so on.
>
> I agree about the erosion.
>
> I am convinced that the only way to stop the erosion is to totally stop
> buying hardware that has only binary only drivers (unless you buy it to
> create an open source driver or to reverse engineer the binary only
> driver of course! ;).
>
> For example if a laptop has an embedded wirless or 3d card not supported by
> open source drivers, buy a laptop without any wireless card or without
> 3d, instead of buying one with the not-supported hardware without using
> it (I can guarantee there are still laptops that requires no 3d
> binary only drivers and no wirless cards drivers, even for the winmodems
> you can choose the ones supported by alsa). We literally have to refuse
> buying those cards with binary only kernel drivers.
>
> Every time we buy a piece of hardware with binary only drivers we admit
> that the binary only driver vendors are doing the right choice for their
> stockholders. Only when we refuse to buy it, we can make a slight difference.
> When we don't buy hardware without open source drivers, we send the
> message to the shareholders that the management is causing them a loss.
The problem with this statement is that Linux users are a drop in the
bucket of sales for this hardware. Boycotting doesn't cost the vendors
enough to make them care. And this does nothing for people who are
converting over to Linux, and didn't buy hardware with that
consideration in mind.
The only way to break the stalemate is to reverse engineer drivers.
Turning the screws tighter isn't going to make open drivers magically
appear. More likely, the vendors will abandon Linux as being too
hostile and/or too costly to support, leaving everybody back at square one.
--
Brian Gerst
Andrea Arcangeli
> The problem with this statement is that Linux users are a drop in the
> bucket of sales for this hardware. Boycotting doesn't cost the vendors
> enough to make them care. And this does nothing for people who are
> converting over to Linux, and didn't buy hardware with that
> consideration in mind.
Effectively this is why 3d drivers are the only thing we litearlly lost
control of. But my email was general. I wasn't only speaking of 3d
hardware.
For 3d you're very well right, but once linux becomes mainstream in the
desktop, things could change.
Also note, I've some 3d on my laptop but I need no binary only drivers
for it, so there's some option.
Currently in KLive I can see there are about 44% of the users with the
nvidia driver loaded (once I have time to work on klive again, I'll
make the new data browsable on the web, I had to query the db by hand to
see it right now, ironically there are about 80 sessions where the
_only_ driver loaded is the nvidia one and everything else is static ;).
> The only way to break the stalemate is to reverse engineer drivers.
> Turning the screws tighter isn't going to make open drivers magically
> appear. More likely, the vendors will abandon Linux as being too
> hostile and/or too costly to support, leaving everybody back at square one.
Let's not forget they make money selling the hardware, the binary only
driver is free. And releasing an open source driver if something will
decrease their maintainance costs. The only thing this binary only
driver does is to avoid them _risks_, but they gain no money by keeping
it binary only. So the day they will be losing money by keeping the
driver binary only, I expect they may open it. They simply have no
reason to do it right now.
However this will only work out if we exercise our buyer rights (again
in general). To make the counter example, if we would suddently start to
prefer hardware with binary only drivers, then the doomsay scenario may
materialize with quick erosion.
In the meantime I don't like gratuitous breakages, I prefer that they
open it because it makes sense for them. Breaking it gratuitously is
what could make linux hostile and too costly to support IMHO.
Andre Hedrick
Hi Arjan,
You know I like to chime in from time to time on this subject, mostly for
fun.
Inside the your position, many (non-linux people) have seen a position
which appears to be acceptable when added with the classic "IFF" or
"If and only IF" conditionals.
Binary Blob + source glue layer == psuedo module.
The arguement implies this is okay in theory but practice has proven it
falls apart. However, the remander represents a snap back direction to
the otherside. This make one wonder if server hardware direction goes
this way regardless of the opensource ideas, what really prevents the
hardware vendors from abandoning Linux. Does anyone really know what the
actual percentage is for a given company's topline v/s bottom line revenue
broken down as a ratio of open source customers revenue/totals v/s other
customers revenue/totals.
If there was some way to obtain such information, this could lead credence
or negate the arguement about open source drivers.
Please know the comments are about "open source" only and does not take a
position on any given license associated to the work.
Cheers,
Andre
PS this is for the arena of ideas and not material to flame.
On Mon, 5 Dec 2005, Arjan van de Ven wrote:
> Linux in a binary world
>
>
> What if.. what if the linux kernel developers tomorrow accept that
> binary modules are OK and are essential for the progress of linux.
>
> a hypothetical doomsday scenario by Arjan van de Ven
>
> the primary assumption in this scenario is obviously not going to
> happen, but all assumptions that follow are based things that are true
> in some form or another, but of course the names of the "innocent" have
> been omitted.
>
>
>
>
> On December 6th, 2005 the kernel developers en mass decide that binary
> modules are legally fine and also essential for the progress of linux,
> and are as such a desirable thing. At first, the development process of
> the linux kernel doesn't change much other than a bunch more symbols
> getting exported, and EXPORT_SYMBOL_GPL removed.
>
> Within 3 weeks, distributions like Red Hat Enterprise Linux and SuSE's
> SLES distribution start to include a wide variety of binary modules on
> their installation CDs. Debian renounces this and stays pure to the
> cause, as do other open distributions like Fedora Core and openSuSE.
>
> The enterprise distros don't just NVidias and ATIs modules, but include
> all the OEM vendor "fakeraid" modules and the various wireless,
> winmodem, windsl and TCP-offloading modules as well,. However, unlike
> NVidia and ATI, most of the binary driver vendors do not provide their
> drivers in a "glue layer" source form, they provide only the final
> binaries.
>
> Several hardware vendors that have been friendly to open source so far,
> see their competitors ship only binary drivers, and internally they
> start to see pressure to also keep the IP private, and they know that
> they haven't used some features of the hardware because their legal
> department didn't want that IP in the public. As a result they perceive
> their competitors binary drivers to be at a theoretical advantage, or at
> least their own drivers could be at an advantage if they were also
> closed, because they then can use those few extra features to be ahead
> of the competition. By February 1st 2006, about half the hardware
> vendors have refocused their internal linux driver efforts to create
> value adds in the binary drivers they will release in addition to the
> open drivers that already exist. Some vendors even openly stopped
> supporting the open drivers because they don't have enough resources
> to do both.
>
> March 1st. All the new server lines from the top tier hardware vendors
> come out with the next generation storage and network hardware. This
> hardware comes with binary drivers for the last 2 versions of RHEL and
> SLES distributions, and these drivers are already integrated into the
> February refreshes of these distributions. One of the storage vendors
> releases their driver in a .o + glue layer format, the others doesn't
> bother and only releases binaries for these two distributions. Two of
> the network card manufacturers release an update for their open source
> driver to minimally support the new cards, the others don't. Consumer
> hardware is largely unaffected; most consumer chipsets standardize on
> AHCI for SATA storage and keep the existing feature sets in networking
> chipsets.
>
> April 1st. 2 of the consumer chipset makers have upgraded their chipsets
> to include a new and exciting audio feature that enables enhanced DVD
> playback, but unfortunately this caused them to deviate from the
> 'standard' i810 audio hardware interface. One of them releases a binary
> driver for a handful of distributions, the other doesn't consider linux
> relevant for the desktop and hasn't bothered to do a linux driver yet.
>
> May 1st All of the server class hardware you can buy requires at least
> one but usually 2 or 3 binary modules to operate. While some of these
> modules are available in blob+glue form, several are only available for
> RHEL3, RHEL4 and SLES9 and sometimes the newly released SLES10. Linux
> users will have the choice of 4 kernels for these servers at this time,
> but no hope to run a kernel.org kernel on these servers. The Ubuntu
> people are very upset and are trying hard, with varying success, to get
> drivers available for their distribution. Due to this lobby success,
> about 50% of the servers can be used with the Ubuntu kernel as well.
>
> June 1st. A huge flamewar, the fourth on this topic since January,
> happens on the linux-kernel mailing list. Users and some developers are
> demanding that the kernel.org kernel adopts either the existing RHEL or
> the SLES module ABI. Investigation shows that this is not possible, and
> the thread turns into a discussion on designing a new ABI versus
> freezing the existing one. Many kernel developers feel that the existing
> ad-hoc ABI is not suitable for freezing and that a new ABI and API,
> designed such that it can be kept stable more easily is the way to go,
> while others say that this takes too much time and then won't help for
> the next 2 years until RHEL and SLES have adopted this ABI, and at least
> demand an immediate freeze of the kernel.org ABI so that the upcoming
> RHEL5 release maybe uses it, and thus gets drivers written for it. Users
> generally use RHEL or SLES for production servers, and clones like
> CENTOS which have released binary compatible kernels.
>
> July 1st. It's increasingly hard to run linux without binary modules on
> most new consumer PCs. While a year earlier people would have to give up
> 3D acceleration for this often, now even 2D doesn't work without binary
> drivers, nor does networking (both fixed wire or wireless) or sound. For
> half the machines there is not enough linux support available at all,
> while 20% use ndiswrapper like translation layers to run the Windows
> sound and networking drivers. The Debian project, unable to run on most
> machines now, is losing massive amounts of users to Ubuntu and
> Ubuntu-Debian hybrids. Debian-legal and various other project lists are
> impossible to read by people not interested in this particular
> flame-topic. Most of the vendors who kept their open source drivers at
> least somewhat updated have basically stopped doing so.
>
> July 14th. Linus declares the kernel ABI stable but also splits off a
> 2.7 kernel and declares that the 2.8 kernel will have a different ABI.
> In practice, only people who held on to their old machines can assist in
> the 2.7 development, since none of the vendor drivers, not even the ones
> who still have a blob+glue construct care about the 'too rapid' moving
> development tree.
>
> August 21st. A serious security flaw is found in the 2.6 series, which
> turns out to be a design flaw in a key sysfs API. Fixing this flaw would
> require to break the module ABI and practically all modules out there,
> while not fixing this flaw leaves a potential roothole open. A quick fix
> is made available under a CONFIG_ option, but users who need binary
> drivers have no choice but leave their systems vulnerable. Flamewars on
> lkml flare up again that say Linus made a mistake in freezing the
> existing ABI rather than creating a new one designed to be frozen. 2.7
> development has mostly stagnated and a patch is proposed to have 2.7
> have the 2.6 ABI again, reverting several key VM subsystem improvements
> and Ingo's realtime patches.
>
> August 26th. A precooked exploit for the security hole hits bugtraq, and
> has been sighted in the wild as used by various rootkits. A php exploit
> uses it to go from the httpd user to root. Users are putting pressure on
> module vendors to release modules for the new ABI, and several actually
> do so in the next three weeks. Others, mostly in the consumer area, say
> that the hardware in question is no longer sold and that they aren't
> going to spend any time or effort on drivers for it.
>
>
>
>
>
>
> Now this scenario may sound unlikely to you. And thankfully the main
> assumption (the December 6th event) is extremely unlikely.
>
> However, and this unfortunately, several of the other "leaps" aren't
> that unlikely. In fact, some of these results are likely to happen
> regardless; witness the flamewars on lkml about breaking module API/ABI.
> Witness the ndiswrapper effect of vendors now saying "we support linux
> because ndiswrapper can use our windows driver". I hope they won't
> happen. Some of that hope will be idle hope, but I believe that the
> advantages of freedom in the end are strong enough to overcome the
> counter forces.
>
>
Zwane Mwaikambo
> Which is the best reason in the world to buy and use, the open source
> video card now under development, and I hear its less than 3-4 months
> from production status now, and at a competitive, sub $150 USD price.
>
> If 50% of nvidia's currant linux market share were to dissappear a month
> after this card becomes available for purchase by those whom one might
> categorize as believers, I'd think that would send a message loud enough
> to be heard.
>
> Particularly if windows drivers are available, open sourced, and
> installable on a winderz box using the normal install wizard, and
> promoted as such to the joe six-packs of the world. At the right price,
> that would send an even louder message to both nvidia and ati
Do you think this opensource hardware could keep up with nvidia and ati
hardware development? Joe sixpack is all about the fastest hardware.
Greg KH
> Dave Airlie wrote:
> >>To the larger argument about supporting binary drivers,
> >>all Arjan manages to prove with his post is that,
> >>if handled in the worst possible way, support for
> >>binary drivers would be a disaster. Who can disagree
> >>with that?
> >>
> > And do you think that given the opportunity, any company is going
> > spend the extra money required to not do it in the worst possible
> > way??
>
> I meant "handled in the worst possible way by
> the kernel developers". It *is* possible to define
> stable APIs and have them used successfully.
>
> POSIX is not the greatest example, but it seems
> to work OK. I realize that drivers are more
> tightly bound to the kernel than are libraries
> or applications, but sheesh, this is not rocket
> science.
For people to think that the kernel developers are just "too dumb" to
make a stable kernel api (and yes, I've had people accuse me of this
many times to my face[1]) shows a total lack of understanding as to
_why_ we change the in-kernel api all the time. Please see
Documentation/stable_api_nonsense.txt for details on this.
thanks,
greg k-h
[1] My usual response is, "If we are so dumb, why are you using the kernel
made by us?", which usually stops the conversation right there.
Greg KH
> I don't believe that most drivers are derivative works
> of the operating systems they run with, and I don't
> believe it helps Linux to assert that they are.
> But, hey, it's not my kernel, and not my plan for
> world domination. ;-)
Why do people bring up the "derivative works" issue all the time. Are
they so blind to the very simple "linking" issue that all kernel modules
do when they are loaded into the kernel?
That's the much simpler reason for why numerous IP lawyers of big
companies that do Linux work feel that closed source Linux kernel
modules are not legal.
thanks,
greg k-h
Michael Poole
> On Mon, Dec 05, 2005 at 03:56:06PM -0800, Tim Bird wrote:
> > DISCLAIMER: I'm not speaking for Sony here. Personally
> > I don't believe that most drivers are derivative works
> > of the operating systems they run with, and I don't
> > believe it helps Linux to assert that they are.
> > But, hey, it's not my kernel, and not my plan for
> > world domination. ;-)
>
> Why do people bring up the "derivative works" issue all the time. Are
> they so blind to the very simple "linking" issue that all kernel modules
> do when they are loaded into the kernel?
Most likely people bring up the "derivative works" issue because
that's what the GPL says it affects. The FSF contends that linking
creates a derivative work, but is curiously quiet when people ask for
statutory or case law to support that claim.
Besides, if the act of linking is what makes the derivative work,
there is no problem: The GPL allows a user to make any modifications
or combinations or derivatives whatsoever, and only imposes
requirements when the result is distributed. The linking of the two
works occurs only on the end user's machine.
Michael Poole
Gene Heskett
>On Mon, 5 Dec 2005, Gene Heskett wrote:
>> Which is the best reason in the world to buy and use, the open source
>> video card now under development, and I hear its less than 3-4 months
>> from production status now, and at a competitive, sub $150 USD price.
>>
>> If 50% of nvidia's currant linux market share were to dissappear a
>> month after this card becomes available for purchase by those whom
>> one might categorize as believers, I'd think that would send a
>> message loud enough to be heard.
>>
>> Particularly if windows drivers are available, open sourced, and
>> installable on a winderz box using the normal install wizard, and
>> promoted as such to the joe six-packs of the world. At the right
>> price, that would send an even louder message to both nvidia and ati
>
>Do you think this opensource hardware could keep up with nvidia and ati
>hardware development? Joe sixpack is all about the fastest hardware.
That I've no knowledge of. The developers are claiming pretty decent
performance from the breadboards now, in the top 85% I'd guess, but go
check their site for clarification on that. As to keeping up with new
hardware, if the sales support it, then even newer ones will always be
in the pipeline. The key to success is as always, sales propaganda in
Joe Six-packs face, and that, no surprise, costs money. So when it is
released, support it if you want to keep it alive. To me, thats a no
brainer. But who am I but an old fart on SS... If I can afford it,
certainly lots of you younger folks can too. Putting our money where
our mouth is makes perfect sense to me and I'll do it at least once.
Maybe 3 times as I have 3 boxes here.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Brian Gerst
> On Mon, Dec 05, 2005 at 09:31:30AM -0500, Brian Gerst wrote:
>> The problem with this statement is that Linux users are a drop in the
>> bucket of sales for this hardware. Boycotting doesn't cost the vendors
>> enough to make them care. And this does nothing for people who are
>> converting over to Linux, and didn't buy hardware with that
>> consideration in mind.
>
> Effectively this is why 3d drivers are the only thing we litearlly lost
> control of. But my email was general. I wasn't only speaking of 3d
> hardware.
>
> For 3d you're very well right, but once linux becomes mainstream in the
> desktop, things could change.
>
> Also note, I've some 3d on my laptop but I need no binary only drivers
> for it, so there's some option.
Intel? That's all nice and dandy if and only if you have an Intel CPU.
Not an option for AMD users, for obvious reasons.
--
Brian Gerst
Al Viro
> the kernel developers". It *is* possible to define
> stable APIs and have them used successfully.
>
> POSIX is not the greatest example, but it seems
> to work OK. I realize that drivers are more
> tightly bound to the kernel than are libraries
> or applications, but sheesh, this is not rocket
> science.
You do realize that any attempt to create a stable API (which would
reduce the amount of exported symbols by factor of 50 to start with)
will have the parties currently advocating interface stability screaming
bloody murder?
Who do you think had been responsible for current mess? The people
who kept adding random exports with no rationale beyond "it's needed
for our code", that's who...
Willy Tarreau
> For people to think that the kernel developers are just "too dumb" to
> make a stable kernel api (and yes, I've had people accuse me of this
> many times to my face[1]) shows a total lack of understanding as to
> _why_ we change the in-kernel api all the time. Please see
> Documentation/stable_api_nonsense.txt for details on this.
It's not about being dumb, but this problem is -I think- what prevents
some companies from releasing drivers for their hardware (when they
don't consider that opening it will give their IP away). I've played
several times with opensource drivers for ADSL modems, LCD modules,
watchdogs, ethernet adapters, IDE drivers, etc... and their problem
was that what worked well in 2.4.21 did not even build in 2.4.22
and became difficult to fix starting with 2.4.23. Most of those
small companies who propose a Linux driver simply start by paying
a student during summer for porting their windows/sco/whatever
driver to linux. They think the job is done when he leaves.
Unfortunately, they receive complaints 3 months later from users
because the driver is broken and does not build. They don't have
the resources to keep a permanent developer on it, and they
quickly understand that Linux is just a "geek OS" and that it's
the last time they release any driver.
Of course, you'll tell me that they can write the driver for
the major stable distros (RHEL, SLES, ...). But when they
don't really understand what Linux is, do you believe it's the
student who will tell them "I should write it for RHEL" ? No.
The student will decide "I will write it for vanilla kernel
and test it on my Debian because I hate proprietary systems".
Anyway, those who write drivers for RHEL have no problem
keeping them closed because their users generally don't
expect to read the sources.
> thanks,
>
> greg k-h
>
> [1] My usual response is, "If we are so dumb, why are you using the kernel
> made by us?", which usually stops the conversation right there.
I've already heard a funny response to this : "Usually I use *BSD, but
right now for an unknown reason, it does not install on this strange
machine, so I was FORCED to install Linux, but I will remove it once
I can fix my BSD" :-) It's the same as people who complain about windows
all the day and use it all the day.
Regards,
Willy
Rob Landley
> On Mon, 2005-12-05 12:18:34 -0500, Jeff Garzik <jga...@pobox.com> wrote:
> > >Linux in a binary world
> >
>
> Um, let's write an binary emulator for those archs. It did work for
> Alphas executing i386 code, so it'd work for PPC, too :-)
Fabrice Bellard beat you to it, QEMU, and yes it's GPL.
Trying to bolt it to the kernel would deeply suck.
Rob
--
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
Neil Brown
> On Mon, Dec 05, 2005 at 08:08:20PM -0800, Greg KH wrote:
>
> > For people to think that the kernel developers are just "too dumb" to
> > make a stable kernel api (and yes, I've had people accuse me of this
> > many times to my face[1]) shows a total lack of understanding as to
> > _why_ we change the in-kernel api all the time. Please see
> > Documentation/stable_api_nonsense.txt for details on this.
>
> It's not about being dumb, but this problem is -I think- what prevents
> some companies from releasing drivers for their hardware (when they
> don't consider that opening it will give their IP away). I've played
> several times with opensource drivers for ADSL modems, LCD modules,
> watchdogs, ethernet adapters, IDE drivers, etc... and their problem
> was that what worked well in 2.4.21 did not even build in 2.4.22
> and became difficult to fix starting with 2.4.23. Most of those
> small companies who propose a Linux driver simply start by paying
> a student during summer for porting their windows/sco/whatever
> driver to linux. They think the job is done when he leaves.
> Unfortunately, they receive complaints 3 months later from users
> because the driver is broken and does not build. They don't have
> the resources to keep a permanent developer on it, and they
> quickly understand that Linux is just a "geek OS" and that it's
> the last time they release any driver.
>
> Of course, you'll tell me that they can write the driver for
> the major stable distros (RHEL, SLES, ...).
I won't tell you that.
I'd say that with a linux driver, the job isn't done it "works", but
rather the job is done when it "is merged".
Once it is merged, it will mostly be updated along with the rest of
the kernel, and if it breaks silently, there is probably someone
available who can fix it.
I think we should frown on out-of-tree drivers nearly as much as
closed-source drivers.
NeilBrown
Coywolf Qi Hunt
Your response is nonsense. It has the same logic as saying "If
proprietary software is wrong, why are you using it?".
Everybody are using proprietary software, aren't they?
If the pattern goes in A->B .... ->A, then the developers are really dumb.
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
David Woodhouse
> Most of those small companies who propose a Linux driver simply start
> by paying a student during summer for porting their
> windows/sco/whatever driver to linux. They think the job is done when
> he leaves. Unfortunately, they receive complaints 3 months later from
> users because the driver is broken and does not build. They don't have
> the resources to keep a permanent developer on it, and they quickly
> understand that Linux is just a "geek OS" and that it's the last time
> they release any driver.
If they hired someone who did a _proper_ job -- writing a fully portable
and maintainable driver which got merged into Linus' kernel, then this
scenario doesn't make much sense. In-kernel code does generally get
maintained as interfaces change.
Of course, maintaining a driver _outside_ the kernel tree is a
never-ending task -- but why would anybody ever want to do that?
--
dwmw2
Arjan van de Ven
> On Mon, Dec 05, 2005 at 04:18:51AM -0800, William Lee Irwin III wrote:
> > The December 6 event is extraordinarily unlikely. What's vastly more
> > likely is consistent "erosion" over time. First the 3D video drivers,
> > then the wireless network drivers, then the fakeraid drivers, and so on.
>
> I agree about the erosion.
>
> I am convinced that the only way to stop the erosion is to totally stop
> buying hardware that has only binary only drivers (unless you buy it to
> create an open source driver or to reverse engineer the binary only
> driver of course! ;).
this only works if more people than "just Andrea and Arjan" do it
though.
>
> For example if a laptop has an embedded wirless or 3d card not supported by
> open source drivers, buy a laptop without any wireless card or without
> 3d, instead of buying one with the not-supported hardware without using
> it (I can guarantee there are still laptops that requires no 3d
> binary only drivers and no wirless cards drivers, even for the winmodems
> you can choose the ones supported by alsa). We literally have to refuse
> buying those cards with binary only kernel drivers.
I fully agree; I bought a centrino based laptop recently (from Dell),
because Intel did a most excellent job of getting all the parts I use
supported fully. That was actually my primary purchase criterium.
Several other vendors didn't get my sale because they had no decent
supported laptop. (eg ati or nvidia video or some at-the-time driverless
wireless)
> The fact Arjan got the "nvidia fanboy" complaining, is the sign that
> some people just don't care. This understandable for a 3d kind of
> product which is 90% for entertainment (nobody loses money when it
> crashes), and we generally can't expect everyone to care about the long
> term kernel development.
lately a trend started where linux users consider it normal to use
binary drivers. Not only for 3D, but for everything. To the point where
in discussions about the gpl bcm43xx driver in development they feel
it's useful to chime in by saying "just use ndiswrapper instead", in
fact that's the standard answer on mailinglist on ANY wireless issue
nowadays it seems. There is an atmosphere that it's the duty of the
kernel developers to keep nvidia and ndiswrapper and all other binary
drivers working, anyone who even suggests different is a fundamentalist
GPL terrorist. (if you think that I'm overreacting, just for fun read
the forum on heise.de about this mail/article; this article apparently
is very fundamentalist). Nowadays people get upset and start calling
names if you point then at the nvidia forums instead of given them the
exact answer they want on $whatevermailinglist.
So while I fully agree with your "we shouldn't buy the unsupported
hardware" I fear that that no longer is happening in practice, not even
on the server side anymore, where some of the linux-friendly hardware
vendors now sell machines which require binary only modules to run and
call it fully linux certified and don't even mention anywhere that it
needs such modules, or that those modules are only available for RHEL or
SLES.
Greetings,
Arjan van de Ven
Bernd Petrovitsch
> On Tue, 2005-12-06 at 07:07 +0100, Willy Tarreau wrote:
> > Most of those small companies who propose a Linux driver simply start
> > by paying a student during summer for porting their
> > windows/sco/whatever driver to linux. They think the job is done when
> > he leaves. Unfortunately, they receive complaints 3 months later from
> > users because the driver is broken and does not build. They don't have
> > the resources to keep a permanent developer on it, and they quickly
> > understand that Linux is just a "geek OS" and that it's the last time
> > they release any driver.
>
> If they hired someone who did a _proper_ job -- writing a fully portable
> and maintainable driver which got merged into Linus' kernel, then this
Then you have to motivate the management that it the initial development
cost is (roughly) doubled because of the process to get it accepted into
the kernel (instead of having a bloated converted driver from $OTHER_OS
which works just now somehow). And they didn't realize that bitrotting
is much faster in the free world then in the old-economy (i.e. Win*).
> scenario doesn't make much sense. In-kernel code does generally get
> maintained as interfaces change.
Yes, most of them (until the maintainer vanishes and after a year of
not-compiling-since-no-one-apparently-cares a patch to delete it is
submitted).
> Of course, maintaining a driver _outside_ the kernel tree is a
> never-ending task -- but why would anybody ever want to do that?
-) Because it was never accepted (yes, there are lots of reasons here -
some are more valid, some are less valid as seen by the
company/management financinf this)?
-) Because the have drivers + user-space libs for several OSes and want
to keep them as similar and working together as possible?
-) __________________
And probably a few more (sane reasons, not insane reasons).
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Xavier Bestel
> > The _GPL tag is useful as an hint to binary only vendors as as such it
> > makes perfect sense.
> Well, if it makes sense to have developers giving out legal
> advice, then I guess so.
You seem to imply that kernel developers have no legitimity to give a
hint on how to use what *they* created.
Dirk Steuwer
> The problem with this statement is that Linux users are a drop in the
> bucket of sales for this hardware. Boycotting doesn't cost the vendors
> enough to make them care. And this does nothing for people who are
> converting over to Linux, and didn't buy hardware with that
> consideration in mind.
>
> The only way to break the stalemate is to reverse engineer drivers.
> Turning the screws tighter isn't going to make open drivers magically
> appear. More likely, the vendors will abandon Linux as being too
> hostile and/or too costly to support, leaving everybody back at square one.
>
> --
> Brian Gerst
>
I see binary drivers as a problem, too.
How does a customer find out, if a piece of Hardware works in the free software
world? Yes there are a few places, where you find a hardware compatibility list,
but these are scattered and often incomplete. And they only include hardware
that someone thinks is working, added a couple of month after sales launch.
The only solution is to create pressure on these companies, as suggested.
Ideally, there should be a label "designed for Linux" (or "designed for free
software" (maybe getting the bsd people on board as well?)) straight on the box.
So customers that start to care about linux, can see this right away and make
the right choice, when buying hardware.
And because the driver is already included/licensed before the product makes it
into the shelves, its a plug and play scenario for the customer. They don't need
to worry about drivers at all. Stick it in and it just works(tm).
This would be a real value added in favor of linux for the customer and could
create some real pressure on companies with binary only drivers.
Which Authority would be best to release such a Label?
Regards,
Dirk
Alexander E. Patrakov
>
>>On Monday 05 December 2005 10:52, Arjan van de Ven wrote:
>>
>>>a hypothetical doomsday scenario by Arjan van de Ven
>>>
>>
>
>
> I got one too many hatemails from a "nvidia fanboy" who blamed me for
> just about anything wrong in the world.... I fear that most of these
> people have no idea why open source drivers matter, or at least what the
> consequences are for not caring about drivers being open or not.
I guess that such people also use drivers without Microsoft's digital
signature in Windows and don't understand where their bluescreens come
from. So talking to them is a wasted effort.
--
Alexander E. Patrakov
Bernd Petrovitsch
> Andrea Arcangeli wrote:
> >[...]
> > The _GPL tag is useful as an hint to binary only vendors as as such it
> > makes perfect sense.
> Well, if it makes sense to have developers giving out legal
> advice, then I guess so.
Lots of patent attorneys and average law persons gives advices on
technical stuff (where they effectively have no idea what's really going
on) so it *must* be legitimate the other way 'round.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
-
David Woodhouse
> Lots of patent attorneys and average law persons gives advices on
> technical stuff (where they effectively have no idea what's really
> going on) so it *must* be legitimate the other way 'round.
I think Tim's right to suggest that we shouldn't be giving that kind of
advice. Especially when we are so inconsistent about it, and when our
opinion is irrelevant.
If your lawyers advise you that using a given symbol from your
binary-only module was OK when it was exported with EXPORT_SYMBOL, then
that situation _cannot_ change when we switch it to EXPORT_SYMBOL_GPL;
we're simply not _allowed_ to impose additional restrictions. The only
thing that changes is the _amount_ of trouble you are in if the court
disagrees with your lawyers, because now you've actively circumvented a
technical protection measure in order to violate our copyright.
That protection is the only real difference between EXPORT_SYMBOL() and
EXPORT_SYMBOL_GPL(), once you realise that it can't change the legal
status of the export in question, and you discount the 'advice' which we
shouldn't be giving anyway.
Since the protection of EXPORT_SYMBOL_GPL() is only relevant if you are
actually found to be in violation of the licence, we might as well be
using it for all symbols. If you fervently believe that binary-only
modules are legal, you can still go ahead and use them. It's just that
you'd better be _very_ sure of yourself before you do so, because if you
_do_ lose in court you'll be getting more than a slap on the wrist.
By switching in the opposite direction, Linus is actively weakening our
position, and I object very strongly to that.
--
dwmw2
Jeff Garzik
> Since the protection of EXPORT_SYMBOL_GPL() is only relevant if you are
> actually found to be in violation of the licence, we might as well be
> using it for all symbols. If you fervently believe that binary-only
> modules are legal, you can still go ahead and use them. It's just that
> you'd better be _very_ sure of yourself before you do so, because if you
> _do_ lose in court you'll be getting more than a slap on the wrist.
>
> By switching in the opposite direction, Linus is actively weakening our
> position, and I object very strongly to that.
Linus made a pragmatic technical decision for the benefit of a bunch of
Linux users, a decision I support despite the fact that NVIDIA are a
bunch of sillyheads.
Realistically, no position was weakened, nothing new happened.
In the context of the larger thread, the doomsday scenario is highly
unlikely because of positive engineering attributes of open source.
Smart companies want open source drivers not because people snipe at
them verbally and legally, but because the process produces superior
engineering in the end.
Jeff
Sander
> Let's not forget they make money selling the hardware, the binary only
> driver is free.
The driver is not free. You paid for it when you bought the card. The
driver is just as free as the tires on the car you just bought.
--
Humilis IT Services and Solutions
http://www.humilis.net
Sander
> The only solution is to create pressure on these companies, as suggested.
> Ideally, there should be a label "designed for Linux" (or "designed for free
> software" (maybe getting the bsd people on board as well?)) straight on the box.
> So customers that start to care about linux, can see this right away and make
> the right choice, when buying hardware.
Quite a few companies state on their site that their hardware is
supported in Linux if it is.
And I've never bought any computer equipment in a shop. Always online,
where there is no such thing as a box anyway :-)
--
Humilis IT Services and Solutions
http://www.humilis.net
Luke-Jr
> When this happens, vendors will just have to solve all the IP nonsense
> associated with their hardware, or design hardware to be more dependent on
> firmware so that largely open source drivers are more feasible for them.
That just moves the problem. Now, there is yet even more concern that they
should release source for the firmware.
--
Luke-Jr
Developer, Utopios
http://utopios.org/
Jean-Christian de Rivaz
> Which is the best reason in the world to buy and use, the open source
> video card now under development, and I hear its less than 3-4 months
> from production status now, and at a competitive, sub $150 USD price.
Can you post a link about this open source video card ? I strongly wants
to support this kind of project. It's clear for me: this is the only way
to solve the problem in the long term.
Thanks,
--
Jean-Christian de Rivaz
Arjan van de Ven
>
>
> On 12/6/05, Andrea Arcangeli <and...@suse.de> wrote:
> On Mon, Dec 05, 2005 at 09:31:30AM -0500, Brian Gerst wrote:
> drop in the
> > bucket of sales for this hardware. Boycotting doesn't cost
> the vendors
> > enough to make them care. And this does nothing for people
> who are
> > converting over to Linux, and didn't buy hardware with that
> > consideration in mind.
>
> litearlly lost
> control of. But my email was general. I wasn't only speaking
> of 3d
> hardware.
>
> For 3d you're very well right, but once linux becomes
> mainstream in the
> desktop, things could change.
>
> mainstream in the desktop area. In fact It's adopted in offices, by
> governments and schools for security, reliability and openoffirce.org
> (low $$).
but... "proper hardware support" can be open source, that's the whole
point! Everyone considering binary only support "full" causes the entire
problem of not being able to run without binary modules anymore, which
in turn means you're either stuck with enterprise distro kernels, or
linux is stuck with a kernel that can't be developed on anymore in a 2.7
style series.
Nobody is arguing that hardware shouldn't be supported, to the contrary.
I and others are arguing that short term binary only "support" isn't
real support in the long term, and in both the long and short term leads
to a significant reduction in choice. Note: NVidia right now is nice
enough to do the blob+glue layer thing. Many others don't, they only
provide modules for certain enterprise distros. Now those schools and
governments of course run those enterprise distros... but what does that
gain in the end? Security? It doesn't; several of these binary modules
actually introduce security holes (the most famous one is an old 3D
driver of a company I won't name that had a "make me root" ioctl).
Price? Well those enterprise distribution companies need to make money
somehow... so while the price may be lower... you're stuck to them
again..
> So , without some sort of effort from kernel developers, things
> arent going to change.
I would turn this around; without some sort of effort from the USERS,
things aren't going to change. As long as USERS don't use their purchase
power to urge vendors that linux and open source are important, nothing
is going to improve. Going binary is not a long term improvement! It's
more like a quick shot of heroin that makes you feel better today,
rather than going to a psychiatrist who helps you out of your depression
for the rest of your life.
> There could be, for example, a limited but stable API for
> external/binary stuff. This could force hardware vendors to lately use
> the current API for better performance and thus releasing drivers with
> an open layer a la NVIDA & c. or even opensource.
doesn't work; such a limited api wouldn't be used by the majority of
those modules, simply because most of them want to touch internals for
some reason (probably lack of judgement and just because they can, but
still)
Arjan van de Ven
> > I would turn this around; without some sort of effort from the USERS,
> > things aren't going to change. As long as USERS don't use their
> > purchase power to urge vendors that linux and open source are
> > important, nothing is going to improve.
>
> are still a small community, so I see it complicated using our power
> to change vendor's minds.
it worked in the past.. and the linux community got bigger. lots bigger.
Now the hard part is getting the "newcomers" care about this and also
help to convince the vendors, rather than blindly accepting that
ndiswrapper and nvidia blobs are the right way.
Denis Vlasenko
> On Mon, Dec 05, 2005 at 04:18:51AM -0800, William Lee Irwin III wrote:
> > The December 6 event is extraordinarily unlikely. What's vastly more
> > likely is consistent "erosion" over time. First the 3D video drivers,
> > then the wireless network drivers, then the fakeraid drivers, and so on.
>
> I agree about the erosion.
>
> I am convinced that the only way to stop the erosion is to totally stop
> buying hardware that has only binary only drivers (unless you buy it to
> create an open source driver or to reverse engineer the binary only
> driver of course! ;).
I'm afraid there is not enough Linux users in desktop/laptop market
for vendors to notice.
How about refusing binary-only modules instead? I mean, maybe
if Linux will stop being lax about GPL requirements on modules.
--
vda
Ralf Baechle
> On Monday 05 December 2005 18:44, Alistair John Strachan wrote:
> > When this happens, vendors will just have to solve all the IP nonsense
> > associated with their hardware, or design hardware to be more dependent on
> > firmware so that largely open source drivers are more feasible for them.
>
> That just moves the problem. Now, there is yet even more concern that they
> should release source for the firmware.
ACPI is a demonstration why firmware is not the answer.
Ralf
Rudolf Randal
new license called GPL_HARD - with a clause that would make all
linking to the kernel illegal if not in open source. Any vendor who
doesnt comply could be arrested and flown off to a detention camp on
some remote island without the right to legal council. We could borrow
some old planes from the US postal service..
These vendors could be interrogated until they reveil their
specifications for their hardware.
I vote for hard interrogation - if they wont tell they could be forced
to wear tux-outfits and listen to badly ripped mp3´s until they talk.
These vendors constitutes an axes of evil and are a real threat to the
security on a lot of machines.
To all vendors - you are either with us or against us!
--
Rudolf Randal - Hässleholmsgatan 3B lgh 503 - 214 43 Malmö - Sweden -
Phone: +46 (0)76 234 05 77
Ralf Baechle
> > What if.. what if the linux kernel developers tomorrow accept that
> > binary modules are OK and are essential for the progress of linux.
> >
> [...]
> > Now this scenario may sound unlikely to you. And thankfully the main
> > assumption (the December 6th event) is extremely unlikely.
> >
> > However, and this unfortunately, several of the other "leaps" aren't
> > that unlikely. In fact, some of these results are likely to happen
> > regardless; witness the flamewars on lkml about breaking module API/ABI.
> > Witness the ndiswrapper effect of vendors now saying "we support linux
> > because ndiswrapper can use our windows driver". I hope they won't
> > happen. Some of that hope will be idle hope, but I believe that the
> > advantages of freedom in the end are strong enough to overcome the
> > counter forces.
> And some embedded companies provide the minimal source code to put
> in arch and everything else (ethernet, adsl, wifi, ...) is binaries
> modules.
Provide a one time source drop to show what good GPL citizen they are,
then let it rot away making sure the average user will have to pay their
bill ...
Ralf
Brian Gerst
Once again I'd like to point out that user's purchase power means jack
when they only have two choices for video: ATI and Nvidia. You can't
walk into a computer store and find anything else (I don't count
integrated video on the motherboard as a solution, since only Intel
boards have it, sorry AMD users). Even over the web it's hard to find
anything else. I'm not trying to defend closed source here, but you
people just have to face the reality that trying to use the market to
get our way is just not going to work with video. The only way forward
is reverse engineering. We aren't going to get help from the vendors so
we have to help ourselves.
--
Brian Gerst
Rudolf Randal
Well - reverse engineering isnt gonna get any easier over time .. as
hardware gets more complex and bus speed increases it will become more
and more impossible to do any probing?. There also isnt any way to
ensure that vendors wont go down the m$ way as on the xbox or xbox360
and encrypt data between chips to protect their IP.
Most likely that will prevent the reversely engineered driver from
getting out in time before the next generation of hardware arrives ?
--
Rudolf Randal - Hässleholmsgatan 3B lgh 503 - 214 43 Malmö - Sweden -
Phone: +46 (0)76 234 05 77
linux-os (Dick Johnson)
When the linux-BIOS group started, few knew where to start. Then,
mysteriously, there was a complete directory tree of a well-known
BIOS that appeared on the web. That was a start.
Want video drivers? I would suggest starting a Linux-video group.
Start with a few hacks of some reverse-engineered stuff then I
guess some help will mysteriously appear, especially if the
blob/glue stuff is done in that group, too. A video board company
doesn't care about operating systems! They care about selling
boards. The easier it is to relate to their video hardware, the
more likely help will be forthcoming.
Also, you are still likely to have a blob/glue system because
the blob is the stuff that needs to be uploaded to the FPGA upon
startup! Although serial eproms are cheap, few PC/Board vendors
will spend the money to put the blob on the board where it belongs.
So, usually it needs to be bit-banged into the device upon startup.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.44 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to Deliver...@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Aimo Asiakas
>
>[1] My usual response is, "If we are so dumb, why are you using the kernel
> made by us?", which usually stops the conversation right there.
should not be using
their kernel. There are alternatives that are open source and equally good
if not better (BSD, Solaris).
Linux is made for the members of the Linux community (family) who understand
how important it is to get all the hardware details and other trade secrets
made available public domain. This is a live and death issue to the
community because it lmakes it possible to hackers to continue to hack.
Binary (only) drivers are considered evil because then may cause the
hardware information flow to hackers to stop forever. Linux should be made
the dominating desktop OS so that stupid hardware companies will be forced
to realize that resistence is futile.
But what do the desktop customers (the ones who should start using Linux)
expect? We would expect that Linux works with the hardware we have or
whatever we decide to buy. And more important we expect that the
applications we need are available for Linux. Do we care about hackers'
right to free hardware information? No. This means that we users are
complete morons and we should be brainwashed to realize how cool thing Linux
is.
So the conclusion is that we (potential) customers should grow up to the
level where we can fully understand the importance of the Linux movement.
The kernel community in turn does the right thing in trying to enforce pure
GPL even if it causes some unavoidable damage to usability of Linux. Linux
will sooner or later dominate the desktop. Until that happens we we users
should support the effort of the development community and happily suffer
from hardware compatibility problems (or user some less state-of-the-art
hardware). Or should we?
As I said maybe Greg's opinion is correct. We stupid morons should let the
kernel guys to play with their nice sandbox in whatever way they like. We
don't contribute anything to the kernel so we definitely don't have any vote
on what they do or don't do. We should stop raising idiotic issues like
unbanning binary only drivers. Instead by moving to some other open source
kernel we can improve the S/N ratio of this mailing list. This gives the
kernel community good working peace to build as pure GPL kernel as they
like.
Regards,
Aimo
_________________________________________________________________
Nopea ja hauska tapa lähettää viestejä reaaliaikaisesti - MSN Messenger.
http://messenger.msn.fi
Arjan van de Ven
> applications we need are available for Linux. Do we care about hackers'
> right to free hardware information? No.
In my article I tried to explain to you why you SHOULD care. If you can
get your drivers ONLY for the SLES/RHEL distros... would you be happy
with that? Are you currently running RHEL or SLES? If not, why not? If
you have a reason for that... then maybe you shouldn't be happy about
the direction things are going either!
Open drivers are NOT just for hackers. GET THAT? They are there for YOU
as well. So that YOU can run whatever linux you want, not just today but
also tomorrow and next month and later. Maybe you don't want to read the
source code, maybe you're no programmer at all and don't know how to
read it. Yet even if you use nvidia and ndiswrapper you depend on the
rest of the kernel drivers to be open to run the distribution you want,
and not RHEL or SLES.
Maybe saying this makes me a fundamentalist GPL terrorist (as some have
called me as reaction to the article I wrote). To some degree I don't
care, I've been called worse.
But I am hoping that people like you (and I don't mean that in any
negative way) start to realize why you can run the linux you want today,
and that embracing binary drivers as a good thing will threaten that
ability in the future.
Andrea Arcangeli
> [..] we might as well be
> using it for all symbols [..]
Cool, so if we use it for all symbols it will add zero information to
the kernel. Which means it's exactly the same as if we nuke _GPL tag
completely and we remove it from all symbols.
I always thought the _GPL tag isn't needed and can be removed, your
suggestion to add it to all symbols confirms it. Furthermore its
existence is a sort of proof that you can legally link the kernel with
non-GPL modules (which Greg disagrees with, I don't have an opinion, I
only know Linus said binary only drivers are ok as long as they don't
create a derivative of the kernel).
I don't think the GPL tag can make somebody more or less illegal, it's
just irrelevant. This is just a favour we make to those companies, and
that they may also not trust in the first place because we're not
lawyers in the first place.
> By switching in the opposite direction, Linus is actively weakening our
> position, and I object very strongly to that.
I think Linus is doing the right thing here, and he is avoiding what I
described in the previous email: that is breaking drivers gratuitously
is what could make linux hostile and too costly to support IMHO. We want
to be parnters with all hardware companies, but we want them to support
linux properly (not with binary only drivers), in a way that we can fix
it, port it to other archs, and so that we don't lose support for the
hardware while improving internal APIs.
Also note, that if we lose control on the development (the doomsday
scenario) everybody else loses control too, it's not like somebody can
bank on it and steal the control and profit from it and pay lots of
taxes to the US governament. Everybody will lose and wealth will be
destroyed globally and less taxes will be paid in all countries
worldwide. All those hardware companies compete against each other, so
each one will have control on a little tiny piece of the OS, so when a
bug triggers in the doomsday secnario, the thing will become
undebuggable for everyone (at best everyone can blame on each other when
there's random memory corruption). That again may be acceptable for a
desktop, but I doubt it's acceptable for servers.
Arjan van de Ven
> when they only have two choices for video: ATI and Nvidia. You can't
> walk into a computer store and find anything else (I don't count
> integrated video on the motherboard as a solution, since only Intel
> boards have it, sorry AMD users). Even over the web it's hard to find
> anything else.
(resending this since it seems the other mail didn't get anywhere)
Sure. But that doesn't mean there is no purchase power. HP, Dell and IBM
and co DO have purchasing power over NVidia and ATI. If they tell ATI or
NVidia to either go open source (unlikely) or rearchitect their drivers
to do the "hot IP" in userspace, it will happen. And YOU can influence
Dell and HP and IBM again. By complaining to their sales people. By
letting them know binary modules aren't going to cut it. Not just for
video, but for EVERYTHING. Once the Dell/HP/IBM sales people hear enough
of "binary isn't good enough", the message will get through, and those
vendors in turn will crank up the pressure.
And enough people have influence when at work a linux desktop is
purchased (assumption I make here is that that's not going to be used
for 3D games), at such occasions you CAN influence the vendors and let
them know that the "binary" cards aren't an option.
There are lots of opportunities to put pressure on vendors, either
direct or indirect. Nvidia has a support department. If they get enough
calls / letters about their solution not being good enough, they're more
likely to consider the rearchtect solution.
On the other hand, if everyone just accepts it and praises them for
being a good citizen.. things will never change, and wireless is next.
Then audio. Then SATA. Then USB sticks. Then Networking.
Mark Lord
> I believe the only real thing to do is release all new kernels under a
> new license called GPL_HARD - with a clause that would make all
Nice theory, but thank (insert favourite deity here) that the GPL
protects us from this ever happening!
Andrea Arcangeli
> are still a small community, so I see it complicated using our power
> to change vendor's minds.
Why not using the vendor that ships hardware that requires no binary
only driver?
I know there is the option to remove the embedded wireless card ;).
Better not to have it than to pay for it without using it. A bluetooth
usb dongle costs only a dozen dollars anyway.
Andrea Arcangeli
> Once again I'd like to point out that user's purchase power means jack
> when they only have two choices for video: ATI and Nvidia. You can't
> walk into a computer store and find anything else (I don't count
The single fact you looked to see if there was something else is a very
good thing. As wrote in the other email, with their binary only drivers
those companies are increasing their risk of introducing more
competition into the 3d space, they open up a niche. I know I wouldn't
take this risk if I was in them.
Pavel Machek
> >Every time we buy a piece of hardware with binary only drivers we admit
> >that the binary only driver vendors are doing the right choice for their
> >stockholders. Only when we refuse to buy it, we can make a slight
> >difference.
> >When we don't buy hardware without open source drivers, we send the
> >message to the shareholders that the management is causing them a loss.
>
> The problem with this statement is that Linux users are a drop in the
> bucket of sales for this hardware. Boycotting doesn't cost the vendors
> enough to make them care. And this does nothing for people who are
Actually, yes it does cost them. If you refuse to buy $2000 notebook,
because its 3D graphics card ($100) is not supported properly... well
notebook vendor is going to put pressure on graphics card vendor.
And you don't have to be Linux user to refuse closed hardware. Having
option in future is always good.x
Pavel
--
Thanks, Sharp!
David Woodhouse
> On Tue, Dec 06, 2005 at 09:56:43AM +0000, David Woodhouse wrote:
> > [..] we might as well be using it for all symbols [..]
>
> Cool, so if we use it for all symbols it will add zero information to
> the kernel. Which means it's exactly the same as if we nuke _GPL tag
> completely and we remove it from all symbols.
>
> I always thought the _GPL tag isn't needed and can be removed, your
> suggestion to add it to all symbols confirms it.
In terms of information, you're right -- there's no point in having both
of them.
However, the _GPL tag does mean that someone who wants to violate the
licence has to deliberately circumvent the protection, and cannot plead
ignorance. That does have an effect in court, albeit after the basic
question of guilt or innocence has been decided.
> Furthermore its existence is a sort of proof that you can legally link
> the kernel with non-GPL modules (which Greg disagrees with, I don't
> have an opinion, I only know Linus said binary only drivers are ok as
> long as they don't create a derivative of the kernel).
I happen to agree with Greg's opinion, and not with Linus'. But
obviously there is no 'right' answer until/unless it comes to court.
But yes -- its existence is indeed a 'sort of proof' that non-GPL
modules are at least _considered_ to be OK in some situations. I wish
we'd never invented EXPORT_SYMBOL_GPL() in the first place -- it appears
to legitimise something which was never really OK in the first place,
and weakens our position when we take it to court.
> I don't think the GPL tag can make somebody more or less illegal, it's
> just irrelevant. This is just a favour we make to those companies, and
> that they may also not trust in the first place because we're not
> lawyers in the first place.
True -- that's what I've said many times. The point, however, is that
the GPL tag provides a measure of protection which the violator would
have to _deliberately_ circumvent. That doesn't directly affect the
licensing question, but it does change the _penalties_ which a court
would impose if a vendor of non-GPL'd modules who is found to be
violating the GPL.
Maybe a vendor will have deep pockets and a penchant for risk, and will
still be happy to bypass the protection afforded by EXPORT_SYMBOL_GPL --
maybe with MODULE_LICENSE("GPL\0not really") or by other means. But the
_default_ would be that non-GPL modules would not work, and having to
circumvent the protection would make them stop and think _very_ hard
before doing it.
> > By switching in the opposite direction, Linus is actively weakening our
> > position, and I object very strongly to that.
>
> I think Linus is doing the right thing here, and he is avoiding what I
> described in the previous email:
He's also doing what you described in the email to which I'm reply --
reinforcing a 'sort of proof' that what they're doing is OK, by going
out of his way to accommodate them.
> that is breaking drivers gratuitously is what could make linux
> hostile and too costly to support IMHO.
Supporting Linux with binary-only drivers _is_ hostile and costly.
And it wouldn't be _broken_ -- they could still rebuild the kernel
without the checks, or make their module pretend to be licensed under
the GPL to bypass the EXPORT_SYMBOL_GPL() protection. Of course, they'd
have to be _very_ sure of their lawyers' interpretation of the GPL if
they were going to do that.
By switching to EXPORT_SYMBOL_GPL for everything, we put the onus upon
the vendors of such modules to be _very_ sure of themselves and the risk
they're taking before continuing to release such modules. I don't think
that's a bad thing.
> We want to be parnters with all hardware companies, but we want them
> to support linux properly (not with binary only drivers), in a way
> that we can fix it, port it to other archs, and so that we don't lose
> support for the hardware while improving internal APIs.
Allowing binary-only drivers only harms that goal, in the long term.
> Also note, that if we lose control on the development (the doomsday
> scenario) everybody else loses control too, it's not like somebody can
> bank on it and steal the control and profit from it and pay lots of
> taxes to the US governament. Everybody will lose and wealth will be
> destroyed globally and less taxes will be paid in all countries
> worldwide. All those hardware companies compete against each other, so
> each one will have control on a little tiny piece of the OS, so when a
> bug triggers in the doomsday secnario, the thing will become
> undebuggable for everyone (at best everyone can blame on each other when
> there's random memory corruption). That again may be acceptable for a
> desktop, but I doubt it's acceptable for servers.
I think we're digressing somewhat, but you seem to be agreeing that
binary-only modules are generally a bad thing. We have a tool available
to us to discourage their proliferation -- the licence under which the
kernel is released. That's the whole _point_ of the GPL, in fact.
So what's wrong with the suggestion that we make _use_ of that rather
than continuing to not only tolerate violations, but go out of our way
to aid and abet the violators?
--
dwmw2
Florian Weimer
> Once again I'd like to point out that user's purchase power means jack
> when they only have two choices for video: ATI and Nvidia. You can't
> walk into a computer store and find anything else (I don't count
> integrated video on the motherboard as a solution, since only Intel
> boards have it, sorry AMD users). Even over the web it's hard to find
> anything else.
What about Matrox cards? Are there open drivers for accelerated 2D
operation?
Hannu Savolainen
> How about refusing binary-only modules instead? I mean, maybe
> if Linux will stop being lax about GPL requirements on modules.
Or why not to include an embedded version of gcc/binutils in the kernel
LKM interface. In this way all drivers can only be distributed in source
code which effectively makes all forms of binary only drivers impossible.
After that all the EXPORT_SYMBOL_GPL nonsense can be removed and a proper
DDI layer can be implemented for Linux. This makes it possible to ship
"outside the kernel build" drivers without a risk of major
incompatibility problems in the next kernel version. No, I'm not 100%
serious but just 50%.
Best regards,
Hannu
-----
Hannu Savolainen (ha...@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
Pekka Enberg
On 12/6/05, Aimo Asiakas <aimo.a...@hotmail.com> wrote:
> But what do the desktop customers (the ones who should start using Linux)
> expect? We would expect that Linux works with the hardware we have or
> whatever we decide to buy. And more important we expect that the
> applications we need are available for Linux. Do we care about hackers'
> right to free hardware information? No. This means that we users are
> complete morons and we should be brainwashed to realize how cool thing Linux
> is.
As Arjan said, this is not about the developers, it is about all of
us. While you're not interested in the availability of hardware
documentation, surely you do care if you can still run free software
on your machine in two years from now? Closed hardware documentation
means that you have to rely on your vendor to update the driver which
is not in their interest if they have a new product out which they
want you to buy. Nor will the driver be updated if the vendor has gone
out of business.
See, if you want to be able to walk in the store and buy whatever you
want and have it work on Linux (or any other open source kernel for
that matter), you're absolutely in favor of open hardware
documentation. You just haven't realized it yet.
Pekka
Paweł Sikora
> * Brian Gerst:
> > Once again I'd like to point out that user's purchase power means jack
> > when they only have two choices for video: ATI and Nvidia. You can't
> > walk into a computer store and find anything else (I don't count
> > integrated video on the motherboard as a solution, since only Intel
> > boards have it, sorry AMD users). Even over the web it's hard to find
> > anything else.
>
> What about Matrox cards? Are there open drivers for accelerated 2D
> operation?
Open 2D is nothing new. The OpenGL is a major part.
Matrox and XGI (e.g. Volari V3 based cards) have openGL parts closed.
--
to_be || !to_be == 1, to_be | ~to_be == -1
Greg KH
> > [1] My usual response is, "If we are so dumb, why are you using the kernel
> > made by us?", which usually stops the conversation right there.
>
> proprietary software is wrong, why are you using it?".
> Everybody are using proprietary software, aren't they?
Um, no, not at all. The logic is, "you trust these developers enough to
want to run their code, controlling the most basic and secure portions
of your machines, yet you think they are incapable programmers?"
And no kernel developers are forcing anyone to use Linux. If they don't
like it for whatever reasons, there are other alternatives...
thanks,
greg k-h
Jon Smirl
> Linux in a binary world
Why not start our own Linux doomsday? Give the closed source vendors
exactly what they fear the most, a patent lawsuit. Whining will get us
nowhere, hitting the vendor's revenue stream will get you anything you
want.
US patent infringement provides the giant sledgehammer of having a
court issue an injunction stopping the shipment of product that is in
litigation over patent infringement. Note that it does not have to be
proven that the the patents are valid. RIM is very close to having an
injunction issued against it even though it is likely that the patents
they are accused of violating will be found invalid.
The game plan is simple. IBM and Intel hold enough hardware patents to
take down any hardware company these choose. Donate one or two key
patents to the FSF with a rule that they can't be used against the
company that donated them. The FSF then moves for a patent
infringement injunction against ATI, NVidia or other closed source
vendor.
The target company gets a choice:
1) open source the drivers and hardware. As a sweetener contribute a
patent to the pool and aim the FSF at the next domino. In exchange the
suit will be dropped.
2) Endure the lawsuit and hope the FSF doesn't get a $450M settlement
like NTP is getting from RIM. Meanwhile watch your stock price tumble
since the injunction prevents you from shipping product.
--
Jon Smirl
jons...@gmail.com
Simon Oosthoek
>
>>On Monday 05 December 2005 10:52, Arjan van de Ven wrote:
>>
>>>a hypothetical doomsday scenario by Arjan van de Ven
>>>
>>
>>Can I ask what prompted your post?
>
>
> I got one too many hatemails from a "nvidia fanboy" who blamed me for
> just about anything wrong in the world.... I fear that most of these
> people have no idea why open source drivers matter, or at least what the
> consequences are for not caring about drivers being open or not.
>
>
I suppose this is as good as any point in the thread to add my 2
eurocents...
I use nvidia cards, mostly because they work better than an alternative
for now, but every time I need a card I look for stuff that is more
open, because I hate to have to use the non-free closed stuff to do
graphics. (Having no real choice in this is really annoying to me!)
I believe the kernel community has a great leverage point on these
proprietary vendors (although I don't know how far this goes), by
changing the ABI/API fairly often, they will have to adjust their driver
building tools as well. This will become annoying to them and may cause
them to free some more parts of their code. This is not a full solution,
but at least it will cause them to rethink their policies more often.
Alternatively, I'd be willing to pay some more money than for an
equivalent closed source driver card, to get good hardware with a GPL
driver. I may not be part of the majority of PC equipment buyers though ;-)
Cheers
Simon
Florian Weimer
> 2) Endure the lawsuit and hope the FSF doesn't get a $450M settlement
> like NTP is getting from RIM. Meanwhile watch your stock price tumble
> since the injunction prevents you from shipping product.
Unlike NTP[1], the FSF distributes real products and is vulnerable to
counterclaims.
[1] http://www.ntp.com/ belongs to a different company, AFAIK.
Dirk Steuwer
>
> Quite a few companies state on their site that their hardware is
> supported in Linux if it is.
>
> And I've never bought any computer equipment in a shop. Always online,
> where there is no such thing as a box anyway
>
Yes, but there isn't and won't be much recognition - every company does its own
thing. And how many people buy online all the time? But even then, a genery
"runs with Linux" Logo would be great. If a company's product is not certified,
its not considered by Linux customers.
Also you could hold up figures from certified hardware to impress and argue
against companies that think there is no real market for Linux.
There needs to be a way to breack out of the chicken and egg problem - no linux
market, no linux hardware.
Corporate Customers can afford to do research, expert staff does the buying. But
the average homeuser? He needs a generic sign, as simple as that.
Dirk
Jon Masters
> I know I have become a very disappointed ATI
> customer after figuring out that they have zero interest in me using
> the hardware I paid for on Linux...
I remember calling up ATI and speaking to the CEO's secretary back in
the late 1990s. They'd just started to help out the GATOS guys a
little back then and I decided that they cared more than Nvidia do
about Linux so I would continue to buy only ATI cards. The ATI/Nvidia
thing even determined which model of Powerbook I would buy (since the
12" model had an Nvidia chipset).
Now I'm just disgusted with them. I understand exactly why they've
done what they have, but it's very uncool. People should call them up
and ask them to reconsider their actions. Question: who can I pay
money to for graphics cards that don't have hobbled drivers?
Jon.
P.S. I'm not just being anti-ATI. There are many others who are far
far worse - but we need good vendor support for graphics now more than
we ever did if more people are going to enjoy a good desktop
experience when using Linux.
Greg KH
> It's not about being dumb, but this problem is -I think- what prevents
> some companies from releasing drivers for their hardware (when they
> don't consider that opening it will give their IP away). I've played
> several times with opensource drivers for ADSL modems, LCD modules,
> watchdogs, ethernet adapters, IDE drivers, etc... and their problem
> was that what worked well in 2.4.21 did not even build in 2.4.22
> and became difficult to fix starting with 2.4.23. Most of those
> small companies who propose a Linux driver simply start by paying
> a student during summer for porting their windows/sco/whatever
> driver to linux. They think the job is done when he leaves.
> Unfortunately, they receive complaints 3 months later from users
> because the driver is broken and does not build. They don't have
> the resources to keep a permanent developer on it, and they
> quickly understand that Linux is just a "geek OS" and that it's
> the last time they release any driver.
That's why Documentation/HOWTO was written, to help those people realize
what needs to be done in order to do it properly.
thanks,
greg k-h
Benjamin LaHaise
> Besides, if the act of linking is what makes the derivative work,
> there is no problem: The GPL allows a user to make any modifications
> or combinations or derivatives whatsoever, and only imposes
> requirements when the result is distributed. The linking of the two
> works occurs only on the end user's machine.
But if it's a module, it's probably been compiled against kernel headers.
Last time I checked, header files were covered by the GPL unless explicitly
placed under a more permissive license. How do you use something like
spinlocks without compiling in GPL code to a module?
-ben
--
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <do...@kvack.org>.
Jon Masters
> I am convinced that the only way to stop the erosion is to totally stop
> buying hardware that has only binary only drivers (unless you buy it to
> create an open source driver or to reverse engineer the binary only
> driver of course! ;).
That's not enough people to make a big enough difference - but I agree
with the logic and do my part.
One idea for dealing with this is to have the kernel complain more
loudly about binary only drivers - instead of using terms like "taint"
which Sysadmins might casually ignore it might be better to have a
couple of lines of warning message in their syslog explaining what it
means in more graphic terms. Granted that average users won't see this
but it would certainly help to convey the impression that binary only
is "wrong" (it's not putting policy in the kernel, it's embedded
politics in the kernel :P).
> I think messages like the one from Arjan are very positive to let
> people understand the long term effect of binary only drivers
I wrote a couple of articles this month which explain to the average
reader what is wrong with this and how it can be addressed. I used
Greg's mail as an example but will followup with a reference to this
thread - we need to encourage more people to talk about this.
> Perhaps we should add a printk that points to an url on kernel.org
> including Arjan's message every time a non-gpl module gets loaded by the
> kernel. I think it's a matter of educating the customer too or they can
> do mistakes, creating a blacklist would help too.
I like the idea of being far more graphic (no pun intended there) by
describing what this means in everyday language - "using binary only
drivers causes your machine to explode! (may not actually cause
machine to explode)" type stuff.
Jon.
Jesper Juhl
> On Mon, 5 Dec 2005, Gene Heskett wrote:
>
> > Which is the best reason in the world to buy and use, the open source
> > video card now under development, and I hear its less than 3-4 months
> > from production status now, and at a competitive, sub $150 USD price.
> >
> > If 50% of nvidia's currant linux market share were to dissappear a month
> > after this card becomes available for purchase by those whom one might
> > categorize as believers, I'd think that would send a message loud enough
> > to be heard.
> >
> > Particularly if windows drivers are available, open sourced, and
> > installable on a winderz box using the normal install wizard, and
> > promoted as such to the joe six-packs of the world. At the right price,
> > that would send an even louder message to both nvidia and ati
>
> Do you think this opensource hardware could keep up with nvidia and ati
> hardware development? Joe sixpack is all about the fastest hardware.
Well, they are not aiming at creating a high end gaming card.
Here are some quotes from various documents at http://www.opengraphics.org/ :
"
Requirements
In order to be interesting to the open source community and OEM
vendors such a card should at a minimum meet the following
requirements:
* Programming interface must be fully documented
* No IP encumberment for implementing drivers
* Very good 2d graphics performance
* Full OpenGL implementation with as much hardware acceleration as possible
* Good support for xv (yuv->rgb, scaling) for video playback
* Reasonable price!
"
"
Due to market size it will not be possible to compete on 3d
performance with market leaders such as ATI and NVIDIA. This is not an
immediate problem because gaming is not what this card is aimed at,
but performance should be good enough for scientific simulations and
similar.
"
"
1. *Will I be able to play Doom 3 with this hardware?*
Nope, but at the time of this writing, there is no graphics card on
the market on which you can play Doom 3 well while using open source
drivers. Less demanding games are likely to work however.
"
"
With about 6.4 gigabytes/second memory bandwidth, the video
performance should be comparable to current midrange graphic-cards
like the ATI Radeon 9600 which can e.g. play Battlefield 2.
"
Their featurelist also has more details:
http://wiki.duskglow.com/tiki-index.php?page=FeatureList
--
Jesper Juhl <jespe...@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
David Woodhouse
> Intel? That's all nice and dandy if and only if you have an Intel
> CPU. Not an option for AMD users, for obvious reasons.
Actually even the Intel support isn't particularly good. We don't have
proper mode setup code -- we have to invoke the BIOS to do mode setup,
and we can't set specific modelines (like PAL-compatible modes); we're
limited to what the BIOS knows about -- it's like vesafb with
acceleration.
There's some work on reverse-engineering the BIOS so that you can
hackishly poke 'new' modes into its tables, but it's still not a very
good option.
--
dwmw2
Luke-Jr
> Arjan van de Ven wrote:
> > On Mon, 2005-12-05 at 18:26 +0000, Andrew Walrond wrote:
> >>On Monday 05 December 2005 10:52, Arjan van de Ven wrote:
> >>>a hypothetical doomsday scenario by Arjan van de Ven
> >>
> >>Can I ask what prompted your post?
> >
> > I got one too many hatemails from a "nvidia fanboy" who blamed me for
> > just about anything wrong in the world.... I fear that most of these
> > people have no idea why open source drivers matter, or at least what the
> > consequences are for not caring about drivers being open or not.
>
> for now, but every time I need a card I look for stuff that is more
> open, because I hate to have to use the non-free closed stuff to do
> graphics. (Having no real choice in this is really annoying to me!)
The ATi Radeon 9200 works fine...
--
Luke-Jr
Developer, Utopios
http://utopios.org/
Lee Revell
> On Tue, 6 Dec 2005, Denis Vlasenko wrote:
>
> > How about refusing binary-only modules instead? I mean, maybe
> > if Linux will stop being lax about GPL requirements on modules.
> Or why not to include an embedded version of gcc/binutils in the kernel
> LKM interface. In this way all drivers can only be distributed in source
> code which effectively makes all forms of binary only drivers impossible.
Are you saying you'd open source all those binary only OSS drivers if
this were to happen?
Lee
Luke-Jr
> Your response is nonsense. It has the same logic as saying "If
> proprietary software is wrong, why are you using it?".
> Everybody are using proprietary software, aren't they?
No proprietary software here, excluding things such as firmware/BIOS where
there is no choice.
--
Luke-Jr
Developer, Utopios
http://utopios.org/
Lee Revell
> Sander <sander <at> humilis.net> writes:
> >
> > Quite a few companies state on their site that their hardware is
> > supported in Linux if it is.
> >
> > And I've never bought any computer equipment in a shop. Always online,
> > where there is no such thing as a box anyway
> >
>
>
> Yes, but there isn't and won't be much recognition - every company does its own
> thing. And how many people buy online all the time? But even then, a genery
> "runs with Linux" Logo would be great. If a company's product is not certified,
> its not considered by Linux customers.
The vendors will just lie like they do now. For example M-Audio claims
all its products are supported under Linux but leave out the fact that
half of it had to be reverse engineered, lots of it still doesn't work
right for lack of docs, and whenever someone asks them about Linux
support they just punt to the ALSA mailing lists.
Lee
Tomasz Torcz
> Dnia wtorek, 6 grudnia 2005 16:30, Florian Weimer napisał:
> > * Brian Gerst:
> > > Once again I'd like to point out that user's purchase power means jack
> > > when they only have two choices for video: ATI and Nvidia. You can't
> > > walk into a computer store and find anything else (I don't count
> > > integrated video on the motherboard as a solution, since only Intel
> > > boards have it, sorry AMD users). Even over the web it's hard to find
> > > anything else.
> >
> > What about Matrox cards? Are there open drivers for accelerated 2D
> > operation?
>
> Open 2D is nothing new. The OpenGL is a major part.
> Matrox and XGI (e.g. Volari V3 based cards) have openGL parts closed.
Interesting remark, but false. Xorg ships open source driver with full
3D acceleration suport forMatrox.
--
Tomasz Torcz "Never underestimate the bandwidth of a station
zdzichu@irc.-nie.spam-.pl wagon filled with backup tapes." -- Jim Gray
Zwane Mwaikambo
> On 12/6/05, Zwane Mwaikambo <zw...@arm.linux.org.uk> wrote:
> > On Mon, 5 Dec 2005, Gene Heskett wrote:
> >
> > > Particularly if windows drivers are available, open sourced, and
> > > installable on a winderz box using the normal install wizard, and
> > > promoted as such to the joe six-packs of the world. At the right price,
> > > that would send an even louder message to both nvidia and ati
> >
> > Do you think this opensource hardware could keep up with nvidia and ati
> > hardware development? Joe sixpack is all about the fastest hardware.
>
> Well, they are not aiming at creating a high end gaming card.
>
> Here are some quotes from various documents at http://www.opengraphics.org/ :
My reply was to his email and not in reference to opengraphics.org
Theodore Ts'o
> On Mon, Dec 05, 2005 at 03:56:06PM -0800, Tim Bird wrote:
> > DISCLAIMER: I'm not speaking for Sony here. Personally
> > I don't believe that most drivers are derivative works
> > of the operating systems they run with, and I don't
> > believe it helps Linux to assert that they are.
> > But, hey, it's not my kernel, and not my plan for
> > world domination. ;-)
>
> Why do people bring up the "derivative works" issue all the time. Are
> they so blind to the very simple "linking" issue that all kernel modules
> do when they are loaded into the kernel?
The linked kernel+module combination is pretty clearly a derived work
(but I am not a lawyer). However, that never gets *distributed* and
the GPL only covers distribution rights.
The question of whether or not something which *could* be linked into
the kernel is a derived work is a very different question, and if
taken too far, an advocate of this interpretation starts advocating
something very close to interface copyrights --- something which I
will note the FSF is passionately against when they called a boycott
on companies such as Lotus many years ago.
But this is very much off-topic for this list. I suggest that folks
talk to Larry Rosen for his view on this issue, if they want a
balanced counterpoint to that pushed by the FSF.
- Ted
Jesper Juhl
> Gene Heskett a écrit :
>
> > Which is the best reason in the world to buy and use, the open source
> > video card now under development, and I hear its less than 3-4 months
> > from production status now, and at a competitive, sub $150 USD price.
>
> to support this kind of project. It's clear for me: this is the only way
> to solve the problem in the long term.
>
--
Jesper Juhl <jespe...@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Paweł Sikora
> On Tue, Dec 06, 2005 at 04:49:14PM +0100, Paweł Sikora wrote:
> > Dnia wtorek, 6 grudnia 2005 16:30, Florian Weimer napisał:
> > > * Brian Gerst:
> > > > Once again I'd like to point out that user's purchase power means
> > > > jack when they only have two choices for video: ATI and Nvidia. You
> > > > can't walk into a computer store and find anything else (I don't
> > > > count integrated video on the motherboard as a solution, since only
> > > > Intel boards have it, sorry AMD users). Even over the web it's hard
> > > > to find anything else.
> > >
> > > What about Matrox cards? Are there open drivers for accelerated 2D
> > > operation?
> >
> > Open 2D is nothing new. The OpenGL is a major part.
> > Matrox and XGI (e.g. Volari V3 based cards) have openGL parts closed.
>
> Interesting remark, but false.
I investigated only mtx driver from theirs website.
> Xorg ships open source driver with full 3D acceleration suport forMatrox.
For which card?
Jesper Juhl
> On Tue, 6 Dec 2005, Jesper Juhl wrote:
>
> > On 12/6/05, Zwane Mwaikambo <zw...@arm.linux.org.uk> wrote:
> > > On Mon, 5 Dec 2005, Gene Heskett wrote:
> > >
> > > > Particularly if windows drivers are available, open sourced, and
> > > > installable on a winderz box using the normal install wizard, and
> > > > promoted as such to the joe six-packs of the world. At the right price,
> > > > that would send an even louder message to both nvidia and ati
> > >
> > > Do you think this opensource hardware could keep up with nvidia and ati
> > > hardware development? Joe sixpack is all about the fastest hardware.
> >
> > Well, they are not aiming at creating a high end gaming card.
> >
> > Here are some quotes from various documents at http://www.opengraphics.org/ :
>
> My reply was to his email and not in reference to opengraphics.org
>
Ok, then I misunderstood your mail.
--
Jesper Juhl <jespe...@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Jeff Garzik
> Once again I'd like to point out that user's purchase power means jack
> when they only have two choices for video: ATI and Nvidia. You can't
> walk into a computer store and find anything else (I don't count
> integrated video on the motherboard as a solution, since only Intel
> boards have it, sorry AMD users). Even over the web it's hard to find
> people just have to face the reality that trying to use the market to
> get our way is just not going to work with video. The only way forward
> is reverse engineering. We aren't going to get help from the vendors so
> we have to help ourselves.
It sure looks that way.
Let's hope the rev-eng people do it the right way, by having one team
write a document, and a totally separate team write the driver from that
document.
Jeff