Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Those are technically GPL violations, but kernel devs haven't (yet) complained much.


That is absolutely not the community consensus. Linus and the kernel community as a whole have taken the position that this is specifically allowed by the GPL as using a public interface isn't creating a derivative work.




If you use Wikipedia as source, please verify that the section you are referring has a source. Both now has citation needed tags on them.


It does not seem that there is a community consensus position.


I've been able to find a statement from 2008 in which many kernel devs publicly said they think that closed drivers are harmful. But violations?

I'm not convinced. Got a link that might convince me?


Depend which you want to listen to. If you want to listen to what lawyers think (fsf), then there is a GPL violation( https://www.gnu.org/licenses/gpl-faq.html#NonfreeDriverKerne...).

If you want to listen to kernel hackers, (such as Linus Torvalds), then he doesn't say if it is, or isn't a violation. Rather, he says that developers has a right to write non-free drivers to the kernel using modules (http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules....).

So... what does that mean? Im not a lawyer, but it looks to me as an GPL violation which has been given permission to exist by one of the kernel developers. That it is the project leader that gives permission does lower the risk that any individual kernel developer will suddenly go out and start suing companies for GPL violations, even if they has a legal right to do so under copyright.


Interesting.

The non-litigious nature of the kernel devs seems to keep this from kicking off. It would probably end up hysterically expensive for all concerned and be a bit of a PR failure I guess.


That FSF page also claims that Perl programs that use GPL'd Perl modules are required to be licensed under the GPL, and assorted other absurdities (hint: if there is no copying or modification of something copyrighted, there can be no copyright violation).

Contrary to the FSF's apparent belief, dependency has nothing to do with derivation.


Since FSF for years has had (and still have) lawyers advising them that this is indeed the case, what is your authority to claim otherwise?

Or, in other words, citation needed.


Firstly and most obviously, the FSF is clearly the only group that believes this garbage. Stop a minute and think about the consequences if coding to an interface made your program a derivative of whatever (first) implemented that interface... have these actually happened? does anyone even act as if they take the possibility seriously (outside the FSF's FUD)?

Remember the story of how IBM-compatible PCs came to be, with the clean-room reimplementation of the BIOS? That would be a copyright violation, except it clearly wasn't (or the clones would have been shut down). WINE and ReactOS would be copyright violations, and especially so given wanting to implement undocumented/non-public interfaces. Samba would be a copyright violation.

Any Win32 program that Microsoft didn't like, could be shut down as a copyright violation. So the browser wars would have been conducted rather differently. WordPerfect could have been blocked or forced to pay for licenses, instead of hindered by sneaky means.

IIRC the FSF claims support based on one case, where someone made singing children's toys and someone else made replacement ROMs (or maybe it was the whole electronic module?) to make them sing differently; the replacement parts were found to be a copyright violation because the performance that the toy put on, was found to be a derivative of the original performance. Which is still ridiculous (and IIRC other districts have found differently in a few similar cases involving video games), but even so does not support the FSF's extreme interpretation.


> [...] FSF is clearly the only group that believes this [...]

So, it should be no trouble for you to provide a citation from an legal authority which states otherwise?





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: