[conspire] Another discussion of Linux/GPL and proprietary software
Rick Moen
rick at linuxmafia.com
Sun Jun 5 16:07:01 PDT 2011
Posted with John's blessing. John is a local longtime BSD activist
and friend.
Date: Thu, 2 Jun 2011 16:58:31 -0700
From: Rick Moen <rick at linuxmafia.com>
To: John Sokol <john.sokol at gmail.com>
Cc: Jesse Monroy <jesse650 at gmail.com>, Ted Walther <tederific at gmail.com>
Subject: Re: GPL
Organization: If you lived here, you'd be $HOME already.
X-Mas: Bah humbug.
User-Agent: Mutt/1.5.20 (2009-06-14)
Quoting John Sokol (john.sokol at gmail.com):
> Is there any authoritative sources for what is and isn't allowed under
> GPL and in Linux?
Your question is so unbelievably vague that nobody on Earth could give
it a meaningful answer, as stated. Your question does not even
distinguish between GPLv2 and GPLv3, and they have significant
differences.
You also use the word 'Linux' without specifying whether you're talking
about just the kernel (strict sense of the term) or entire non-Android
system based on the kernel (loose and common sense of the term).
There are other questions you might be trying to ask. You might be
trying to ask: 'What is and is not a derivative work?' You might be
asking 'What's the best course of action when a firm finds itself with a
copyright obligation to furnish matching source code under GPLv2 clause
3b, but business contract obligations make that painful and expensive?'
You might be trying to ask 'Which licences can combine with GPL[23]
for derivative works without copyright violation and without the need
for special permission grants to avert licence conflict?'
The general answer to 'What is allowed under GPL[23]' is 'Any
redistribution or creation of a derivative work that conveys to
recipients all rights required to be passed along by the terms of
GPL[23] concerning the work or derivative, and fulfilling GPL[23]
obligations.'
'Derivative work' is a legal term of art, defined by copyright caselaw.
If it's unfamiliar, read the CAI v Altai and Micro Star v. FormGen
decisions that I've linked from
http://linuxmafia.com/kb/Licensing_and_Law/ . Please ignore what FSF
says, as they tend to push what they _want_ 'derivative work' to mean.
(Clue: It has nothing to do with linking.)
For the rights that must be passed along for works encumbered by
GPL[23], and the obligations entailed, read GPL[23]. It's really not
difficult, honestly.
> I keep seeing big companies making all sorts of assumptions on this.
Examples?
C'mon, John. Give. Don't just hurl out lazy questions to get
free-of-charge consulting from friends, and not even telling us a few of
these for-instances.
Let me cast one out. Before MySQL AB was bought out by Sun and then Sun
was gobbled by Oracle, the company's (MySQL AB's) salesdroids used to
FUD potential customers into buying proprietary-usage licences for MySQL
deployments that combined MySQL with ancillary proprietary software such
as proprietary code running in their Web sites.
That company issued a MySQL database instance under GPLv2. It also
offered the same codebase as a separate instance under for-money
proprietary terms. This is a standard money-making model for which
copyleft licensing gets used. Problem is, MySQL AB's salesdroids tended
to outrageously overstate the reach of GPLv2's obligations in order to
(usually deceptively) motivate customers to purchase proprietary
licences.
Let's look at why I say that: The typical sales scenario would involve
the customer wishing to use the MySQL engine and its bundled access
libraries. All of those are GPL-encumbered unless the customer
purchases the for-money licence. The customer might be running some
sort of proprietary Java crud under IBM WebSphere, and seek to use MySQL
as the backend database.
The salesdroid say 'Well, you're using FastCGI calls (or PHP, or
whatever) to call the MySQL access libraries, which are GPLv2. So, all
of your routines and related software that talks to the access libraries
need to be GPLv2, or you're committing copyright violation and we might
sue you for damages. Unless you buy a licence, in which case everyone's
happy.'
But not so fast. Does talking to the MySQL access libraries via its
documented interface create a derivative work? Not in _this_ universe,
it doesn't. And if the particular means of access happened to be of
such nature as to create a derivative work, there are actually
alternative access libraries for MySQL that are under permissive
licences, thus averting the licence conflict problem.
The MySQL AB droid never told you those things. He or she didn't have
to, being a salesman.
This scenarios is not limited to copyleft, by the way. How do you know
that your particular use of proprietary-licensed work A is lawful and
that the coder won't sue you for some tort? You don't. You read the
damned licence, maybe understand a bit of tort law, and you get by
usually pretty well on fair dealing.
What _really_ happens when a firm finds itself caught in a bind under a
copyleft obligation? Don't wonder, read, since I've been there and have
documented it:
http://linuxmafia.com/faq/Licensing_and_Law/copyright-infringement.html
Date: Thu, 2 Jun 2011 17:10:35 -0700
From: Rick Moen <rick at linuxmafia.com>
To: John Sokol <john.sokol at gmail.com>
Cc: Ted Walther <tederific at gmail.com>, Jesse Monroy <jesse650 at gmail.com>
Subject: Re: GPL
Organization: If you lived here, you'd be $HOME already.
X-Mas: Bah humbug.
User-Agent: Mutt/1.5.20 (2009-06-14)
Quoting John Sokol (john.sokol at gmail.com):
> Ouch. So the question that keeps going by is: Code, libraries and
> drivers on Linux, for example.
So, for that, you have to determine what is and is not a derivative
work. See separate posting.
Elements of a work that exist for strictly functional reasons are not
eligible for copyright in the first place, nor are ones for
compatibility. Only 'expressive elements' that evince creative nature
give rise to copyright.
So, for example, Nvidia assert that they wrote their proprietary video
drivers for the Linux kernel (+ related X.org userspace driver) without
using any substantive creative / expressive elements from the Linux
kernel. That is a triable claim of fact. If any of the relevant
copyright holders ever brought an assertion of copyright violation to
trial, a judge would get to decide it.
Who would win? If I knew it would be Nvidia, I wouldn't tell them,
because I personally want them and all of the other publishers of cruddy,
buggy, unfixable, kernel-tainting hardware drivers for the Linux kernel
to feck off and Die In A Fire. So, I'm not offering advice for or about
them (and that includes ATI/AMD, Marvell, Broadcom), except that they
should grow up and get used to open source hardware drivers.
'Code'? 'Libraries'? I'm sorry, but I fail to see the relevance to
the Linux kernel.
(Again, you use 'Linux' without bothering to say what you mean.)
If running proprietary code or libraries on the Linux kernel were any
sort of legal problem -- _or even_ if there were a legal problem with
running such code/libs on Linux-based complete systems, you can bet that
several dozen companies would be siccing their lawyers onto Oracle
Corporation over Oracle RDBMS and its related support libraries.
So, I'm sorry if you are dealing with firms that don't get that, but
I suspect that in many cases it's much like 'tactical stupidity'
(http://linuxmafia.com/~rick/lexicon.html#tactical-stupidity), i.e.,
just a shoddy excuse for evading the issue.
Date: Sat, 4 Jun 2011 17:15:55 -0700
From: Rick Moen <rick at linuxmafia.com>
To: John Sokol <john.sokol at gmail.com>
Cc: Ted Walther <tederific at gmail.com>, Jesse Monroy <jesse650 at gmail.com>
Subject: Re: GPL
Organization: If you lived here, you'd be $HOME already.
X-Mas: Bah humbug.
User-Agent: Mutt/1.5.20 (2009-06-14)
Quoting John Sokol (john.sokol at gmail.com):
> Please forgive; it was after work and on my Android. Hard to type off
> a proper set of questions.
No problem!
> BTW: I love that lexicon page.
Thanks, I get a laugh out of some of its items, too.
(There's some pique in what follows, which is pretty much all intended
for proprietary-leaning companies who get whiney about copyleft. Please
don't take any of that as aimed at you personally, John, as it isn't.)
> I like the fact this this discussion is in writing that I can pick
> through later, rather then the hazy and difficult attempt to recall a
> conversation later and get 1/2 of it wrong or missing.
For the same reason, I like FAQing key analyses and statements onto/via
my Web site, so I hope you'll please spend some time reading through
this, as it answers many of your concerns better than I could possibly
do if I were to slog through the entire topic from scratch:
'Proprietary Kernel Modules' on http://linuxmafia.com/kb/Kernel
'Abstraction, Filtration, Comparison' and 'Derivative Works' on
http://linuxmafia.com/kb/Licensing_and_Law
'Licensing HOWTO' on http://linuxmafia.com/kb/Licensing_and_Law
'Copyright Infringement' on http://linuxmafia.com/kb/Licensing_and_Law
(both of them)
'GPL Violations' on http://linuxmafia.com/kb/Licensing_and_Law
Please in particular carefully read the first linked text file. It is a
series of posting from Linus Torvalds about writing and publishing
proprietary drivers for the Linux kernel, running from 1995 to 2002,
during which time his personal view on the subject wobbled maybe a _tiny_
bit, but not really much. (My guess is that his views clarified through
getting briefed by clueful legal authorities.)
Of note also -- and this, by contrast, is not just one engineer's
opinion on points of law, but an actual integral part of the kernel
licence -- is this preface to the Linux kernel source code tree's
COPYING file, which has been there since very early days:
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (i.e., v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
Linus Torvalds
Following that pair of paragraphs is GPLv2. Note that Torvalds
specifies v2 _only_, not the 'v2 or any later version' language FSF
recommends -- though there are a number of individual files in the Linux
kernel with that 'v2 or any later version' addendum because the file's
creator wanted that.
(Aside: The _correct_ name for the copyright-law concept Torvalds has
in mind is '_derivative_ work', not 'derived work'. In discussions of
licensing law, I can spot the Linux techies who have absolutely no idea
what copyright law really says, by the fact that they pick up Torvalds's
slight malapropism and don't know better. In fairness, Torvalds was
attempting to refer to GPLv2 section 2's wording about a work 'derived
from the Program'.)
Anyhow, Torvalds's aims should be very clear from that wording plus his
archived postings in my 'Proprietary Kernel Modules' file: He and his
fellow coders wished to accommodate anyone making existing drivers for,
say, SVR4 compatible with Linux by letting them use normal Unix userspace
system calls and Linux's published extensions (exported functions...)
without licence consequence, but otherwise take no steps whatsoever to
encourage or permit development of proprietary Linux kernel drivers. In
particular, they decline to reassure anyone with a 'no' answer to the
question 'If I borrow and use Linux kernel sources using [method FOO]
for creating and publishing a proprietary kernel module, do I have to
worry about being sued for copyright violation?'
Their attitude is that it's strictly that programmer's _own_ problem to
worry about whether his/her method of borrowing and using Linux kernel
source code creates a derivative work of the Linux kernel, and that, if
kernel coders with copyright title are sufficiently irritated by such a
coder as to sue, the courts can decide whether a derivative work exists
or not.
Thus, for example, the kernel coders aren't going to say 'Oh, we
_guarantee_ that you can use Linux kernel headers to make your
proprietary driver work with our kernel, because after all they're only
header files and probably don't have sufficient creative content to give
rise to copyright interest, are strictly functional, and are required
for compatibility.' Instead, proprietary-software creators who use Linux
kernel header files and anything else from the kernel in their
proprietary code, do so at their own risk: If a kernel copyright
stakeholder sues them, and a judge agrees that the usage creates a
derivative work, then the proprietary coder has a legal problem. That's
just the way it is. The fact that the proprietary coders have to worry
about whether their borrowing of kernel content for use in proprietary
code infringes copyright or not is a feature, not a bug.
If they don't like that, they're free to write their own header files
for compatibility with the kernel. And, by the way, regardless of whose
header files they use for proprietary code maintained outside the
mainline kernel tree, the kernel's interfaces _can and do change_
between versions. So, after going through all that trouble to
create a proprietary driver and worrying about whether the reuse of
kernel elements infringes copyright, they'll also have to live with the
knowledge that their cruddy proprietary driver will break and need to be
revised at unplanned intervals as new kernels come out.
(Said outsiders often demand that Linux start promising stable binary
in-kernel interfaces, as with Solaris. However, Linux's declining to
emulate Solaris is likewise a feature, not a bug. The kernel coders
have said 'Hell no' often enough that this, too, has been FAQed. See:
'Stable API Nonsense' on http://linuxmafia.com/kb/Kernel )
As Torvalds points out, if you wrote your proprietary driver _afresh_
for Linux rather than, say, porting over to it old, pre-existing AT&T
SVR4 driver code, you should probably worry a lot about what that
hypothetical judge will think on the derivative work question, and at
least should think hard about the reasons you'll cite to the judge about
how your work wasn't derived from the kernel despite appearances.
Moreover, as Torvalds points out, even if you did port over your own
Andrew Filesystem (AFS) driver from old AT&T SVR4 _source_ code that's
entirely yours to do with exactly as you please (or, to use another
example, IBM's JFS filesystem code that they wrote for OS/2 and ported
to Linux), if you compile it into a Linux _binary_ module, you should
worry about whether you're about to distribute a derivative work of the
Linux kernel on account of your inclusion of Linux kernel sources during
the compilation process.
If the proprietary coder doesn't like that situation, he/she is free to
use a permissively licensed kernel. I'll be glad to refer him/her to
the BSD community and say 'Enjoy!'
OK? I'm hoping that covers most of your concerns. And, _please_, read
the cited links. There's a reason why I provide them, and it's not so
that I can then have the privilege of interpreting them for people who
write in.
That's for the Linux kernel issue. Frankly, if the people you're
dealing with are paranoid about whether their proprietary userspace
software is violating Linux kernel and glibc copyrights just by running
on an OS with copylefted components, cut to the chase and tell them to
talk to Larry Ellison, who continues to not seem worried.
> I think that's clear, but still there is a level of irrational anxiety
> I often see even by senior developers about using FOSS, GPL, and
> Linux.
Tell them: 'Have you noticed that Larry Ellison is a capitalist?'
E.g., Oracle RDBMS for Linux continues to ship, and the sky never fell.
> When I say Linux, I mean the whole package of GNU userland libraries,
> libc, etc., and kernel and drivers -- basically all the shit you get
> when you install Ubuntu, Red Hat, CentOS, etc.
>
> I mean I see some people thinking that just compiling your code on a
> Linux box makes you required to open source it.
Those people are, obviously, morons^Wmisinformed. Don't waste your
time, except perhaps to point meaningfully in the direction of the
Oracle towers in Redwood Shores.
> While others see making a driver do that.
See above.
Short version, people who want to develop bespoke proprietary kernel
drivers for Linux can, in my personal view, FOAD if they can't figure
things out for themselves. I have no desire to help them.
> I think it's safe to make drivers and code, that dynamically link to GPL
> FOSS code without infringement. But there is still use of standard header
> files that are needed to make a driver.
See above, including the FOAD part (and note that 'linking' is not a
meaningful concept; derivative work is).
> As you may know most TV Set top boxes today are based on Linux. TiVo, most
> Cable TV STB's, most BluRay players, etc.
> Few if any give back anything.
You are factually mistaken concerning TiVo: All of TiVo's kernelspace
code is available under GPLv2 in compliance with the licence. (In fact,
the company are (last I heard) GPLv2 good citizens. A lot of people
dislike the locked-down nature of the combination of TiVo's software
suite plus the TiVo-subsidised hardware on TiVo Series II and later
units, but that isn't licence violation, and anyone is fully free to run
TiVo's GPLv2-compliant software on other hardware of their choosing.
The source code is available and fully licence-compliant. But you're
better off running a MythTV derivative, so frankly the issue doesn't
arise.)
If other companies do not, and make use of Linux kernel source within
proprietary codebases in such a way as to risk creating a derivative
work of the Linux kernel, they _should_ be afraid of copyright
infringement. That's good, IMO. Not a bug.
If someone gets around to bringing them to court, even better.
> Broadcom ships MIPS core chips with a Linux port 2.6.18 that most
> companies just build around. Basically kits with RF tuners and video
> DSPs.
Broadcom are indeed one of the worst offenders. They can FOAD, in my
personal view.
> The security requirements to be able to decode and play cable TV,
> satellite, Netflix, etc., is about as high as they can raise the bar
> and still have product on the market.
This can be done (on Linux) without copyright infringement. I decline
to help them, however.
> But this is true of the whole embedded space.
Embedded space is indeed a sewer of copyright violation.
> Trying to blend there proprietary hardware driver code with the GPL
> Linux code to get the product done, and finding that we can share
> their code, and yet we modified the GPL code to accommodate it.
Had legal worries, did you? Good. From your very brief description, I
think I'd have worried about copyright violation, too.
> One of the goals of GPL Version 3
> (http://en.wikipedia.org/wiki/GPL#Version_3) is to prevent
> "Tivoization".
As you will have noticed when you get around to reading the above + the
materials I've cited, the Linux kernel is GPLv2, not GPLv3. Thus TiVo's
legal right to ship Series II and later hardware with a kernel that runs
only if it validates with crypto keys TiVo, Inc. decline to share with
their customers.
> Try to make a document that clearly show the demarcation line between
> GPL and proprietary code.
You could just point to my Web site's knowledgebase articles. Except as
noted, and subject to other people's own rights and conditions, articles
within my knowledgebase may be freely redistributed under the terms of
Creative Commons Attribution-ShareAlike 3.0 .
And the situation with that licensing, by the way, is neatly analogous
to the Linux kernel developers' standardised permission grant to the
entire world: Anyone and his brother is welcome to make any use that
complies with CC By-SA 3.0. It's then up to the re-user to make sure
such use complies with my choice of conditions. If, by contrast, a
would-be reuser is extra-paranoid and the corporate counsel wants me to
sign contracts saying the reuser is absolutely are OK to do
this-and-that thing and that I'll hold it harmless from
that-and-the-other and that I warrant my right to grant some-things,
then the reuser should be prepared to offer me significant inducement
money, instead of just taking my CC By-SA 3.0 grant and running with it.
Why? Because if it wants extra assurances and privileges from me I'm
not offering to everyone for free, then it needs make that nuisance
worth my while, and especially if I have to deal with its lawyers, and
especially because I'll have to run all the one-off agreements by _my_
lawyer.
> TiVo is terrified of law suits that could effectively tell them they must
> deactivate all of their customer units, until the case is resolved,
> effectively costing them billions and killing them instantly.
I think they're about a half-dozen orders of magnitude more afraid of
Our Lords in Hollywood than they are of Linux kernel coders.
> This TiVoisation is actually a requirement of the Entertainment
> industry....
Well, yes. I'm highly aware of that. Been around for a long time,
John. Also, my wife Deirdre used to work at TiVo doing service
engineering. Those Python scripts that you guys use to parse setbox
logfiles reported in over the wire? She wrote them. (I obviously do
not know if they're still using those exact ones, but they have in the
past used them extensively and to very good effect.)
> ...and many Android products for example can't play Blockbuster or
> Netflix, because they fail to have sufficient security hardware and
> software protection.
I'm sorry to hear about the fact that _you_, because of your job at
TiVo, Inc., need to deal with the inference into computing and
monopolist paranoia by Our Lords in Hollywood, but my _own_ personal
perspective is that Blockbuster, Netflix, Amazon.com, Apple iTunes,
Microsoft Silverlight, and Intel's High-bandwidth Digital Copy
Protection can all FOAD.
I understand that many people are happy to run devices that are
handcuffed by baroque technical impediments required before Our Lords in
Hollywood will let 'Jackass: The Movie' run on them, but I'd rather use
real general-purpose computers, and really cannot possibly care except
that I applaud every time yet another DRM scheme crashes and burns.
> 1.) Who is in charge of enforcement of GPL License violations?
Um, John, you need to study the fundamentals of civil law in Western
legal systems. Then, you will not need to ask such questions.
Clue: Look up 'standing' and 'civil lawsuit'.
> 2.) Are there best practices where GPL and proprietary code can be
> married without causing problems?
Please see above.
> 3.) Can we enumerate the different scenarios, and show what is allowed
> and not allowed, to provide a simple clear and concise explanation to
> people?
No. Please see the material I've provided. It gives, if I may say so,
about as clear an overview as you are likely to get anywhere.
If that's not good enough for you, I'm sorry, but I am not interested in
doing unpaid consulting work for TiVo, Inc. or for a bunch of
proprietary-leaning embedded-appliance weenies whom I've never met and
whom I probably wouldn't even like or wish well.
> Would it be possible to get GPL insurance in case you're sued for GPL
> violations?
I've a better idea: They (generic they; not you) shouldn't use other
people's property in ways the owners haven't authorised. Which is
really not even difficult. In fact, here's the larger point, John: The
people you're talking with behave as if GPL and other copyleft licensing
compliance were some sort of new and challenging problem that must be
pondered and worried about endlessly, and yet they endure and ignore far
worse and more worrisome compliance issues with proprietary code
_every frelling day_.
Basically, seen in that light, this whole thing is utter bullshit. Let
me elaborate on why I say that:
When the embedded-code developer considers using Metrowerks CodeWarrior
to compile something, does he or she stop short and say 'I dunno, man.
Are we absolutely totally completely certain that we aren't going to
violate Metrowerks's copyright if we distributed our compiled code with
little bits of runtime engine or header code compiled into it?' No,
such coders simply take it as given that they have the right to do what
they expect reasonably to do and that others do without worry. And they
do that without even bothering to read the CodeWarrior EULA, which is
orders of magnitude more difficult to understand than GPL[23] and has
far, far more worrisome provisions. The difference is, in fact, 100% to
the advantage of standard major copyleft licences (GPL, LGPL, CDDL,
MPL), whose content you can know in advance without needing to read
one-off product-specific licences minutely and are, by contrast,
extremely predictable and devoid of unpleasant surprises.
So, please remind the people you work with that copylefted offerings are
in fact _far less problematic_ than the stuff they use every day.
Especially given that, if they _did_ want to do something edgy and
lawsuit risking with CodeWarrior, they would be picking up the 'phone to
call Metrowerks's lawyer and saying 'Um, can we buy a special licence to
do [foo]?' Again, that is exactly like with my knowledgebase, and
exactly like with BusyBox (GPLed multitool software that is much beloved
of embedded Linux companies) and exactly like with the Linux kernel: If
they want to do something whacked that they're not sure is covered by the
default public licence, they should -- obviously -- offer to buy some
additional rights for money.
If they aren't willing to do that, then they (generic they, not you)
are free to write their own replacement, or to STFU and comply with the
default public licence.
In that regard, the only people who could reasonably say 'I'm not sure
if I want to deal with the complications of copylefted licensing' whom I
would not accuse of ridiculous hypocrisy (on grounds of using far, far
more problematic things every day) would be someone who's running
nothing but a pure BSD kernel and libc, with X.org, Apache, MIT, and BSD
code, where everything's compiled using Clang or nwcc (not gcc, of
course) and who never, ever uses any proprietary code.
In particular, those would not be the people you're talking about, who
are firmly in the perspective-challenged hypocrite camp.
Please do quote me on that, and give them my love.
More information about the conspire
mailing list