Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
"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)
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.
Posted Oct 4, 2008 21:44 UTC (Sat) by chromatic (guest, #26207)
Have you actually looked on what nVidia REALLY distributes?
Posted Oct 5, 2008 7:39 UTC (Sun) by khim (subscriber, #9252)
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
Posted Oct 5, 2008 12:34 UTC (Sun) by paulj (subscriber, #341)
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)
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:
1. It's easier to keep this blob as separate non-derivative work (then you can ship the same code for Windows and Linux and save on Q&A).
2. They are legally required to keep it in non-derivative state.
3. If it's both easier and required - then why nVidia will do it in any other way?
Posted Oct 5, 2008 6:57 UTC (Sun) by gmaxwell (subscriber, #30048)
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:
1) Did you distribute, modify, publicly perform, or otherwise execute a reserved right with the the covered work:
Yes) You must do whatever the license requires. Stop.
No) Continue on to (2)
2) Would a court consider what you distributed to be a derivative work?
Yes) You must do whatever the license requires and you should have answered Yes to the above, creating a derivative is a reserved right. Idiot. Stop.
No) Do whatever you want. Stop.
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)
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:
1) We want to distribute our "cool technology" as proprietary plugin to
2) Can we bundle them and distribute GCC and our cool technology
3) No? Well - too bad, we need chapter in documentation about downloading
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"...
Posted Oct 6, 2008 1:59 UTC (Mon) by gmaxwell (subscriber, #30048)
Posted Oct 9, 2008 4:24 UTC (Thu) by lysse (guest, #3190)
Experienced copyright lawyer? Who's that? Why he's infallible?
Posted Oct 9, 2008 7:49 UTC (Thu) by khim (subscriber, #9252)
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"...
Posted Oct 9, 2008 13:38 UTC (Thu) by lysse (guest, #3190)
But cluefulness is not binary, and they have rather more than you do.
Posted Oct 9, 2008 20:15 UTC (Thu) by vonbrand (subscriber, #4458)
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.
Posted Oct 9, 2008 20:42 UTC (Thu) by gmaxwell (subscriber, #30048)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds