| |||||||||||||
Plugging into GCCPlugging into GCCPosted Oct 3, 2008 21:33 UTC (Fri) by flewellyn (subscriber, #5047)Parent article: Plugging into GCC
I don't see what the big deal is; just have the "plugin API" require that the plugin module be linked to the GCC binary. Then the "linking" clause of the GPL takes hold. Easy enough.
(Log in to post comments)
Plugging into GCC Posted Oct 4, 2008 2:49 UTC (Sat) by i3839 (guest, #31386) [Link]
That won't work, for multiple reasons...
"linking clause" only works one way, so isn't relevant for the distribution of the binary plugin, only the GPL lib it's linked to (or if you prefer: "The whole work"). And it's easy to bypass.
Plugging into GCC Posted Oct 4, 2008 8:52 UTC (Sat) by drag (subscriber, #31333) [Link]
The 'linking clause' is very suspect anyways.
It's quite possible (although unlikely and unusual, unless the author is very careful) to have a piece of software that links with another and not be 'derived work' and therefore be quite out of bounds of any restriction any copyright-based license can impose, whether or not the language of the license allows it or not.
Remember that 'derived work' is defined in copyright law and in judge's opinions and not in any license.
Plugging into GCC Posted Oct 4, 2008 21:44 UTC (Sat) by chromatic (guest, #26207) [Link]
The question may depend on whether the distribution is in source form or binary form. The source code may not be a derivative work, while a binary may be. (This question is most interesting when considering NVIDIA's binary blob kernel module.)
Have you actually looked on what nVidia REALLY distributes? Posted Oct 5, 2008 7:39 UTC (Sun) by khim (subscriber, #9252) [Link] This question is most interesting when considering NVIDIA's binary blob kernel module This is real-world proof of successfull circunvention: nVidia is clearly in the clear here. No one ever said otherwise. Why? Simple: they distribute this "binary blob" as two parts: big closed-source driver and "public domain" glue code. The driver itself is not in violation of copyrights: it's not a derived work since the same blob can be used, for example, in Windows driver. Nothing Linux-specific there. Glue code is probably a derivative work of the Linux kernel, but... it's distributed without ANY restrictions and so is GPL-compliant. The real toxic thing is actual loadable kernel module - but nVidia does not distribute that (Canonical does), so nVidia is in the clear... The tiny amount of doubt remains: are binary blob and glue code really separate works? Court will decide but since both were created by nVidia problems in the interface (which can lead to derivativennes) are easy to fix...
Have you actually looked on what nVidia REALLY distributes? Posted Oct 5, 2008 12:34 UTC (Sun) by paulj (subscriber, #341) [Link]
it's not a derived work since the same blob can be used, for example, in Windows driver. Nothing Linux-specific there. What's the evidence for this btw? I know it's the generally accepted view, but what evidence is there for it, besides NVidias' confidence in being able to distribute this driver and the circumstantial evidence of some "looks like Windows programming style" symbol names? Is there any real independent evidence for this belief, or is being taken on trust?
No evidence. And it's probably not even true :-) Posted Oct 5, 2008 12:44 UTC (Sun) by khim (subscriber, #9252) [Link] Actually I think this blob differs slightly from what they ship in Windows driver. And I'm pretty sure even nVidia does not have Windows driver which uses this blob - but apparently they believe they can create such driver if court demands this. Realistically I do not expect deception here: if you have driver for Windows it's much easier to introduce glue code which will take it more-or-less unmodified then it's to create Linux-native driver. Think NDISwrapper. Linux developers will NEVER accept such driver in mainline - but this is not an issue for nVidia... Thus I'm pretty sure nVidia's blob IS what they have used for Windows driver - plus few small modifications here and there. Probably not enough to qualify as derivative of Linux kernel. And since the only reliable way to know (via court) is quite expensive... nobody bothers to actually check. Basically it all boils down the following three-step thought process:
Common misconception Posted Oct 5, 2008 6:57 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]
There is a common belief that a software license is unable extend requirements related to derivatives past some boundary because of some externally imposed definition of derivative. In cases where this reasoning is invoked it is usually wrong.
When a copyleft license says "Thou shall not froboz this package with software under a different license" it doesn't much matter that US law may not consider frobozing to be an action which causes the target to be a derivative work: Your ability to receive the rights granted by the license was conditional on following the rules and without those rights you're not able to do much involving that package.
This does potentially leave open the door for vendors of proprietary code intended to be linked into free software, but whom don't actually distribute the free software themselves. Unless it can be shown that the free software's license was required (i.e. if the module were a derivative work) only downstream distributors (or, potentially, users) who need the rights granted by the free license be in violation.
But in the context of copyleft licenses and linking-like activities the person doing the linking-like activity will almost always be distributing the copyleft license covered software. In these cases the license is pretty much free to define its own linking requirements and have them be completely enforceable, since their distribution of the covered software would be a copyright infringement without the rights granted by the license.
The flow chart is:
The misunderstanding comes from skipping straight to (2) without first considering (1).
It's not misconceptions - it's just omitted step Posted Oct 5, 2008 7:28 UTC (Sun) by khim (subscriber, #9252) [Link] The misunderstanding comes from skipping straight to (2) without first considering (1). May be some people (like drag above) have this misconception, but people actually involved (RMS and FSF) surely don't. They see nVidia, they see Broadcom and ask "how can we prevent THIS?" and "should we actually try to prevent THIS?". And yes - this IS about case where plugins developer does not distribute GCC itself... Sorry, but you are coming from wrong side. You are cosidring what is
convenient (of course distribution of proprietary plugin with GCC is more
convinient then distribution without GCC) and then think about
copyrights. The makers of proprietary plugins come from different side: Think about Microsoft/Novell deal: how proud Microsoft was when their lawers found the loophole which allowed them to sign a deal which was supposed to be prevented by GPL! It's security - you should always think about the "weak part"...
It's not misconceptions - it's just omitted step Posted Oct 6, 2008 1:59 UTC (Mon) by gmaxwell (subscriber, #30048) [Link]
I guess I should have named names: I was speaking of some of the upthread posters (and similar comments on past threads), and *not* the FSF. Obviously the FSF knows what they are doing here (see my post way up at the top).
It's not misconceptions - it's just omitted step Posted Oct 9, 2008 4:24 UTC (Thu) by lysse (guest, #3190) [Link] Can everyone who is not an experienced copyright lawyer please refrain from jumping up and down and loudly insisting that they know what the legal position is? You might have an opinion about what the legal position should be; that's fine - but to claim any more than that without the appropriate expertise overreaches.
Experienced copyright lawyer? Who's that? Why he's infallible? Posted Oct 9, 2008 7:49 UTC (Thu) by khim (subscriber, #9252) [Link] The fact is: "experienced copyright lawyers" often are wrong when they discuss copyright licenses too. They just prepend every sentence with "this is my opinion, if you want legal advice I'll need more detail" so their mistakes are overlooked. The only entity which can know the legal position is Supreme Court (by definition) - and then the relevant position will be true only in one country. And it'll be entirely too silly to just go in dark because we can not get supreme courts opinions on the GCC plugins matter. To even approach something resembling legal position you need understanding of both copyright and technology (think SCO: do you think they prepared their insane legal theories without help of copyright lawers?) - and such people are rare and not all of them have lawers degree. Thankfully one of them is working on the case and I hope soon we'll get something "official"...
Experienced copyright lawyer? Who's that? Why he's infallible? Posted Oct 9, 2008 13:38 UTC (Thu) by lysse (guest, #3190) [Link]
> The fact is: "experienced copyright lawyers" often are wrong
> when they discuss copyright licenses too.
But cluefulness is not binary, and they have rather more than you do.
Common misconception Posted Oct 9, 2008 20:15 UTC (Thu) by vonbrand (subscriber, #4458) [Link] What the copyright laws control is a narrow set of actions. I.e., distributing, or distributing derivative works. If "frobozing" doesn't involve those actions, the law is silent.
Common misconception Posted Oct 9, 2008 20:42 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
Although in the posed hypothetical, and in many practical cases, we're considering someone who both frobozzes and reproduces the covered work. Since the latter is a reserved right we must look to see if a license existed, and presuming the offered license was conditional on non-frobozification we would conclude that someone who frobozzes has no such license and can not legally practice any of the rights reserved to the copyright holder. Perhaps they have no interest in those activities, but that is not usually the case.
People who spread the belief that if frobozzing is not an aspect of copyright law that a copyright license can't be conditional on it are spreading misinformation.
|
|||||||||||||