Compatibility of Nvidia NVNET driver license with GPL
Hello
I faintly remember reading some article on the Net from Linus Torvalds stating something like if a piece of code is written specifically for Linux kernel, it must be under GPL.
I have got an nVidia NForce2 board and downloaded their Ethernet driver (nvnet) and they say in README: "the network driver provided by NVIDIA is subject to the NVIDIA software license". How is with compatibility of such a behaviour with GPL of the kernel sources?
Cl<
Quoted 10 lines · Karel Kulhavý
Hello
I faintly remember reading some article on the Net from Linus Torvalds stating something like if a piece of code is written specifically for Linux kernel, it must be under GPL.
I have got an nVidia NForce2 board and downloaded their Ethernet driver (nvnet) and they say in README: "the network driver provided by NVIDIA is subject to the NVIDIA software license". How is with compatibility of such a behaviour with GPL of the kernel sources?
Since I am not a lawyer, my engineering suggestion would be to sidestep legal issues by using "forcedeth" driver, to drive your nForce NIC. It's fully GPL'd, and full open source.
Jeff
Quoted 13 lines · Jeff Garzik
Quoted 10 lines · Karel Kulhavý
Hello
I faintly remember reading some article on the Net from Linus Torvalds stating something like if a piece of code is written specifically for Linux kernel, it must be under GPL.
I have got an nVidia NForce2 board and downloaded their Ethernet driver (nvnet) and they say in README: "the network driver provided by NVIDIA is subject to the NVIDIA software license". How is with compatibility of such a behaviour with GPL of the kernel sources?
Quoted 3 lines
Since I am not a lawyer, my engineering suggestion would be to sidestep legal issues by using "forcedeth" driver, to drive your nForce NIC. It's fully GPL'd, and full open source.
Suppose we would like to overcome these perpetual problems with misbehaving manufacturers by designing a PCI network card from scratch in the soul of free source hardware.
What are the requirements of the kernel for such a card to be cool instead of piece of shit? How should such a card behave from PCI point of view, should it support scatter, gather, how should interrupts be handled, what should be programmable and what not? How should be busmastering implemented?
I am seriously thinking about designing something like that (tailored specially for Linux) because of developping Ronja - if I included native Ronja support in "my" network card, I could remove the superfluous circuits that implement "bureaucracy" linke autonegotiation, TP link integrity etc. and concentrate on raw performance. Also multiple ports could be on one card (say 4) which would make the whole thing more nifty.
I have made to work the whole design chain from schematic design to production of raw files for PCB manufacturers. Also seen a design of video capture board for IDE connector so I judge implementing something on a PCI should'n be a pain in the ass higher than moderate.
Is it possible to obtain some PCI specs without NDA's and such bullshit? Is here anyone who has taken the PCI specs and rewritten them in their own words?
Cl<
Quoted 10 lines
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 35 lines · Karel Kulhavý
Quoted 8 lines · Jeff Garzik
Quoted 6 lines · Karel Kulhavý
Hello
I faintly remember reading some article on the Net from Linus Torvalds stating something like if a piece of code is written specifically for Linux kernel, it must be under GPL.
Quoted 7 lines
Quoted 4 lines
I have got an nVidia NForce2 board and downloaded their Ethernet driver (nvnet) and they say in README: "the network driver provided by NVIDIA is subject to the NVIDIA software license". How is with compatibility of such a behaviour with GPL of the kernel sources?
Since I am not a lawyer, my engineering suggestion would be to sidestep legal issues by using "forcedeth" driver, to drive your nForce NIC. It's fully GPL'd, and full open source.
Suppose we would like to overcome these perpetual problems with misbehaving manufacturers by designing a PCI network card from scratch in the soul of free source hardware.
What are the requirements of the kernel for such a card to be cool instead of piece of shit? How should such a card behave from PCI point of view, should it support scatter, gather, how should interrupts be handled, what should be programmable and what not? How should be busmastering implemented?
I am seriously thinking about designing something like that (tailored specially for Linux) because of developping Ronja - if I included native Ronja support in "my" network card, I could remove the superfluous circuits that implement "bureaucracy" linke autonegotiation, TP link integrity etc. and concentrate on raw performance. Also multiple ports could be on one card (say 4) which would make the whole thing more nifty.
Quoted 4 lines
I have made to work the whole design chain from schematic design to production of raw files for PCB manufacturers. Also seen a design of video capture board for IDE connector so I judge implementing something on a PCI should'n be a pain in the ass higher than moderate.
If you are serious about this, we have tons of good ideas, and tons of suggestions on how to avoid bad ideas :)
OpenCores (http://www.opencores.org/) might be a good place to start, as they already have a 10/100 ethernet MAC which is working, and has been silicon'd: http://www.opencores.org/projects/ethmac/ Full "source" for the MAC is available, in VHDL I think. OpenCores also has PCI VHDL and other glue you may need.
You'll definitely want to implement autonegotiation. It's a showstopper without that. And if it's not gigabit ethernet, it's already outdated.
So it's a tough challenge.
Once you have basic gigabit ethernet working with 10/100/1000 autonegotiation, let us know, and we'll pelt you with good suggestions :)
Quoted 3 lines
Is it possible to obtain some PCI specs without NDA's and such bullshit? Is here anyone who has taken the PCI specs and rewritten them in their own words?
You don't need an NDA, but you do need to pay US$50 or so for the specs.
Or a nice person might just send them to you :)
Jeff
Hi!
Quoted 9 lines
If you are serious about this, we have tons of good ideas, and tons of suggestions on how to avoid bad ideas :)
OpenCores (http://www.opencores.org/) might be a good place to start, as they already have a 10/100 ethernet MAC which is working, and has been silicon'd: http://www.opencores.org/projects/ethmac/ Full "source" for the MAC is available, in VHDL I think. OpenCores also has PCI VHDL and other glue you may need.
Quoted 3 lines
You'll definitely want to implement autonegotiation. It's a showstopper without that. And if it's not gigabit ethernet, it's already outdated.
So it's a tough challenge.
AFAIK, Clock is developing ethernet-over-infrared-over-300meters-of-air. It knows what is at the other end, and probably does not need autonegotiation. It is probably not going to be gigabit, either. [Current version that works is 10mbit over ~300meters].
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 15 lines · Pavel Machek
Hi!
Quoted 9 lines
If you are serious about this, we have tons of good ideas, and tons of suggestions on how to avoid bad ideas :)
OpenCores (http://www.opencores.org/) might be a good place to start, as they already have a 10/100 ethernet MAC which is working, and has been silicon'd: http://www.opencores.org/projects/ethmac/ Full "source" for the MAC is available, in VHDL I think. OpenCores also has PCI VHDL and other glue you may need.
Quoted 3 lines
You'll definitely want to implement autonegotiation. It's a showstopper without that. And if it's not gigabit ethernet, it's already outdated.
So it's a tough challenge.
Quoted 5 lines
AFAIK, Clock is developing ethernet-over-infrared-over-300meters-of-air. It knows what is at the other end, and probably does not need autonegotiation. It is probably not going to be gigabit, either. [Current version that works is 10mbit over ~300meters].
FWIW autonegotiation is strictly related to "the wire", so wireless would be a totally different space.
Jeff
nVidia's _video_ drivers are mostly proprietary code that is not specific to Linux. They provide a GPL wrapper or shim that, apparently in the view of their lawyers, insulates their proprietary code from GPL license terms.
Perhaps their network software is done the same way?
Signature · 3 lines
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373Quoted 6 lines · Paul Jackson
nVidia's _video_ drivers are mostly proprietary code that is not specific to Linux. They provide a GPL wrapper or shim that, apparently in the view of their lawyers, insulates their proprietary code from GPL license terms.
Perhaps their network software is done the same way?
It's a fair argument that nVidia has significant IP in their video drivers... I understand that's where they get a fair amount of their speed.
For a network driver, nVidia will have a really tough time convincing me there is useful IP in their NIC driver, or the NIC itself :) There are much more advanced NICs out there (with public docs, no less)...
Jeff
Quoted 6 lines · Jeff Garzik
For a network driver, nVidia will have a really tough time convincing me there is useful IP in their NIC driver, or the NIC itself :) There are much more advanced NICs out there (with public docs, no less)...
Jeff
Where might one look to find a list of these, for system planning purposes?
-chuck
On Fri, 2004-01-02 11:04:02 -0600, Chuck Campbell <[email protected]> wrote in message <[email protected]>:
Quoted 7 lines · Jeff Garzik
Quoted 4 lines
For a network driver, nVidia will have a really tough time convincing me there is useful IP in their NIC driver, or the NIC itself :) There are much more advanced NICs out there (with public docs, no less)...
Where might one look to find a list of these, for system planning purposes?
Personally, I like to buy tulip based cards. One you might easily get is the KTI KT-320 (or was it KF-320? Both exist, one is el-cheapo, the good one is at about 40..50 EUR or US-$).
Some time ago, I also used eepro100-based cards. But since Intel has started to put these into their chipset (as it seems with some additional silicone bugs, which freezes the box with eepro100, but not with working-around Intel's e100 driver) I don't use them any longer...
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));