|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
The Seventh Circuit affirmed the ruling of The U.S. District Court for the Southern District of Indiana and dismissed the case, finding the plaintiff had suffered no antitrust injury."Although antitrust law serves the interests of consumers rather than producers, the Supreme Court has permitted producers to initiate predatory-pricing litigation," Judge Easterbrook wrote in the November 9 decision. "This does not assist Wallace, however, because his legal theory is faulty substantively."
Perhaps most significantly, Wallace had not contended that software available under the GPL would lead to monopoly prices in the future. The court observed the anomalous thinking behind any conclusion that it would, "when the GPL keeps price low forever and precludes the reduction of output that is essential to monopoly."
The court cited the market domination of proprietary operating systems like Windows, OS X and Solaris despite the fact that Linux is available for free for 15 years. Similarly Photoshop is preferred in the market to Gimp, and Lexis and Westlaw are preferred to free legal sources such as court websites.
The court ruled that Sherman Act didn't advance the plaintiff's case either. Instead of being a restraint on trade, the court held that the GPL serves to foster creativity, by enabling the free distribution and building of new derivative works.
See [a copy of the opinion. No. 06-2454 (7th Cir., November 9, 2006).]
by diegocgteleline.es (653730) on Saturday October 28, @08:04AM (#16621516)
Slashdot Re:An old slogan comes to mind
(Score:5, Informative)by Halo1 (136547) <[email protected]@ugent@be> on Monday October 23, @06:31PM (#16553120)
(http://www.ffii.org/)by Gulik (179693) on Monday October 23, @03:50PM (#16550734)I wouldn't be surprised if the ONLY reason they used this against Amazon, is because Amazon does the same thing to others.Then be very surprised. IBM has a long history of strong-arming other companies with its patent portfolio [forbes.com] and extracting license money from them [ffii.org]. In fact, Marshall Phelps (who now works for Microsoft [microsoft.com] fwiw), turned IBM's sleeping patent portfolio into a $1+ billion profit [forbes.com].
Re:An old slogan comes to mind (Score:5, Interesting)
"Live by the sword, die by the sword."
Of course, with IBM's patent portfolio, they can match you sword-for-sword and still have fifteen thousand left to swing at you after you've run out.
Which won't protect them from any of those patent litigation firms, but then there's still the sheer megatonnage of IBM's legal department to contend with.
I knew it (Score:0)
by Anonymous Coward on Monday October 23, @04:12PM (#16551042)A couple years ago in a thread surrounding the SCO vc IBM case, I made a reply to the background chorus of/.'s that were singing IBM's praises: i.e. how lucky FOSS was to have IBM's support. I was jumped when I suggested to hold back a little- I worked for IBM for a number of years, and stated that if mgmt thought it was in their interests, they would skin us all alive & sell the result in China as customized wetsuits.
Man, I am absolutely telling you all again that IBM's "partnership" with FOSS is one of convenience only- if and when the time comes, IBM will without a doubt or a regret bend each and every one of us associated with FOSS over a chair... smiling the whole time & telling us "we were asking for it".
is a counter-argument to the position of the Maintainers (and others). It makes cogent points, which is why I think the FOSS movement must split. There has never been a good fit between the FSFers, who believe that software really should be free, and the corporate types, who want to commodify operating systems as a way of providing a platform on which to hang money-making aps and services. And these are conflicts of moral principle on the FSF side versus huge financial stakes on the corporatist side. The latter cannot give way -- it would cost too much and render the whole enterprise pointless. And the FSFers can't give way because it would make the enterprise pointless from their perspective.
Personally, I am happy to see it, of course, because the conflict highlights the unworkability of the Free Culture Movement's models of peer-based production without regard for payment. Since the FCM regards open source software as a pilot program for all other creative products, ranging from music to movies, the quicker its weaknesses as a mode of production are rendered obvious, the sooner the debate can shift to real issues of how to define and protect IP rights in a time of great technological change. Where should they shrink, and where should they expand?
posted by James DeLong @ 9:06 AM | Software
Link to this Entry | Printer-Friendly | Email a Comment
CommentsThe goose has laid enough golden eggs, time to kill it and cook it for dinner?
Posted by: John Smith at September 30, 2006 04:13 PM
So let's say you just released some commercial software. Would you ever allow for a compromise in the associated license? Would you ever allow somebody to "mostly" comply to your terms?If you don't like our terms of use, don't use our software. We're not trying to "fit" with anyone. We're writing software for our own needs. This is what drives us to write code and, in turn, what drives the Free software movement. The GPL works to help ensure the code we write remains Free - not just "mostly" free.
Free software may be "unworkable" for you. That's fine. By the same token, many commercial solutions on the market are worthless to us, either due to the financial cost or the closed nature of development. For example, if I need a feature tweaked somewhat, I'm at your mercy. This is unacceptable for a lot of people.
Rather than just assuming that your position is correct, perhaps you should take a look around. Do you realize just how huge the Free software movement has become? Can you comprehend the fact that there might be a reason for it?
Posted by: Tom at October 17, 2006 01:42 AM
Have a look at www.Joomla.org or many similar free software projects that continue to grow exponentially. Why? Because thousands of people like me (independent consultants and small companies) charge good money to customize and maintain installations for our clients, and we also contribute contribute back to Joomla and others, knowing it will grow our core profitable platform. It's a new ecosystem, and it's entirely economically sustainable.Posted by: Dan at October 17, 2006 03:45 AM
September 29, 2006 (Red Herring) Exclusive Q&A: Linux kernel creator speaks out about the current controversy over an update to the key open-source license.
A new version of a license for open-source Linux has caused a storm among the community of open-source developers. Known as GNU General Public License, or simply GPL, it is the most widely used license for distributing free software.
The current version of the license, GNU GPLv2, was released in 1991. The first version of the license was written by open-source proponent Richard Stallman, who founded the Free Software Foundation that administers the license. The GPL license also covers the Linux kernel whose creation was led by Linus Torvalds.
Now 10 kernel developers have rallied against the Free Software Foundation’s efforts to update the license. They have signed a “position paper” against the new version known as GPLv3.
The kernel developers contend that the Free Software Foundation’s plan to promote GPLv3 has “the potential to inflict massive collateral damage upon our entire ecosystem and jeopardize the very utility and survival of open source.”
Though Mr. Torvalds supports them, his name has been absent from that position paper.
Now, in an email interview with Red Herring, he puts his thoughts on the record. Mr. Torvalds says this is not as much a “debate” between the kernel developers and the Free Software Foundation “as it is a declaration of different positions.”
Q: Ten key kernel developers have signed a "position paper" on the new draft of the GNU GPL license. Why did you not join them in signing the paper?
A: I wrote a separate email to the kernel mailing list about that. It’s easiest to just point you at it: http://lkml.org/lkml/2006/9/24/246. It wasn’t the only reason. The actual letter was mostly penned by James Bottomley, and I just don’t much like the “open letter” kind of things, so if I didn’t write it or add to it, I generally try to keep my name off it.
Finally, I actually wanted to make clear that I wasn’t the only one who felt that way, so I didn’t feel like my name needed to be on everything.
Q: Do you even believe there is a need to update the GPL license and have a version 3 put out? Do you think that GPLv2 is not serving the purpose adequately?
A: I think the GPLv2 is stronger today than it was 15 years ago. It’s been upheld in court both in the U.S. and abroad, and obviously it’s gathered a much larger community around it. So no, I don’t see the need.
Q: What is your position on the draft version of the GNU General Public License Version 3?
A: One of my major gripes with it is that it extends the GPLv2 so much that it’s not at all the same license. If it had been developed as a totally new license, that would be fine, but since the FSF [Free Software Foundation] has been asking people to release their code compatible with “any future versions,” I think it’s a bit inappropriate to add totally new issues to the license.
FSF promised that any such future versions would be “similar in spirit,” but it’s apparently their stance on the spirit that matters, not the stance of the people who they tried to actually reassure with the language—which makes the whole thing rather pointless.
Q: If the GNU GPLv3 proceeds in its current form, what do you fear?
A: Well, “fear” may be too strong a word. What I think the GPLv2 has been good at is that it was so widely acceptable that it acted as a common thing for people to get together around. The GPLv3 imposes a number of new rules that aren’t really acceptable to many people, and as such it just means that rather than have one common license, we’ll have two.
Now, multiple licenses isn’t really necessarily a huge deal in practice, since even before, we’ve had lots of different non-GPL open-source licenses that have had reasonably wide use. But I happen to think it’s a loss, and also confusing to have different versions of the “same” license basically say different things.
Q: The Free Software Foundation has issued a clarification on its web site that developers will have the right to use GPLv2 even after GPLv3 is published. In light of that, do you think that the GPLv3 in its current form is not as dangerous?
A: That’s just silly. Of course people have the “right” to continue to use the GPLv2. That’s like clarifying that the Earth will still retain its gravity and we won’t all fly out into space when the GPLv3 is released. That was never a worry. The FSF can release new versions of the GPL, but they can’t force people to use them.
Q: How do you think that the current impasse around GPLv3 can be solved? What are your recommendations to move ahead?
A: Personally, I think the FSF should either just really try to keep to the same rules as the GPLv2, or just rename the new license, so that there is no confusion. People are used to just saying “GPL,” without the ambiguity of which GPL we’re talking abut.
Q: Who do you think needs to negotiate with the Free Software Foundation to make the changes happen?
A: They’ve been at it for a year and a half now. I’m not sure this is about negotiation anymore. They certainly knew that they were the radical fringes of the bigger community, and they certainly knew my standpoint on the things they added to the GPL. I think the thing they didn’t expect was just that while I’m a moderate, I’m passionate about being moderate.
I asked Torvalds, via email, if he was likely to take Moglen up on his offer to participate in the process. Torvalds' reply, which was cc:ed to Moglen, was less than enthusiastic:I wonder why everybody but the FSF seems to know my email address, but the FSF can't find it.
If it has an anti-Tivo clause, I think it's bad. I've tried to explain it to some people (the freedom of the _project_ is much too important to let any license clause limit how you can use it), but when other people did that, the FSF just explained how they had mis-used the word "use".
But I'm so fed up with the FSF right now that I'm not in the least interested. There's no way in _hell_ they can claim that they don't know my standpoint, so what are they even asking for?
The FSF's response to the kernel developers on Monday took issue with the characterization of the anti-DRM clause as an "end use restriction," but didn't address the developers' other arguments about the anti-DRM clauses in the GPLv3 draft.
In fact, the FSF's response largely failed to address any of the concerns put forward by kernel developers and instead focused on correcting a few minor factual errors in the position paper. The FSF has declined several requests for interviews to answer questions about the developers' position paper. Moglen, through the SFLC, has also declined to answer any questions.
Stopping TiVo is worse than TiVo itself
Torvalds says that he has cc:ed Moglen in the past regarding his position on the GPLv3 drafts, and that his position on the license should be clear already. Torvalds also writes that removing the anti-DRM clause would go a long way toward addressing his concerns:
Eben, I think the whole anti-Tivo crusade is _wrong_. If you can get rid of the language that says that you cannot use a project any way you want to (and I don't care if it legally is about "distribution" or "use", I just want it to be _practically_ about the usage standpoint), just about all my very fundamental concerns go away.
Other people might worry about the patent language, but at least I _personally_ really only dislike the whole term "Tivoization", and all the new language to try to "stop" it. I think stopping Tivo is a much bigger problem than Tivo itself ever was.
But that [removing the anti-DRM language] would require a public statement that things like Tivo trying to control _which_ particular version of a program they run on hardware _they_ control is actually ok, and that you can actually use a GPLv3'd project in all the same situations you could use a GPLv2 one.
(It's not just Tivo, either. Medical supplies, cellphones with restricted updaters, you name it. Cryptography is a fundamental technology, and should not be disallowed).
It's their hardware. I do _not_ want to ask for control of the "environment" back in a license. I want the improvement to the _software_, not the keys to the kingdom. The "environment" a program runs in (or the medium it is distributed on) doesn't have to be open. Just the program itself.
As it is, the GPLv3 limits a program that uses it very fundamentally more than Tivo _ever_ limited Linux. Tivo never limited the way Linux could be used by others. The GPLv3 tries to limit how a project can be used. The GPLv3 is the one that really limits your freedoms, not the other way around.
Since Torvalds seems to object primarily to the anti-DRM provisions, I asked if he'd consider moving to the GPLv3 if the FSF removed those provisions from the final license. Even if that happened, Torvalds says that he's not "not going to single-handedly try to relicense" the kernel out of respect for past authors of kernel code.
"Any concern by an author of the _current_ work against the switch does weigh very much more than any voice for the switch talking about potential future work.... However, without the anti-Tivoization clauses, I won't fight it rabidly."
- Re:The GPL3 process is not closed(Score:5, Insightful)
by mrchaotica (681592) * <<mrchaotica> <at> <yahoo.com>> on Tuesday September 26, @12:14PM (#16200627)
More and more people will start exploiting the loopholes in GPL v.2 (e.g. apps as web servies, so they're not technically "distributed" to the users, TiVo-esque locking of hardware to use only the company's version of the program, etc.).
- Re:The GPL3 process is not closed(Score:4, Interesting) by CaymanIslandCarpedie (868408) on Tuesday September 26, @12:17PM (#16200687)
But for many people (Linus included) those "loopholes" are features not bugs. Those holding views can argue those features are what caused GPL 2 to be so widely adopted and that the "fixes" in v3 will cause v3 to "crumble" (ie nobody using it).
- Is this the enlightened attitude of the FSF?(Score:1)
by partisanX (1001690) on Tuesday September 26, @01:27PM (#16201651)
(http://partisanx.blogspot.com/)If you don't like it, shut up and leave!!!
Yeah, great attitude. Great example for the kids. Very democratic and all that.
eWEEK: “The DRM provisions are designed to go after companies like TiVo, which uses Linux but collects information on consumers’ actions. While TiVo complies with GPL 2.0, it may have more difficulty complying with GPLv3’s anti-DRM provisions.”Not true. As far as I know (I’m not an insider), TiVo is not a derivative work of Linux in the legal sense—it’s simply a Linux application that happens to ship with a Linux distribution bundled as a complete package.
Given that it’s not a derivative work, the anti-DRM provisions (or anything else for that matter) in GPLv3 can’t affect TiVo at all, nor can they affect similar products that simply bundle a Linux application with Linux itself (i.e., pretty much any Linux-based server appliance, etc.).
Now, my first assumption was that this was yet another case of misunderstanding the GPL and/or how Linux-based products such as TiVo work. However, Eben Moglen himself appears to sow the seeds of confusion this time:
Asked if TiVo could avoid using GPL 3.0 when that license is released next year, Moglen said, “Once a GPL’d work has been relicensed under GPLv3, although a party having a copy under GPLv2 could continue to distribute it under that license, any further maintenance from upstream would force the license upgrade.” TiVo could avoid using GPL 3.0 even if, say, the Linux kernel were to change licenses, but only by freezing itself at the last version of the kernel that was licensed under GPL 2. “That will prove to be impracticable in almost every real commercial setting,” Moglen said.
I assume Eben isn’t misunderstanding the GPL, so perhaps he’s misunderstanding how TiVo works. Or, perhaps he made some comments that were taken out of context (the above isn’t an exact quote, after all, and goodness knows, I’ve been misquoted enough times I take such attributed statements with a grain of salt). I do hope, though, it’s not the FSF overplaying its hand on what constitutes a derivative work.
Tivoization is the creation of a system that incorporates software under the terms of a copyleft software license, but uses hardware to prevent users from running modified versions of the software on that hardware. Richard Stallman, creator of the copyleft GNU General Public License (GPL), coined the term and believes this practice denies users some of the freedom that the GPL was designed to protect.[1]The term came about because of how TiVo uses GPL software on TiVo brand digital video recorders (DVR). TiVo's software incorporates the Linux kernel and parts of GNU, both of which are licensed under the GPL Version 2 (GPL v.2). The GPL v.2 requires TiVo to release the associated source code for others to use and modify. One of the goals of this GPL requirement is to allow others to modify the software to better suit their purposes.[2]
However, Stallman believes TiVo circumvented this goal by making their products run programs only if the program's digital signature matches those authorised by the manufacturer of the TiVo. So while TiVo has complied with the GPL v.2 requirement to release the source code for others to modify, any modified software will not run on TiVo's hardware. Many of the authors of the code that TiVo used complain that their work has thus been misappropriated[citation needed]. As a result, one of the goals of the proposed GPL Version 3 is to prevent "Tivoization"; according to Eben Moglen, "the licence should prohibit technical means of evasion of its rules, with the same clarity that it prohibits legal evasion of its rules." [3]On the other hand, Linus Torvalds, the creator of Linux, has argued that it is appropriate for TiVo to use digital signatures to limit what software may run on their systems. In explaining his opposition to the GPLv3's attempts to protect freedom from tivoisation, he has stated that he believes the use of private digital signatures on software are a beneficial security tool. However, no draft of GPLv3 prohibits using private digital signatures as a security tool[citation needed]. Torvalds also believes that software licenses should only attempt to control software, not the hardware on which it runs. So long as one has access to the software, and can modify it to run on some other hardware, Torvalds believes there is nothing unethical about using digital signatures to prevent running modified copies of Linux.[4]
There is also the interpretation that the "complete source code" in the GPL v.2 already implies that TiVo has to offer the private keys required for enabling modified software to run on their hardware. Gpl-violations.org has already successfully enforced this interpretation in Germany against Siemens and TomTom.
From: Linus Torvalds
Date: Sun Sep 24 2006 - 22:45:59 EST
- Next message: Rusty Russell: "Re: [PATCH 5/7] Use %gs for per-cpu sections in kernel"
- Previous message: Randy Dunlap: "Re: i386 pda patches"
- Next in thread: Willy Tarreau: "Re: An Ode to GPLv2 (was Re: GPLv3 Position Statement)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
One of the reasons I didn't end up signing the GPLv3 position statement
that James posted (and others had signed up for), was that a few weeks ago
I had signed up for writing another kind of statement entirely: not so
much about why I dislike the GPLv3, but why I think the GPLv2 is so great.
(There were other reasons too, but never mind that.)
I didn't get my fat arse off the ground on that, partly exactly because
the developer poll of "which is better" which was related to that issue
distracted me, but mostly because I just seldom write that kind of text -
one thing the kernel work has conditioned me for is that I write _replies_
to email, I seldom start threads myself (I suspect most of my emails on
linux-kernel that aren't replies are just release announcements).
However, since there was a sub-thread on groklaw about the kernel
developers opinions on the GPLv3, and since I did try to explain it there
(as a reply to postings by PJ and others), and since some of those
explanations ended up being exactly the "why the GPLv2 is so insanely
great" that I never wrote otherwise, I thought I'd just repost that
explanation as an alternative view.
So this post is kind of another way to look at the whole GPLv3 issues: not
caring so much about why the GPLv3 is worse, but a much more positive "Why
the GPLv2 is _better_". I suspect some people may have an easier time
seeing and reading that argument, since it's not as contentious.
A lot of people seem to think that the GPLv2 is showing its age, but I
would argue otherwise. Yes, the GPLv2 is "old" for being a copyright
license, but it's not even that you don't want to mess with something that
works - it's that it very fundamentally is such a good license that
there's not a whole lot of room for fixing aside from pure wording issues.
So without further ado, here's my personal "reply" to the the GPLv3
position statement. It's obviously not meant to repudiate James' text in
any way, it's just an alternate view on the same questions..
I made other posts in the same thread on Groklaw thread, not as positive,
and not perhaps as worthy and quotable. This one may be a bit out of
context, but I do think it stands on its own, and you can see the full
thread in the "GPL Upheld in Germany Against D-Link" discussions on
Groklaw. The particular sub-thread was on what happens since we can't
easily change update the license, called "So What is the Future Then?"
(I'd like to point to the groklaw posts, but there doesn't seem to be any
way to point to a particular comment without getting "The URL from Hell",
so it's easier to just duplicate it here).
Linus
---
And thus spake PJ in response:
"GPLv2 is not compatible with the Apache license. It doesn't cover
Bitstream. It is ambiguous about web downloads. It allows Tivo to
forbid modification. It has no patent protection clause. It isn't
internationally useful everywhere, due to not matching the terms of
art used elsewhere. It has no DMCA workaround or solution. It is
silent about DRM."
Exactly!
That's why the GPLv2 is so great. Exactly because it doesn't bother or
talk about anything else than the very generic issue of "tit-for-tat".
You see it as a failure. I see it as a huge advantage. The GPLv2 covers
the only thing that really matters, and the only thing that everybody can
agree on ("tit-for-tat" is really something everybody understands, and
sees the same way - it's totally independent of any moral judgement and
any philosophical, cultural or economic background).
The thing is, exactly because the GPLv2 is not talking about the details,
but instead talks entirely about just a very simple issue, people can get
together around it. You don't have to believe in the FSF or the tooth
fairy to see the point of the GPLv2. It doesn't matter if you're black or
white, commercial or non-commercial, man or woman, an individual or a
corporation - you understand tit-or-tat.
And that's also why legal details don't matter. Changes in law won't
change the notion of "same for same". A change of language doesn't change
"Quid pro quo". We can still say "quid pro quo" two thousand years later,
in a language that has been dead for centuries, and the saying is still
known by any half-educated person in the world.
And that's exactly because the concept is so universal, and so
fundamental, and so basic.
And that is why the GPLv2 is a great license.
I can't stress that enough. Sure, other licenses can say the same thing,
but what the GPLv2 did was to be the first open-source license that made
that "tit-for-tat" a legal license that was widely deployed. That's
something that the FSF and rms should be proud of, rather than trying to
ruin by adding all these totally unnecessary things that are ephemeral,
and depend on some random worry of the day.
That's also why I ended up changing the kernel license to the GPLv2. The
original Linux source license said basically: "Give all source back, and
never charge any money". It took me a few months, but I realized that the
"never charge any money" part was just asinine. It wasn't the point.
The point was always "give back in kind".
Btw, on a personal note, I can even tell you where that "never charge any
money" requirement came from. It came from my own frustrations with Minix
as a poor student, where the cost of getting the system ($169 USD back
then) was just absolutely prohibitive. I really disliked having to spend
a huge amount of money (to me) for something that I just needed to make my
machine useful.
In other words, my original license very much had a "fear and loathing"
component to it. It was exactly that "never charge any money" part. But I
realized that in the end, it was never really about the money, and that
what I really looked for in a license was the "fairness" thing.
And that's what the GPLv2 is. It's "fair". It asks everybody -
regardless of circumstance - for the same thing. It asks for the effort
that was put into improving the software to be given back to the common
good. You can use the end result any way you want (and if you want to use
it for "bad" things, be my guest), but we ask the same exact thing of
everybody - give your modifications back.
That's true grace. Realizing that the petty concerns don't matter,
whether they are money or DRM, or patents, or anything else.
And that's why I chose the GPLv2. I did it back when the $169 I paid for
Minix still stung me, because I just decided that that wasn't what it was
all about.
And I look at the additions to the GPLv3, and I still say: "That's not
what it's all about".
My original license was petty and into details. I don't need to go back
to those days. I found a better license. And it's the GPLv2.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
The Dangers and Problems with GPLv3 by James E.J. Bottomley, Mauro Carvalho Chehab, Thomas Gleixner, Christoph Hellwig, Dave Jones, Greg Kroah-Hartman, Tony Luck, Andrew Morton, Trond Myklebust, David Woodhouse
This document is a position statement on the GNU General Public License version 3 (in its current Draft 2 form) and its surrounding process issued by some of the Maintainers of the Linux Kernel speaking purely in their role as kernel maintainers. In no regard should any opinion expressed herein be construed to represent the views of any entities employing or being associated with any of the authors.1 Linux and GPLv2
Over the past decade, the Linux Operating System has shown itself to be far and away the most successful Open Source operating system in history. However, it certainly wasn't the first such open source operating system and neither is it currently the only such operating system. We believe that the pre-eminent success of Linux owes a great part to the dynamism and diversity of its community of contributors, and that one of the catalysts for creating and maintaining this community is the development contract as expressed by GPLv2.
Since GPLv2 has served us so well for so long, and since it is the foundation of our developer contract which has helped propel Linux to the successes it enjoys today, we are extremely reluctant to contemplate tampering with that licence except as bug fixes to correct exposed problems or updates counter imminent dangers. So far, in the whole history of GPLv2, including notable successes both injunctively and at trial, we have not found any bugs significant enough to warrant such corrections.
2 Linux, the Kernel and the Open Source Universe
Linux Distributions, as the Free Software Foundation (FSF) has often observed, don't only contain the kernel; they are composed of a distribution of disparate open source components of which the kernel is only a part (albeit a significant and indispensable part) which collectively make up a useful and usable system. Thus, Linux as installed by the end user, is critically dependent on entities, known as distributions, who collect all of the necessary components together and deliver them in a tested, stable form. The vast proliferation of Open Source Licences complicates the job of these distributions and forces them to spend time checking and assessing the ramifications of combining software packages distributed under different (and often mutually incompatible) licences--indeed, sometimes licensing consideration will be sufficient to exclude a potential package from a distribution altogether.
In deference to the critical role of distributions, we regard reducing the Open Source licensing profusion as a primary objective. GPLv2 has played an important role in moving towards this objective by becoming the dominant Licence in the space today, making it possible to put together a Linux Distribution from entirely GPLv2 components and thus simplify the life of a distributor. Therefore, we believe that any update to GPLv2 must be so compelling as to cause all projects currently licensed under it to switch as expediently as possible and thus not fragment the currently unified GPLv2 licensed ecosystem.
3 Linux and Freedom
Another of the planks of Linux's success rests squarely on the breadth and diversity of its community of contributors and users, without whom we wouldn't have the steady stream of innovation which drives our movement forward. However, an essential element of this is the fact that individuals with disparate (and sometimes even competing) objectives can still march together a considerable distance to their mutual benefit. This synergy of effort, while not compromising dissimilar aims, is one of the reasons Linux manages to harness the efforts of not only motivated developers but also corporate and commercial interests. This in turn is brought about by a peculiar freedom enshrined in the developer contract as represented by GPLv2, namely the freedom from binding the end use of the project. Without this freedom, it would be much more difficult to satisfy the objectives of the contributors, since those objectives often have expression in terms of the end use to which they wish to put the particular project. Therefore, in order to maintain the essential development synergy and consequent innovation stream it provides to Linux, we could not countenance any change to the GPL which would jeopardise this fundamental freedom.
4 Pivotal Role of the Free Software Foundation
We have acknowledged before, projects controlled by the FSF (especially gcc, binutils and glibc) are essential components of every shipping Linux distribution. However, we also take note of the fact that the FSF operates very differently from Linux in that it requires assignment of copyright from each and every one of the thousands of contributors to its code base. These contributions have been given to the FSF not as a tribute to do with as it will but under a solemn trust, as stated in article 9 of GPLv2, only to licence the code under versions of the GPL that "... will be similar in spirit to the present version". We, like all the individual contributors to GNU projects, have taken that trust at face value and accorded the FSF a special role in the Open Source Universe because of it. It goes without saying that any updates to GPLv2 must be completely in accord with the execution of that trust.
5 GPLv3 and the Process to Date
The current version (Discussion Draft 2) of GPLv3 on first reading fails the necessity test of section 1 on the grounds that there's no substantial and identified problem with GPLv2 that it is trying to solve.
However, a deeper reading reveals several other problems with the current FSF draft:
5.1 DRM Clauses
Also referred to as the "Tivoisation" clauses.
While we find the use of DRM by media companies in their attempts to reach into user owned devices to control content deeply disturbing, our belief in the essential freedoms of section 3 forbids us from ever accepting any licence which contains end use restrictions. The existence of DRM abuse is no excuse for curtailing freedoms.
Further, the FSF's attempts at drafting and re-drafting these provisions have shown them to be a nasty minefield which keeps ensnaring innocent and beneficial uses of encryption and DRM technologies so, on such demonstrated pragmatic ground, these clauses are likewise dangerous and difficult to get right and should have no place in a well drafted update to GPLv2.
Finally, we recognise that defining what constitutes DRM abuse is essentially political in nature and as such, while we may argue forcefully for our political opinions, we may not suborn or coerce others to go along with them. Therefore, attempting to write these type of restrictions into GPLv3 and then relicense all FSF code under it is tantamount to co-opting the work of all prior contributions into the service of the FSF's political ends, and thus represents a fundamental violation of the trust outlined in section 4.
5.2 Additional Restrictions Clause
As we stated in section 2 one of the serious issues in Open Source is too many licences. The additional restrictions section in the current draft makes GPLv3 a pick and choose soup of possible restrictions which is going to be a nightmare for our distributions to sort out legally and get right. Thus, it represents a significant and unacceptable retrograde step over GPLv2 and its no additional restrictions clause.
Further, the additional restrictions create the possibility of fragmentation of the licensing universes among particular chosen restrictions, which then become difficult to combine and distribute (because of the need for keeping track of the separate restrictions). Thus, we think this potential for fragmentation will completely eliminate the needed compulsion to move quickly to a new licence as outlined in section 2
5.3 Patents Provisions
As drafted, this currently looks like it would potentially jeopardise the entire patent portfolio of a company simply by the act of placing a GPLv3 licensed programme on their website. Since the Linux software ecosystem relies on these type of contributions from companies who have lawyers who will take the broadest possible interpretation when assessing liability, we find this clause unacceptable because of the chilling effect it will have on the necessary corporate input to our innovation stream.
Further, some companies who also act as current distributors of Linux have significant patent portfolios; thus this clause represents another barrier to their distributing Linux and as such is unacceptable under section 2 because of the critical reliance our ecosystem has on these distributions.
6 Conclusions
The three key objections noted in section 5 are individually and collectively sufficient reason for us to reject the current licence proposal. However, we also note that the current draft with each of the unacceptable provisions stripped out completely represents at best marginal value over the tested and proven GPLv2. Therefore, as far as we are concerned (and insofar as we control subsystems of the kernel) we cannot foresee any drafts of GPLv3 coming out of the current drafting process that would prove acceptable to us as a licence to move the current Linux Kernel to.
Further, since the FSF is proposing to shift all of its projects to GPLv3 and apply pressure to every other GPL licensed project to move, we foresee the release of GPLv3 portends the Balkanisation of the entire Open Source Universe upon which we rely. This Balkanisation, which will be manifested by distributions being forced to fork various packages in order to get consistent licences, has the potential to inflict massive collateral damage upon our entire ecosystem and jeopardise the very utility and survival of Open Source. Since we can see nothing of sufficient value in the current drafts of the GPLv3 to justify this terrible cost, we can only assume the FSF is unaware of the current potential for disaster of the course on which is has embarked. Therefore, we implore the FSF to re-examine the consequences of its actions and to abandon the current GPLv3 process before it becomes too late.
Such as the "Matrix House" described in our last article: A DRM-encumbered booby trap not unlike the malfunctioning inventions which feature so regularly in our Rise Of The Machines™ series.
Don't use the GPL to fight these battles, you reckon.
But as we suggested at the outset this is a very nuanced postbag. First of all, we need to outline the problem. When TiVo used Linux, which is based on GPL version 2.0 code, added a proprietary front-end, and turned it into a DRM device, many people were upset.
Asks Matthew Barratt:
There are any number of well developed OSs that people like TiVo and the like could choose. VxWorks, Symbian would do nicely, QNX, embedded XP (eeeeeek!) even? VxWorks is POSIX compliant, so largely familiar to a Linux developer. TiVo picked Linux because it was free. If they didn't like the look of linux in future, maybe because of GPL 3, they could very easily switch to something like VxWorks and it'd make 50pence difference to the unit cost.Indeed, wouldn't life have been simpler if TiVo had chosen a non-free embedded OS? But the objection to TiVo is that they were breaking the spirit, if not the letter of the GPL. Software libre advocates can't prevent such appropriations by invoking the Law of Good Taste, but they can prevent misuse under the GPL. So TiVo is seen to be exploiting a loophole in GPL version 2.0, and so GPL 3.0 is designed to stop TiVOs of the future by blocking this loophole.
But that's not our problem, says Matthew, who sees DRM as an unavoidable part of the world:
I get the impression that this is all muddled up with the wider DRM debate. Is GPL 3 is being leveraged by some as a means to overcome DRM (which is here to stay like it or not) mechanisms? If so they are living in cloud coockoo land and it sounds like they are assuming that there's no other choice out there for Tivo et al.With the scene set, Bill Hufmann gets to the problem with admirable succinctness:
I can sympathize with both sides of this argument, but it does seem to me that GPL 3.0 extends the free (freedom) software concept to cover free (freedom) entertainment content as well. The constituencies of the two concepts overlap considerably but forcing equivalence seems unnecessary and could destroy one or both movements.As Kym Farnick points out, Linus rejection of GPL 3.0 doesn't imperil Linux, it imperils the GPL 3.0 draft as it's currently drafted.
- Torvalds can happily continue using GPL v2 for the Linux Kernel, and there's no reason to go to v3.0, whatever that turns out to be.
- Torvalds could (with difficulty) move to another OSS license or even create a new Linux Open License (LOL) ;-) Maybe one similar to the Mozilla license.
- Moglen can make parts of the V3 license optional.
Carsten's email here sums up the tone of many defending the GPL 2.0 kernel position.
Linus didn't create Linux as something to fit the (L)GPL. He had already started on the Linux project, *then* decided that he needed a formal license, came across the GPL v2 and decided that that fit his needs. End of story, really.I can see why the Open Source "advocates" (be they programmers or journalists) would want to use Linux as the vehicle for their moral crusade. It was succesful, and as Torvalds has always tried to stay away from the political discussions, they pretty much had a free run.
Blaming Linus for not carrying *your* banner in your personal fight for "freedom" is insane. Fight it yourself if you must, but don't start dragging someone into it who just wants time to plug away at his OS.
Ah, but if it was simply a case of few journalists or detached advocates berating Torvalds for rejecting some fancy new license, then it wouldn't merit many column inches. But the license he's being urged to adopt is the officially designated successor to the one he's already using.
Leaving us with the question, does the GPL need Torvalds more than Torvalds needs the GPL?
And if that isn't enough indigestible thoughts before breakfast - how about this thought from Justin Davidow:
Linux is not a magical moral crusade that people undertake to compete with Bill, nor is it a "free" alternative.Er. It isn't?
"'Linux' is only a name," writes Paul Meekin hopefully, carrying on the spirit. He continues:
It is like the value of a company in the stock market in that it only has meaning while everyone believes in it. If enough people decide they don't like Linus's ethical rule, a spin-off would soon occur which would be subject to the new rule. The old GPL ensures that the genie is well and truly out of the bottle for good.But no Register mailbag would be complete without a few unexpected Scuds making their way across the ether and exploding in a zone heavily defended by posturing and hypocrisy. We'll end with these three gems.
Thanks for the Article. What amuses me most is your quote from Linus:" ... we do not - as software developers - have the moral right to enforce our rules on hardware manufacturers. We are not crusaders, trying to force people to bow to our superior God."
Since when has he felt like that. Last time I remembered, the kernel people (including Linus) were real big on being the superior software Gods. Isn't that why we can't have binary modules loaded into the kernel to support hardware? One recent example would be the following:
http://www.smcc.demon.nl/webcam/
And that whole fiasco. Anyways, just amusing to see Linus flip flopping around and sticking to what is convienent to him. I am a big fan of Linux/OpenSource and use it extensively for work and play, but I wish some of the public figures would get a clue and get off their high horses some time.
[name with held by request]
Kevin Hall does a great job of stripping away the posturing that goes on in the holy FOSS crusades, here -
You did hit the nail on the head: if OSS isn't about some kind of moral or ethical shift then what is it exactly? I do get the feeling that Linus has identified that far from being a moral crusade in the tradition of the enlightenment, a crusade set around reason, logic and compromise, the whole OSS/Linux push has been propagated with the kind of zealously that would put the Spanish Inquisition to shame.The thing is, apart from the obvious weaknesses about making a lot of ballyhoo about a clanking Unix clone, it's a complete work of hypocrisy. Lots of huge corporations pour fortunes into OSS development like Oracle and HP into software like Apache and Linux. They get their development done at bargain basement prices and OSS gets a fat subsidy from select sugar daddies. Together your moral foundations are being built on quicksand. You can't fight your number one enemy (Microsoft as has been clearly stated) without making its competitors fatter in the process.
There's also two bigger problems: first no one ever elected Linus to be in charge of Linux and if it is really "free" then he shouldn't have any casting vote over it or own any of the trademarks. The weaknesses (and conversely its strengths) of Linux will stand or fall by its creator who probably shouldn't be able to operate with impunity. I think I also get a sense of impending failure: as Linux matures there is really a creeping sense of failure around the project. It hasn't blew Windows off the desktop, has made modest gains into servers and commercially has only really blossomed where cheapest is key. Much of its surrounding software is either poor quality, arcane in design and administration, outdated or a weak imitation of something commercial.
And the last word goes to reader Chad Walstrom, who's bemused by all the talk of 'moral responsibility' from the FOSS camp:
You left out the part that he believes developers have a moral obligation to make sure the software works, which would fit beautifully with your house analogy.Ouch.
So the issue seems straightforward. There are several ways of ensuring DRM is not part of our future: it can be legislated out of existence, or compensation frameworks can (and surely will) be agreed which make it unnecessary. Don't, say the Torvalds camp, bork our favorite license. Related stories
OSDL accepts GPL proliferation (18 August 2006)
Lessig, Stallman on 'Open Source' DRM (15 April 2006)
Mozilla's Google millions - a tax dodge? (14 March 2006)
Linus, GPL 3.0 and sharks with lasers on their heads (10 March 2006)
Linus: read-up on your GPL 3.0 (15 February 2006)
GPL v3.0: Linus replies (8 February 2006)
If Linus snubs new GPL, is that it for 'open source'? (6 February 2006)
No GPL 3.0 for Linux - Torvalds (26 January 2006)
Linux zealots proud to be as miserable as planes (12 December 2005)
TiVo uses the open source Linux operating system in its digital video recorders and gets a lot of heat from people in the Free and Open Source Software (FOSS) community because those boxes aren't as open as hackers would like them to be.
Oddly enough, however, Linus Torvalds, who created Linux and oversees its development, isn't among the complainers. In an e-mail interview with Forbes, he explains his position.
Forbes: TiVo is criticized for placing digital rights management restrictions on content. What is your take on this?
Torvalds: TiVo has the DRM issue (media companies have strong-armed them into not being as useful as they could be), but the thing that clashes with some in the FOSS community is that they make it hard to upgrade their box with another version of Linux. Which I personally think is OK--they made the box, they choose how to upgrade it. I only care that they give the source code back, not that they make it easy, or necessarily even possible, to play with their hardware. Again, it's the "reciprocity of source code" versus the "freedom of software" thing.
Does TiVo make it difficult to upgrade their box, or impossible? And how do they do this?
Nothing is ever "impossible." But what you can do is, for example, build a small piece of your hardware that refuses to even start up unless another (big piece) can authenticate itself properly to the small piece. The easiest way to do that is to simply cryptographically sign a binary that you're running and refuse to run it unless the cryptographic signature matches the vendor's signature. So you may have the full source code for the box, and you can build your own binary, but unless you have the vendor's private key, you're going to have a really hard time signing your new binary as being "trusted" by the hardware. Now, this is a bit offensive, isn't it? You bought the hardware. It's in your living room. And even if you knew how to fix some problem, the hardware is literally built to not allow you to.
You say what TiVo is doing is "a bit offensive." So why not use GPLv3 [GNU General Public License] to make them stop doing it?
In my worldview, it's OK for other people to do stupid things. I can complain about it, but in the end, it's their choice. If somebody offends me too much, I'll stop dealing with them. Now, I've had to limit my choice of long-distance phone companies because of this practice of mine, but I think it's more productive in the long run than trying to be "activist" with software licensing. Activism and technical decisions just don't mix well.
Why does TiVo get singled out? Aren't there other companies who do the same thing TiVo does with Linux?
I think TiVo gets singled out just because it's an example that a lot of people can relate to. It's something people understand and often interact with themselves (or know people who do). The same kind of thing happens in other embedded Linux uses too: cell phones, network routers, you name it. It's just that they don't have the name and usage recognition that TiVo has.
Part of the complaint involves the inability to upgrade Linux. But isn't DRM an issue too?
Yes. A large part of why they [TiVo] don't want people to upgrade seems to be that they're afraid of the backlash from media companies when people make a TiVo box into a streaming media server. You do realize that the TiVo hardware could easily just connect to the network (it already does), and you could watch your TiVo'ed TV shows from your computer or recode them to take them on the road with a video iPod? These things you could do if you just upgraded it yourself.
If you were to adopt GPLv3 as it is written to today, would TiVo be unable to use future versions of Linux if it also continued imposing DRM restrictions on content? Isn't that rule part of the GPLv3 draft?
That part is a bit muddled and unclear. There's a "DRM" section in the GPLv3, but the way I read it, it doesn't seem to actually say very much. More of a statement of intent than any legal argument. So I would leave arguing against that part to others.
If you did adopt GPLv3 as it is written today, how would this affect TiVo? Couldn't they just keep using and modifying old versions of Linux that were shipped before you adopted GPLv3?
Indeed, they could do that, and probably it wouldn't be a problem for TiVo. I think it would be more of an issue for the next mad scientist that comes along and wants to use Linux for something new and revolutionary, and then starts worrying about the usage restrictions. That's part of why I don't like to restrict usage. Most crazy people are just crazy, but sometimes you have somebody coming up with an odd new idea that actually turns out to be great. By not having restrictions on usage, GPLv2 doesn't restrict anything like that--it just asks for the source code.
Do you not have any desire to hack your own TiVo box?
I actually might hack it. I'm just not that interested in TV, and I'm busy enough as it is. The sad part is that people playing with your hardware is actually a good thing. Companies that make it difficult either do it because they are stupid (that certainly happens) or because they have external forces pressuring them to do so (e.g., media companies and TiVo). I could set up a totally open source PVR [personal video recorder] on one of my computers. I actually did that once, just for the heck of it. In the end, I use TiVo because it's convenient for me, and I don't care that deeply.
III. Willfulness
A willful failure has been defined as "any intentional failure as distinguished from involuntary noncompliance. No wrongful intent need be shown." In contrast, "The courts that have concluded that the failure to comply with a discovery order was not willful have emphasized the inability of the party to comply with the order."
There is no evidence before the court to indicate that SCO lacked the ability to comply with the court's orders. In fact, given SCO's own public statements outlined in part supra, it would appear that SCO had more than enough evidence to comply with the court's orders.
In December 2003, near the beginning of this case, the court ordered SCO to, "identify and state with specificity the source code(s) that SCO is claiming form the basis of their action against IBM." Even if SCO lacked the code behind methods and concepts at this early stage, SCO could have and should have, at least articulated which methods and concepts formed "the basis of their action against IBM." At a minimum, SCO should have identified the code behind their methods and concepts in the final submission pursuant to this original order entered in December 2003 ane Judge Kimball's order entered in July 2005.
Summary of Ruling Authored by: ChasF on Wednesday, June 28 2006 @ 06:23 PM EDT "IBM seeks to limit items numbers 3-112, 143-149, 165-182, 186-193, 232-271, 279-293." Here are the ones left:
- 23
- 43
- 90
- 94
- 186
- 187
- 188
- 189
- 190
- 191
- 192
Summary of Ruling - Part 2 Authored by: ChasF on Wednesday, June 28 2006 @ 06:38 PM EDT There were 294 claims of which IBM objected to 198. Only 11 of the objections have been denied, so this means that 107 claims are valid right now.
The remaining items are:
- 001-002
- 023
- 043
- 090
- 094
- 113-142
- 150-164
- 183-192
- 194-231
- 272-2 78
- 294
Summary of Ruling - Part 2 Authored by: PolR on Wednesday, June 28 2006 @ 07:12 PM EDT item 294 was abandonned by SCOG. See the chart linked by the first post in this
thread.Wells Grants in Part IBM's Motion to Limit SCO's Claims! Authored by: Anonymous on Wednesday, June 28 2006 @ 06:08 PM EDT I'm just reading the order now. The language seems
decidedly "non-judgelike" to me. I'm wondering if this
may be a red herring.
(Specifically thinking of the "If however, the level of
specificity did not require specific source code then IBM
has fired a wayward shot off the starboard bow in its
attempt to sink SCO s ship." from page 22.)
Wells Grants in Part IBM's Motion to Limit SCO's Claims! Authored by: Jaywalk on Wednesday, June 28 2006 @ 06:29 PM EDT ---
===== Murphy's Law is recursive. =====
Style and Grammar Authored by: Felix_the_Mac on Wednesday, June 28 2006 @ 09:27 PM EDT <The language seems decidedly "non-judgelike" to me>
I agree, I was suprised how loose the style was, and also by the significant
number of grammatical & punctation mistakes.
On the other hand, the broad construction and detail of the judgement are
excellent.
Wells Grants in Part IBM's Motion to Limit SCO's Claims! Authored by: swiftest on Thursday, June 29 2006 @ 09:29 AM EDT This is a case about unauthorized copying, ie., "piracy." The wayward
shot fired off the starboard bow is amusingly apropos as it brings to mind two
galleons firing canonballs on the high seas. The judge knew exactly what she was
writing here. Kudos for humor and wit!
non-judgelike interpretation Authored by: Anonymous on Monday, July 03 2006 @ 10:28 AM EDT To my reading, it's very much judge like [disclaimer: my father was a federal
judge]. She's explaining that SCO should have given line, file and version
information regardless;
If IBM was trying to sink SCO's ship, and SCO provided line and file
information, IBM would have missed wildly. If SCO believed they didn't have to
produce line and file information, their own comments missed wildly. Her point
was that no matter how SCO wants to look at it (from IBM's point of view or
their own), they should have produced line file and version information. It
couldn't possibly have hurt them (if their case had merit - heh!), and their own
comments and motions support the need for source code during analysis.
From Open Source
Vol. 2, No. 3 - May 2004
by Jay Michaelson, Wasabi SystemsWhat every developer should know about open source licensing
"The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software to make sure the software is free for all its users."1 So begins the GNU General Public License, or GPL, which has become the most widely used of open source software licenses. Freedom is the watchword—it's no coincidence that the organization that wrote the GPL is called the Free Software Foundation—and that open source developers everywhere proclaim, "Information wants to be free."
United States District Court, Southern District of Indiana,Judge Sarah Evans Barker,Judge John Daniel Tinder, Judge Richard L. Young, Magistrate Judge V. Sue ShieldsCase 1-05-cv-678
For any documents filed but not yet indexed here, they may be in the case's document directory.Exhibits: hide | expand all | normal | (set preference as cookie)
Display: alphabetical | recently updated | motions | calendar
- [info] 1 [PDF] - Wallace's Complaint [Wallace v. IBM 1] agains International Business Machines Corporation, Red Hat Inc., and Novell, Inc. [ Groklaw ]
- [info] 2 [PDF] - Order of Reference [Wallace v. IBM 2] of Case to Magistrate Judge
- [info] 3 [PDF] - Summons [Wallace v. IBM 3] Issued to International Business Machines Corporation, Red Hat Inc., Novell, Inc. [ Groklaw ]
- [info] 4 - Wallace's Receipt [Wallace v. IBM 4] Regarding Payment of Filing Fee
- [info] 5 [PDF] - Wallace's Return of Service [Wallace v. IBM 5] of Complaint
- [info] 6 - Red Hat's Notice [Wallace v. IBM 6] of Appearance by Philip A. Whistler
- [info] 7 - Red Hat's Notice [Wallace v. IBM 7] of Appearance by Curtis W. McCauley
- [info] 8 [PDF] - Red Hat's Notice [Wallace v. IBM 8] of First Extension of Time [ Groklaw ]
- [info] 9 [PDF] - IBM's Notice [Wallace v. IBM 9] of Appearance by Kendall H. Millard
- [info] 10 [PDF] - IBM's Notice [Wallace v. IBM 10] of First Extension of Time [ Groklaw ]
- [info] 11 - Novell's Notice [Wallace v. IBM 11] of Appearance by Philip A. Whistler
- [info] 12 - Novell's Notice [Wallace v. IBM 12] of Appearance by Curtis W. McCauley
- [info] 13 [PDF] - Novell's Notice [Wallace v. IBM 13] of First Extension of Time [ Groklaw ]
- [info] 14 [PDF] - Notice [Wallace v. IBM 14] of Pretrial Conference set for July 28, 2005 at 2:30 P.M. (2005-06-20)
- [info] 15 [PDF] - IBM's Notice [Wallace v. IBM 15] of Appearance by Michael H. Gottschlich (2005-06-21)
- [info] 16 [PDF] - RedHat's Unopposed Motion [Wallace v. IBM 16] for Additional Extension of Time (2005-06-30)
- [info] 16-1 [PDF] - RedHat's Proposed Order [Wallace v. IBM 16-1] Granting Unopposed Motion for Additional Extension of Time (2005-06-30)
- [info] 17 [PDF] - IBM's Motion [Wallace v. IBM 17] to Dismiss (2005-06-30) [ Groklaw text ]
- [info] 18 [PDF] - IBM's Memorandum [Wallace v. IBM 18] in Support of IBM's Motion [Wallace v. IBM 17] to Dismiss (2005-06-30) [ Groklaw text ]
- [info] 19 [PDF] - Wallace's Motion [Wallace v. IBM 19] for Summary Judgment (2005-06-30)
- [info] 20 [PDF] - Wallace's Memorandum [Wallace v. IBM 20] on Motion for Summary Judgment [Wallace v. IBM 19] (2005-06-30) [ Groklaw text ]
- [info] 21 - Wallace's Exhibits [Wallace v. IBM 21] to Motion [Wallace v. IBM 19] for Summary Judgment
- [info] 21-5 [PDF] - Wallace's Hardcopy [Wallace v. IBM 21-5] of the GPL
- [info] 22 [PDF] - Wallace's Answer Brief [Wallace v. IBM 22] to IBM's Motion to Dismiss [Wallace v. IBM 17] (2005-07-01)
- [info] 23 [PDF] - Wallace's Motion [Wallace v. IBM 23] to Amend Complaint (2005-07-05)
- [info] 23-1 [PDF] - Wallace's Proposed Amended Complaint [Wallace v. IBM] (2005-07-05) [ Groklaw text ]
- [info] 24 [PDF] - Order [Wallace v. IBM 24] Granting Red Hat's Motion for Extension of Time to File Answer to the Complaint to 7/6/2005 (2005-07-05)
- [info] 25 [PDF] - Red Hat's Motion [Wallace v. IBM 25] to Dismiss the Complaint (Counsel also represents Novell) (2005-07-06) [ Groklaw text ]
- [info] 26 [PDF] - Red Hat's Brief [Wallace v. IBM 26] in Support of Motion [Wallace v. IBM 25] to Dismiss Complaint (Counsel also represents Novell) (2005-07-06)
- [info] 27 - Wallace's Memorandum [Wallace v. IBM 27] in Opposition to Red Hat's Motion [25] to Dismiss (2005-07-07)
- [info] 28 - Order [Wallace v. IBM 28] Denying [17] IBM's Motion to Dismisss, Granting [23] Wallace's Motion to Amend/Correct Complaint, Signed July 11, 2005 by Judge Sarah Evans Barker (2005-07-11)
- [info] 29 - Wallace's Amended Complaint [Wallace v. IBM 29] against International Business Machines Corporation, Red Hat Inc., Novell Inc. (2005-07-12)
- [info] 30 - Red Hat's Notice [Wallace v. IBM 30] of Potentially Related Case (2005-07-13)
- [info] 31 - Case Reassigned [Wallace v. IBM 31] to Judge John Daniel Tinder (2005-07-19)
- [info] 32 - IBM's Motion [Wallace v. IBM 32] to Dismiss the Amended Complaint (2005-07-19)
- [info] 33 - IBM's Memorandum [Wallace v. IBM 33] in Support of [32] IBM's Motion to Dismiss the Amended Complaint (2005-07-19)
- [info] 34 - IBM's Motion [Wallace v. IBM 34] for Continuance of Pretrial Conference [DUPLICATE FILING--SEE 35 AND DISREGARD]
- [info] 35 - IBM's Motion [Wallace v. IBM 35] for Continuance of Pretrial Conference (2005-07-19)
- [info] 36 - Order [Wallace v. IBM 36] Granting [35] IBM's Motion for Continuance of Pretrial Conference, Reset for 8/18/2005 2:00pm in room #256 before Magistrate Judge V. Sue Shields. Signed by Judge V. Sue Shields on 7/21/05 (2005-07-21)
- [info] 37 - Case Reassigned [Wallace v. IBM 37] to Judge Richard L. Young (2005-07-22)
- [info] 38 - Wallace's Memorandum [Wallace v. IBM 38] in Opposition to [32] Motion to Dismiss the Amended Complaint (2005-07-22)
- [info] 39 - IBM's Response Memorandum [Wallace v. IBM 39] in Support of [32] Motion to Dismiss the Amended Complaint (2005-08-05)
- [info] 40 - Red Hat and Novell's Motion [Wallace v. IBM 40] to Dismiss Wallace's Amended Complaint (2005-08-08)
- [info] 41 - IBM's Motion [Wallace v. IBM 41] to Stay Briefing on Wallace's Motion for Summary Judgment and to Stay Pretrial Conference (2005-08-09)
- [info] 42 - Wallace's Memorandum [Wallace v. IBM 42] in Opposition to [32] IBM's Motion to Dismiss Wallace's Amended Complaint, [40] Red Hat and Novell's Motion to Dismiss Wallace's Amended Complaint, [25] Motion to Dismiss Wallace's Complaint (2005-08-11)
- [info] 43 - Order [Wallace v. IBM 43] Denying [41] IBM's Motion to Stay Pretrial Conference. Motion to Stay Briefing on Wallace's Motion for Summary Judgment will be discussed at Initial Pretrial Conference. Signed August 15, 2005 by Judge V. Sue Shields (2005-08-15)
- [info] 44 - Minute Entry [Wallace v. IBM 44] for Pretrial Conference held August 18, 2005 before Judge V. Sue Shields (2005-08-18)
- [info] 45 - Red Hat and Novell's Unopposed Motion [Wallace v. IBM 45] for Extension of Time to File Response Memorandum in Support of [40] Motion to Dismiss the Amended Complaint (2005-08-29)
- [info] 46 - Red Hat and Novell's Reply Memorandum [Wallace v. IBM 46] in Support of [40] Motion to Dismiss Wallace's Amended Complaint (2005-09-01)
- [info] 47 [PDF] - Order [Wallace v. IBM 47] Denying as Moot [41] IBM's Motion to Stay, Granting [45] Motion for Extension of Time to File Reply, Denying [19] Wallace's Motion for Summary Judgment, Signed November 28, 2005 by Judge Richard L. Young (2005-11-28)
- [info] 48 - Wallace's Motion [Wallace v. IBM 48] to Amend Complaint (2005-12-01)
- [info] 49 - Notice [Wallace v. IBM 49] of Change of Firm Form and Name by Curtis W. McCauley (2006-01-05)
- [info] 50 - Order [Wallace v. IBM 50] Denying as Moot [40] Motion to Dismiss, Granting [48] Motion to Amend, Denying as Moot [25] Motion to Dismiss, Denying as Moot [32] Motion to Dismiss, Signed January 18, 2006 by Judge Richard L. Young (2006-01-18)
- [info] 51 - IBM's Motion [Wallace v. IBM 51] to Dismiss Wallace's Second Amended Complaint (2006-02-01)
- [info] 52 - IBM's Memorandum [Wallace v. IBM 52] in Support of [51] IBM's Motion to Dismiss (2006-02-01)
- [info] 53 - RedHat and Novell's Reasserted Motion [Wallace v. IBM 53] to Dismiss Wallace's Second Amended Complaint (2006-02-01)
- [info] 54 - Wallace's Memorandum [Wallace v. IBM 54] in Opposition to [53] Reasserted Motion to Dismiss (2006-02-06)
- [info] 55 - Wallace's Memorandum [Wallace v. IBM 55] in Opposition to [53] Reasserted Motion to Dismiss (2006-02-07)
- [info] 56 - IBM's Reply Memorandum [Wallace v. IBM 56] in Support of [51] Reasserted Motion to Dismiss (2006-02-21)
- [info] 57 - RedHat's Reply Memorandum [Wallace v. IBM 57] in Support of [53] Reasserted Motion to Dismiss (2006-02-21)
- [info] 58 - RedHat's Submission [Wallace v. IBM 58] of Supplemental Authority in Support of Reasserted Motion to Dismiss (2006-03-22)
- [info] 58-1 [PDF] - Order [Wallace v. FSF 41] Granting [34] FSF's Motion to Dismiss. Mr. Wallace is DENIED leave to further amend his complaint, Signed March 20, 2006 by Judge John Daniel Tinder (2006-03-20) [ Groklaw ]
United States District Court, Southern District of Indiana, Judge John Daniel Tinder, Magistrate Judge Tim A. Baker
Case 1-05-cv-618
For any documents filed but not yet indexed here, they may be in the case's document directory.
Exhibits: hide | expand all | normal | (set preference as cookie)
Display: alphabetical | recently updated | motions | calendar
- [info] 1 [PDF] - Wallace's Complaint [Wallace v. FSF 1] Against Free Software Foundation, Inc. (2005-04-28)
- [info] 2 [PDF] - Order of Reference [Wallace v. FSF 2] of Case to Magistrate Judge (2005-04-28)
- [info] 3 [PDF] - Summons [Wallace v. FSF 3] (2005-04-28)
- [info] 4 [PDF] - Wallace's Receipt [Wallace v. FSF 4] Regarding Payment of Filing Fee (2005-04-28)
- [info] 5 [PDF] - Wallace's Motion [Wallace v. FSF 5] to Amend Complaint (2005-04-29)
- [info] 6 [PDF] - Wallace's Second Motion [Wallace v. FSF 6] to Amend Complaint (2005-05-03)
- [info] 7 [PDF] - Wallace's Proof of Service [Wallace v. FSF 7] of Complaint (2005-05-07)
- [info] 8 [PDF] - Free Software Foundation's Notice [Wallace v. FSF 8] of Appearance by Philip A. Whistler (2005-05-17)
- [info] 9 [PDF] - Free Software Foundation's Notice [Wallace v. FSF 9] of Appearance by Curtis w. McCauley (2005-05-17)
- [info] 10 [PDF] - Free Software Foundations Notice [Wallace v. FSF 10] of Initial 30-Day Enlargement of Time to Respond to Complaint (2005-05-17)
- [info] 11 [PDF] - Wallace's Motion [Wallace v. FSF 11] for Summary Judgment (2005-05-19)
- [info] 12 [PDF] - Wallace's Memorandum [Wallace v. FSF 12] on Motion for Summary Judgment (2005-05-19)
- [info] 13 [PDF] - Order [Wallace v. FSF 13] Granting Wallace's Motion to Amend Complaint and Wallace's Second Motion to Amend Complaint (2005-06-07)
- [info] 14 [PDF] - Wallace's Amended Complaint [Wallace v. FSF 14] (2005-04-29)
- [info] 15 [PDF] - Wallace's Second Amended Complaint [Wallace v. FSF 15] (2005-05-03)
- [info] 16 [PDF] - Free Software Foundation's Motion [Wallace v. FSF 16] to Dismiss the Complaint (2005-06-22) [ Groklaw ]
- [info] 17 [PDF] - Free Software Foundations Memorandum [Wallace v. FSF 17] in Support of [Wallace v. FSF 16] Motion to Dismiss (2005-06-22) [ Groklaw text ]
- [info] 17-A [PDF] - The GPL [ gnu.org ]
- [info] 18 [PDF] - Free Software Foundation's Motion [Wallace v. FSF 18] to Stay Briefing on [Wallace v. FSF 11] Wallace's Motion for Summary Judgment (2005-06-22) [ Groklaw ]
- [info] 18-A [PDF] - Free Software Foundation's Proposed Order [Wallace v. FSF 18-A] on Motion to Stay Briefing on Wallace's Motion for Summary Judgment [ Groklaw ]
- [info] 19 [PDF] - Wallace's Answer [Wallace v. FSF 19] to FSF's Motion [Wallace v. FSF 18] to Stay Briefing on Wallace's Motion for Summary Judgment (2005-06-24) [ Groklaw ]
- [info] 20 [PDF] - Wallace's Answer [Wallace v. FSF 20] to FSF's Motion [Wallace v. FSF 16] to Dismiss (2005-06-23) [ Groklaw ]
- [info] 21 [PDF] - Wallace's Answer [Wallace v. FSF 21] Brief to FSF's Motion [Wallace v. FSF 16] to Dismiss (2005-06-23) [ Groklaw ]
- [info] 22 [PDF] - Wallace's Motion [Wallace v. FSF 22] for Leave to Submit Supplemental Declaration of Plaintiff Daniel Wallace [ Groklaw ]
- [info] 23 [PDF] - Wallace's Third Motion [Wallace v. FSF 23] to Amend Complaint (2005-07-05)
- [info] 24 - FSF's Motion [Wallace v. FSF 24] for Extension of Time to File Reply Memorandum in Support of [16] FSF's Motion to Dismiss (2005-07-24)
- [info] 25 - FSF's Notice [Wallace v. FSF 25] of Potentially Related Case (2005-07-13)
- [info] 26 - FSF's Reply Memorandum [Wallace v. FSF 26] in Support of [16] FSF's Motion to Dismiss (2005-07-15)
- [info] 27 - Order [Wallace v. FSF 27] Granting [18] Motion to Stay, Granting [22] Motion for Leave to File a Supplemental Declaration, Granting [23] Motion to Amend Complaint, Granting [24] Motion for Extension of Time to File Reply Memorandum, Signed September 12 by Judge John Daniel Tinder (2005-09-12)
- [info] 28 - Wallace's Third Amended Complaint [Wallace v. FSF 28] against Free Software Foundation (2005-09-12)
- [info] 29 - Wallace's Supplemental Declaration [Wallace v. FSF 29] (2005-09-12)
- [info] 30 [PDF] - Order [Wallace v. FSF 30] Granting [16] FSF's Motion to Dismiss, Signed November 28, 2005 by Judge John Daniel Tinder (2005-11-28)
- [info] 31 - Wallace's Fourth Amended Complaint [Wallace v. FSF 31] (2005-11-30)
- [info] 32 [PDF] - FSF's Unopposed Motion [Wallace v. FSF 32] for Extension of Time to Respond to [31] Wallace's Fourth Amended Complaint (2005-12-19)
- [info] 33 [PDF] - Order [Wallace v. FSF 33] Granting [32] FSF's Motion for Extension of Time to File Response to Wallace's Fourth Amended Complaint to December 29, 2005, Signed December 20, 2005 by Judge Tim A. Baker (2005-12-20)
- [info] 34 - FSF's Motion [Wallace v. FSF 34] to Dismiss Wallace's Fourth Amended Complaint (2005-12-29)
- [info] 35 - FSF's Memorandum [Wallace v. FSF 35] in Support of [34] Motion to Dismiss Wallace's Fourth Amended Complaint (2005-12-29)
- [info] 36 - Wallace's Memorandum [Wallace v. FSF 36] in Opposition to [34] FSF's Motion to Dismiss Wallace's Fourth Amended Complaint (2006-01-03)
- [info] 37 - Notice [Wallace v. FSF] of Change of Firm Form and Name (2006-01-04)
- [info] 38 - FSF's Motion [Wallace v. FSF 38] for Extension of Time to January 24, 2005 to file Reply Memorandum in Support of [34] Motion to Dismiss Wallace's Fourth Amended Complaint (2006-01-17)
- [info] 39 - FSF's Reply Memorandum [Wallace v. FSF 39] in Support of [34] FSF's Motion to Dismiss Wallace's Fourth Amended Complaint (2006-01-24)
- [info] 40 - Order [Wallace v. FSF 40] Granting [38] FSF's Motion for Extension of Time to File Reply Memorandum, Signed January 26, 2006 by Judge John Daniel Tinder (2006-01-26)
- [info] 41 [PDF] - Order [Wallace v. FSF 41] Granting [34] FSF's Motion to Dismiss. Mr. Wallace is DENIED leave to further amend his complaint, Signed March 20, 2006 by Judge John Daniel Tinder (2006-03-20) [ Groklaw ]
- [info] 42 - Closed Judgment [Wallace v. FSF 42] in favor of Defendant against Plaintiff. Costs shall be allowed the Defendant. Signed March 20, 2006 by Judge John Daniel Tinder (2006-03-20)
http://linuxbusinessnews.sys-con.com/read/80782.htm
The Free Software Foundation (FSF) and the General Public License (GPL), the great enabler of the open source movement, were sued last Thursday for restraint of trade under the Clayton Antitrust Act (15 US Code Section 26) in the US District Court for the Southern District of Indiana.
The pro se suit, filed by physicist, computer programmer and Groklaw gadfly Daniel Wallace, charges that the GPL “contract licensing scheme” artificially fixes software prices.
Wallace is asking the court for an injunction that would outlaw the use of the GPL in the United States .
The four-page suit claims that the “Free Software Foundation has entered into contracts and otherwise conspired and agreed with individual software authors and commercial distributors of commodity software products such as Red Hat Inc. and Novell Inc. to artificially fix the prices charged for computer software programs through the promotion and use of an adhesion contract that was created, used and promoted since at least the year 1991 by the Free Software Foundation Inc. This license is known as the GNU General Public License. The price -fixing scheme implemented with the use of the GNU General Public License substantially lessens the ability of individual software authors to compete in a free market through the creation, sale and distribution of computer software programs.”
Mr. Wallace claims that his “ability to work and create commercial computer programs is dependent upon a market free of restraints on trade through price-fixing schemes” and that the “rapid adoption of the GNU General Public License in schemes to deflate or eliminate the free market valuation of computer programs threatens to diminish or destroy [his] ability to earn future revenues in the career field of computer programming.” He said in an interview on Sunday that he would probably ask the court for a summary judgment.
Even open source advocates have expressed doubt that the GPL can stand up in court and credit the Free Software Foundation’s skillful avoidance of a legal showdown for preserving the GPL this long. Larry Rosen, the former general counsel of the Open Source Initiative ( OSI ), the body that authorizes open source licenses, has called the GPL and LGPL an “impenetrable maze of technological babble” and has raised questions as to the GPL’s legitimacy because of its obtuseness, its idiosyncratic misinterpretation of copyright law, its lumping of collective works in with outlawed derivative works and treating them like they’re the same thing, and its legally untenable position of forbidding anyone from linking unmodified GPL and non-GPL software.
Open source zealots would claim that software doesn’t rest as firmly on copyright law as Rosen suggests and that the copyright claim basic to Rosen’s argument can be shot full of holes.
The only known time the GPL has been hauled into an American court was in 2001-2002 during a contract flap between MySQL AB and its then US distributor, NuSphere, the Progress Software subsidiary. Progress sued for breach of contract and MySQL countersued charging NuSphere with trademark infringement and breaking the GPL in federal court in Massachusetts .
The GPL charge wasn’t central to the case and its validity wasn’t specifically ruled on, but before the case was settled out-of-court in late 2002, the judge hearing it purportedly deemed the GPL “enforceable and binding.”
At least that’s what the Free Software Foundation, which helped MySQL out with the case, said she said after a go at mediation failed and the case bounced back to her court.
According to what was reported at the time, Judge Patti Saris didn’t use the words “enforceable and binding” in open court but the Free Software Foundation, which had filed an affidavit in support of MySQL, insisted that’s what she meant.
Evidently the judge never questioned the GPL license, quoted sections of it at Progress’ chief counsel, asked how exactly NuSphere had complied with this or that GPL term, indicated that Progress needed to comply with the license and told MySQL lawyers that they could come back with a new motion for a preliminary injunction stopping NuSphere from selling the MySQL database if discovery indicated NuSphere hadn’t fully complied with the GPL.
The judge refused to grant an injunction MySQL wanted at that point because she wasn’t convinced MySQL had been irreparably harmed and anyway NuSphere was back in compliance with the GPL by then.
The GPL part of the squabble revolved around the central gotcha in the GPL that scares a lot of people off open source. NuSphere had linked a proprietary storage module called Gemini to MySQL and didn’t immediately provide the Gemini source code although it did a few months later, theoretically bringing it into compliance.
When a GPL product is combined with a non-GPL product, the GPL says the source code for the non-GPL product has to be released. NuSphere claimed its Storage Engine didn’t have to be GPL’d because it wasn’t a MySQL derivative. It was based on technology that Progress had developed years before and used elsewhere.
NuSphere maintained that it hadn’t violated the GPL at all. It said the idea that it violated the license by statically linking proprietary software to MySQL is an extreme interpretation of the GPL.
It also claimed that MySQL had broken the GPL by adding conditions, something GPL disallows, demanding that a commercial license be used for code distributed over a network because of linking.
NuSphere had a problem with the Free Software Foundation’s view that even a trivial violation of the GPL puts the licensee at the mercy of the licensor, who may legally refuse to re-authorize the licensee to distribute the licensor’s GPL software even if the licensee fully rectifies his earlier violation.
Ironically, NuSphere underwrote MySQL’s shift to the GPL and reimbursed the company, then known as TCX Datakonsult, for losses it might suffer from going GPL. MySQL previously used a semi-open license of its own called the Free Public License as well as a traditional commercial license.
For those who are looking for it, Mr. Wallace’s suit against the Free Software Foundation is Civil Complaint No. 1:05-cv-0618-JDT-TAB.
Daniel Wallace is an American professor and physicist (according to his lawsuit document, he has a BS in physics). He is well-known on the Internet for his personal theories about the GPL being a contract, not a license, and for attacking it. He is a member of the Free Software Foundation (FSF), which is something open to anyone. His motive for joining is unknown, however one journalist used his membership to spin a story that a member of the FSF had accepted SCO's anti-GPL claims. His primary claim to fame is having sued the FSF.
In 2005, Daniel Wallace filed a suit in Indiana, stating that the GPL, by requiring copies of any program's code to be made available at no cost, is tantamount to price fixing. However, the GPL FAQ is clear that while you can't charge for the license, you can charge for your code. In fact, Richard Stallman himself supported himself from some of the early years doing exactly that.
This case involves the GNU General Public License (GPL), which governs the use of many products sold and distributed by the Free Software Foundation (FSF), including GNU/Linux operating systems. The GPL requires, among another things, that users who distribute or publish any work derived from GPL-covered software to license that work to under the GPL to all third parties at no charge. The plaintiff, Daniel Wallace (Wallace), was not a user of FSF software; rather, he was a competitor of FSF’s, trying to sell his own operating system. Wallace brought an action pro se against FSF claiming that it was conspiring with commercial distributors IBM, RedHat, Novell, and others to fix prices for intellectual property in the market by attaching the GPL to GNU/Linux operating system software. Wallace claimed, in essence, that the GPL constituted a horizontal price-fixing scheme among competitors in violation of Section 1 of the Sherman Antitrust Act and sought to enjoin FSF from developing and distributing Linux under the GPL. On motion by FSF, Judge Tinder of the United States District Court for the Southern District of Indiana dismissed the complaint for failure to show any “antitrust injury” from FSF’s conduct, but held that Wallace had otherwise stated a claim upon which relief could be granted.
In his third amended complaint, Wallace alleged that FSF was conspiring with its competitors to fix prices for software via the GPL. The court determined that Wallace was effectively claiming the existence of a horizontal price-fixing agreement, which would be illegal per se under the Section 1 of the Sherman Antitrust Act (prohibiting contracts and conspiracies in restraint of trade) because such horizontal arrangements are perceived to have a “pernicious effect” on competition. By comparison, vertical agreements (those between enterprises at different levels within the same chain of distribution) are governed by a “rule of reason” analysis because their effects will not always be anticompetitive. The court determined that the GPL could not be reasonably characterized as a horizontal agreement because it governs agreements between licensees and licensors, who are users at different levels within the same chain of distribution. Therefore, the court reasoned, the GPL is a vertical agreement, and it cannot alone constitute a per se violation of the Sherman Act.
The court then analyzed the GPL under the rule of reason to determine whether it might be an unreasonable restraint of trade. Under the rule of reason, a vertical licensing agreement may violate the Sherman Act if it produces adverse, anti-competitive effects such as a reduction in output, increase in price, or deterioration in the quality of goods and services, among other factors. FSF argued that its practice of allowing free access to software with the GPL aids competition rather than hinders it. However, the court held that the GPL may have an anticompetitive effect by discouraging software developers from creating better programs for Linux (since they could not be adequately compensated) and reducing the number of quality programs available to consumers. Thus, Wallace’s complaint sufficiently alleged a violation of the Sherman Act.
However, the complaint ultimately failed because the court found that Wallace had suffered no antitrust injury, i.e., injury of the sort that the antitrust laws are designed to prevent. Examining Wallace’s complaint, the court found that his only alleged injury was an inability or unwillingness to enter into the software business because he could not compete with users of Linux. Because this is an injury to a (potential) competitor rather than an injury to consumers or to competition itself, the court found no antitrust injury and dismissed the complaint.
Subject: Promiscuous Source
Date: Thu, 01 Apr 1999 23:13:09 -0500
From: David Wallace Croft <[email protected]>
Organization: ANSER WV
CC: [email protected]
Newsgroups: netscape.public.mozilla.license
> I want to write free ("freed") software, in the sense used by the Free
> Software Foundation (www.fsf.org) whilst avoiding the GPL because of
> license-virus effects. Should I use the Mozilla Public License (MPL) or the
> GNU Library General Public License (LGPL)?
I realize that you were asking about the LGPL, not the GPL, but I want to take this opportunity to launch into the GPL versus MPL debate.There are discussions and comparisons of the various Open Source the recently released book "Open Sources: Voices from the Open Source Revolution".
Also, Richard Stallman gives his view of the GPL vs. MPL debate here:
http://www.gnu.org/philosophy/netscape-npl.html
I disagree.It is my opinion that MPL is more free than GPL. It is certainly less restrictive given the "viral" nature of GPL that you mentioned. Public Domain release and the X Consortium/MIT style licenses are by far the most free in that they have little to no restrictions. Why then, if you want your code to be free, would you not simply release the code as Public Domain?
There are two potential reasons:
- You cannot bear to think of anyone besides yourself being able to sell the software.
- You wish to see your code propagate and evolve as far and as long as possible.
GPL meets the first objective while MPL meets the second.
1. You cannot bear to think of anyone besides yourself being able to sell the software.
The GPL prevents code from being sold by itself or as part of a larger work. However, it leaves the door open for the authors to commercially sell the code under different licensing terms if they so choose. For example, this can easily occur:
What does this mean? It means that the GPL is a nice hedge for an author or organization who wants to reserve the exclusive right to commercially sell the software at some future point without competition.
- a single author may initially release code as GPL;
- the author later decides that the code has commercial viability;
- the author stops distributing the code with the GPL.
- the author then reissues the exact same code with a fee-based license.
How can this be?
First, realize that the GPL only binds the licensees, not the original author that holds the unrestricted copyright. The originator can always release the code under other licenses if he so chooses. I have seen a number of websites where the authors release the code as GPL but also advertise that they would be willing to accept licensing fees from those who would wish to sell their code as part of a proprietary larger work. Again, they maintain the exclusive license for commercial sale because the GPL does not release this right to the public.
The MPL, on the other hand, releases this right to all licensees thereby ensuring that if any originating author or organization wanted to stop distributing the code as Open Source and sell it commercially under a different license, they would have to compete. The threat of commercial competition is what dissuades the originator from doing so. Likewise, the commercial competition is unlikely to arise due to the same threat from yet other parties since everyone has been granted the right to commercialize. Thus, the code remains free. True of MPL, not true of GPL.
To be fair to GPL, when there are a large number of contributors in the creation of derivative works, it is really impossible to track down all of those individuals, or their heirs, and get them to unanimously agree to license their rights for commercial sale. So, in effect, on a work with a large number of contributors, the code can never be sold nor mixed with any non-GPL larger work. I believe this was Stallman's intent, that no one should be allowed to sell code.
Even if the number of contributors is small or none, it achieves the goal of preventing even the original copyright holder and cooperating contributors from being able to exclusively sell the code under different license terms so long as one individual is willing to archive the code with the original GPL attached at some public site. This defeats the commercial sale incentive. However, this assumes that the original copyright holder cannot stamp out the GPL distribution sites, by simply discontinuing support from its own sites and by offering compensatory incentives to others, quickly enough before it spreads. As the original copyright holder maintains the exclusive right to sell the code, i.e., others can give away the code but not sell it, only the original copyright holder has the resources and the incentive to stamp out the distribution site. As a contributing factor, as the other distribution sites do not have the exclusive right to sell the software, they only way the can make money off of the code is to accept a fee from the originator in exchange for signing an agreement not to continue to distribute the code with the GPL attached.
For example, an organization releases its code as GPL. Soon thereafter it changes its mind and decides to commercially sell the code. It then goes to the employees, perhaps the employees who authored the code but do not actually own the copyright, and offers them incentives not to distribute the code as a GPL licensee from their personal websites. For those former employees who have left the organization but have taken the source code with them as GPL licensees, the organization makes similar arrangements with them but perhaps must offer greater compensation for signing the agreement.
MPL does not have this weakness. Assume the above scenario but swap GPL with MPL. The organization changes its mind and decides to commercially sell the code as before, with the difference being that it has already licensed the ability to sell the code to the public; it no longer has the right to sell the code exclusively. The costs of buying back the exclusive right to sell the code would be prohibitive, even if no one from the public bothered to archive the code at an alternative site, because the employees and former employees now get to weigh the financial incentives of competing with their employer against taking the lump sum for agreeing not to compete. Again, this is because those who release their code under the MPL give up their right to sell the code exclusively; not so under the GPL.
2. You wish to see your code propagate and evolve as far and as long as possible.
First, MPL allows code to propagate and evolve better than GPL because it removes any financial incentive from the originator to attempt to later "close" the source since it effectively terminates the original copyright holder's right to sell the code exclusively, as described in depth above.
Second, MPL possesses a prolific reproduction and evolution feature that simple Public Domain release and the X consortium/MIT licenses lack. This is the requirement that all licensees must distribute the source code with any compiled work, including derivative works.
The GPL also contains this reproduction/evolution feature but the GPL version is inferior to that of MPL in that it is "viral", causing many individuals and organizations to immunize themselves against the use of such. The GPL requires that any larger work that encompasses even just a single component of GPL code be released in its entirety as GPL.
Why is this a bad thing?
First, it prevents the use of code released under other Open Source licenses, with the exception of Public Domain, from being used in combination to create a larger work. For example, suppose that you have located a third of the source code components that you need for your project under the GPL, another third under the X consortium/MIT style licenses, and the final third as Public Domain. Problem solved? No, you will either have to rewrite the GPL or the X consortium/MIT components as GPL will not co-exist with the other.
Second, even if one were willing to blindly port or write code as entirely GPL, it reduces innovation in the evolution of Open Source licenses themselves. Requiring that the only Open Source license to be used be GPL is pure arrogance in assuming that the GPL is final culmination in the development of the expression of a license that will "free" source code.
Third, the GPL prevents developers in commercial environments from contributing to the Open Source movement. For example, suppose an employed software developer in a commercial organization desperately wishes to contribute code to be released to the public as Open Source. The component which he will be writing may not be considered to have commercial interest to the organization but may have much use to the public in other application domains. Furthermore, the developer may wish to be able to not to have to rewrite the code from scratch but to build upon and improve upon the work of others and contribute the derivative work back to the public. If the prior work is in GPL, the organization will immediately rule out the use of such because it would require the larger work as a whole to be released as GPL, components of which they do have a commercial interest in. This restriction comes to be despite the fact that the component that the developer will be working on has no commercial interest to the organization. In fact, the organization, not just the developer, might be pleased to contribute the work on the component back to the public if they could do in such a way that would not interfere with their proprietary interests.
The GPL in effect eliminates the ability of software developers that work for commercial entities, which is the overwhelming share of the developers at large, from participating in the Open Source movement.
Why, then, do not the organizations and developers simply release their work, for which they have no commercial interest, under the terms of some Open Source license other than GPL? They can certainly do that but it sometimes means that they must then develop the code from scratch instead of building upon the work of others. This is especially true if other developers, in their lack of knowledge of how GPL is less open and less free than other more promiscuous Open Source licenses such as MPL, are reluctant to release their work under Open Source licenses beyond GPL which the developers working for commercial organizations could then improve and return.
Furthermore, the commercial organization may not be willing to originate Open Source code but might be willing to allow a developer to build upon an existing Open Source work and release the derivative work back to the public. That is to say, if the organization has to employ the developer to build it from scratch, the management might, in their failure to understand the indirect benefits of releasing code as Open Source, decide to keep the software closed for some possible potential commercial interest that might pop up in the far future. If, on the other hand, Open Source code is available that can be reused and adapted that would require less man-hour efforts on the part of their employed developer, the management would happily allow the developer to use, evolve, and distribute the derivative work -- so long as the use of such did not require the organization to abandon their commercial interests in the larger work.
If originators who have already released their code as GPL are understanding of the situation the commercial developer is in and are willing to release the code under another Open Source license such as MPL as well, the commercial developer would happily reciprocate by returning as much code as possible to the public as a derivative work under the terms of the Open Source license which allows him to do so in his given environment.
While this does imply that the commercial organization that employs the developer will now have the ability to sell a larger work that incorporates code that used to be exclusively GPL, so long as the originators do not mind giving up their exclusive right to commercially sell the code themselves in exchange for the good of seeing their code disseminated and evolved as much as possible, it will work out for the best for everyone.
The MPL avoids the three problems associated with the "viral" nature of GPL in that it:
I state in this essay that MPL is more free and open than GPL. If what we believe about the organic nature of Open Source is true, then time will either prove or disprove my thesis that MPL is superior to GPL in that, over the long-run and on the whole, MPL source code will tend to live longer, grow larger, and be adapted to more uses than the equivalent code released under the terms of the GPL. If time proves me wrong, it means that the "viral" nature that GPL possesses is a superior evolutionary trait. Given what I know about the cross-fertilization advantages of sexual reproduction over asexual reproduction, I'm betting on MPL and any other and future licenses in the subset of Open Source licenses that are not merely prolific, but Promiscuous as well.
- allows for the combination of MPL code with other code in a larger work without requiring that all code in the entire work be distributed under the same license;
- in turn allows for innovation in Open Source licensing evolution, in that, if an Open Source license that is more free and open than MPL comes along, the Open Source movement can adopt it without having to abandon a potentially large body of MPL work, as would be required with the GPL; and
- gives developers employed by commercial organizations the opportunity to contribute to the Open Source movement and the body of public knowledge since the MPL only requires that just the derivative works be released as MPL, not the entire larger work which the employing commercial entity may have a proprietary interest.
Let the experiment begin.
Like in previous case technically, the GPL was not upheld - Wallace's complaint was dismissed on technical grounds without discussing its merits.
Daniel Wallace's second anti-GPL suit accusing IBM, Red Hat and Novell of predatory price-fixing and restraint of trade has gone down in flames like his first against the Free Software Foundation, which wrote the license.
The second decision came from a different judge in the Southern District of Indiana and, like the first judge and the FSF complaint, he found that Wallace didn't properly state a claim. He said he accepted the allegations as true but that Wallace didn't allege anticompetitive effects in an identifiable market by arguing that it stopped him from marketing his own OS and dismissed the case with prejudice figuring Wallace couldn't remedy the deficiencies.
The judge wrote that "Antitrust laws are for 'the protection of competition, not competitors.' In this case, the GPL benefits consumers by allowing for the distribution of software at no cost, other than the cost of the media on which the software is distributed. 'When the plaintiff is a poor champion of consumers, a court must be especially careful not to grant relief that may undercut the proper function of antitrust.'Because he has not identified an anticompetitive effect, Wallace has failed to allege a cognizable antitrust injury."
(This story appeared originally in Client Server News.)
It looks like SCO hired this prominent Unix expert in May of 2005. See also the original IBM's expert's opinion, the Randall Davis Declaration [PDF], to which he replies. Randal states that SCO had not provided sufficient details for its claims. Parts of Mark Rochkind's claims like "Contrary to disclosures of source code, disclosures of methods and concepts neither require an accompanying disclosure of source code" as well as assumption the Unix conc4pts originated in Unix and not were borrowed from BSD or Multics or Corbato's M.I.T. Compatible Time-Sharing System (CTSS), or some other, and have been copied into Unix are suspect. IMHO Randal Davis testimony is weaker this is real "expert for hire opinion".
| ***************************
Brent O. Hatch (5715) IN THE UNITED STATES DISTRICT COURT
1. I have devoted my professional career to computer science, a field in which over the past 39 years, I have developed software, written textbooks, and taught. My speciality is in the area of UNIX operating systems. 2. I received a Bachelor's Degree in Mechanical Engineering from the University of Maryland in 1970, a Masters of Science in Mechanical Engineering from Rutgers in 1972, and a Masters of Science in Computer Science from Rutgers in 1976. I have taught computer science courses at the University of Colorado. Exhibit A contains details of my professional background and publications. 3. I consider myself to have expertise in computer science generally, and specifically on application and system programming, programming languages, software development processes, software design, database systems, graphical user interfaces, and internet applications. 4. I have personal experience in the development of the UNIX operating system. From 1970 to 1982, I worked on UNIX development at AT&T Bell Laboratories. My work involved design and development of the UNIX operating system and of applications running on the UNIX operating system. 5. I wrote Advanced UNIX Programming, published in 1985, which was the first textbook to explain in detail how to use UNIX system calls to write applications. I updated Advanced UNIX Programming in 2004 to include newer features of UNIX and to include material on Linux and FreeBSD. These books are considered standard references on UNIX operating systems. 6. I was retained by counsel to SCO in May 2005, to analyze the technical evidence in this case, to help prepare the preliminary October and December 2005 Disclosure of Material 2 Misused by IBM (the "December Submission") and to serve as a consultant and expert witness. I have since been asked to review the declaration recently submitted by Professor Randall Davis, and this declaration is submitted as a result of that review. 7. I strongly disagree with Professor Davis's assertion (at paragraph 11) that SCO has failed to identify with specificity 198 challenged items in the December Submission. SCO's Submission identifies the technology in issue with specificity, both with respect to disclosures of code and with respect to disclosures of methods and concepts. It provides ample identification to define each technology in question and from which IBM can formulate a defense, if such defense is available. 8. Of the 294 Items in the December Submission, about a third are cases of misused code, and about two-thirds are cases of misused methods and concepts. With respect to disclosures of code, the December Submission provides specific identification of the code that was wrongfully disclosed by IBM, including in many cases providing charts showing precisely where the code had been disclosed. These disclosures of code are, with a few exceptions, not the subject of IBM's motion or Professor Davis's declaration.1 9. The remaining two-thirds of the material identified in the December Submission are methods and concepts. These are specifically identified in the December Submission not only by
1 IBM notes that SCO "appears not to have even used [CMVC] to prepare its Final Disclosures." That is incorrect. I used CMVC extensively. REDACTED 3 summarizing the method or concept implicated, but also, in almost all cases, by identifying the actual written communication that constitutes the disclosure. In other words, the method and concept is fully described in the December Submission and the related materials, which are referenced as sources for each of the enumerated items. In most cases the December Submission also identifies the IBM individuals involved in making the disclosure. 10. Contrary to disclosures of source code, disclosures of methods and concepts neither require an accompanying disclosure of source code, nor is the method and concept defined or identified by source code. Many textbooks on computer programming discuss methods and concepts without providing accompanying source code for actual systems. I strongly disagree with the premise of Professor Davis that version, file, and line of source code must be provided to identify a method and concept, and to prepare a defense to an allegation of misuse. Where IBM disclosed methods and concepts from the Dynix and Dynix/ptx operating systems without providing source code in the disclosures, for example, it is often not possible and certainly not necessary to cite to specific source code in identifying the disclosure. The reason is simple: the material that was improperly disclosed to Linux was the method or concept itself, not particular lines of source code from Dynix/ptx. 11. Moreover, for many of the challenged items in the December Submission, there is code imbedded in the disclosure email or other document, or found at a referenced URL (internet website) address. In addition, some of the methods and concepts relate to other disclosures that do implicate code. REDACTED 4 12. I have prepared and attach as Exhibit B a summary chart of the 198 challenged disclosures. This chart first shows where the actual disclosure, such as an email from an IBM engineer to a Linux programmer discussing the protected material, has been provided. (See column A.) In these cases, to use Professor Davis's analogy, the proverbial needle itself is identified, verbatim, in the December Submission. The chart also identifies those disclosures as to which there is accompanying source code for the item contained in either the text of the disclosure, a document or URL address referenced in the disclosure, or in related code that is the subject of a separate disclosed item. (See column B.) In those cases, the origin of the method and concept in protected material (often Dynix/ptx) is supported by such source code. In yet other cases, the disclosure does not reference specific code, but contains in the face of the communication an admission or other statement that directly links the method and concept as coming from protected material such as System V, or a derivative such as AIX or Dynix/ptx. (See column C.) Finally, the chart indicates in Column D those disclosures for which file locations in Linux are provided relating to the challenged method and concept.2 13. Even the one example cited by Professor Davis in his Declaration, Item 146, does not support his point that it "provides no meaningful information about what IBM is alleged to have done wrong." REDACTED 2 IBM criticizes the lack of versions in these references. However, the files referenced can be found, in most cases, in any version of Linux issued after the disclosure. 5 REDACTED6 16. IBM alleges in its reply brief that "it is beyond reasonable debate that SCO acted willfully in not specifying its claims" (at 10) and that "SCO has declined, as a practical matter, to tell IBM what is in dispute" (at 9). 17. I am familiar with the technical evidence. I played the largest, although not an exclusive, role in assembling it, so I am in the best position to know that IBM's allegation is false. For each of the 294 Items, I did everything I could to ensure that everything we had was disclosed and that it was organized in the most accessible possible manner. Counsel to SCO made it very clear that that was what they wanted me to do. I made sure that every Tab containing a publicly available email included the complete URL and I also made sure that not only would versions, lines, and files be cited where available, as they were in the October Interim Submission, but that the code itself would be shown and that the misused lines would be highlighted and indicated with red lines drawn between the columns. As I explain above, code copying is properly described one way (version, file, and line), and a different approach is used for methods and concepts. 18. I note that there were some candidate Items that, in my opinion, did not meet my professional standards for completeness, clarity, and specificity. I told SCO's counsel that these should be rejected, and in all cases they took my advice. 19. In short, the 198 Items challenged in IBM's reply brief are as complete as possible, and constitute a specific identification of the misappropriated technology at issue. 20. I will timely submit my expert report, which will offer fully explored opinions about IBM's disclosures formed during the work I have done over the last year. 7 21. I declare under the penalty of perjury that the foregoing is true and correct.
8 CERTIFICATE OF SERVICE Plaintiff, The SCO Group, Inc., hereby certifies that a true and correct copy of the foregoing Declaration of Marc Rochkind was served by mail on Defendant International Business Machines Corporation on the 10th day of April, 2006, by U.S. Mail to: David Marriott, Esq.
(signature) 9 EXHIBIT A Marc Rochkind Marc Rochkind received a BS in Mechanical Engineering from the University of Maryland in 1970, an MS in Mechanical Engineering from Rutgers in 1972, and an MS in Computer Science from Rutgers in 1976. >From 1970 to 1982 he worked at AT&T Bell Laboratories as a Member of Technical Staff and Technical Supervisor. Starting in 1972 he began working on development of the UNIX system. He contributed to the architecture and implementation of the Programmer's Workbench version of UNIX (PWB), several UNIX commands, a table-driven data-validation system that served as a model for the "awk" programming language, and the Source Code Control System (SCCS). His paper on SCCS, delivered at the first IEEE Software Engineering conference, won an award from IEEE a decade later as the most significant from the first conference. SCCS has formed a basis for RCS, CVS, SourceSafe, PVCS, and other version control systems. In 1982 Mr. Rochkind started one of the early software companies to take advantage of the emergence of the IBM PC as the dominant personal computer. In 1988 he invented XVT, the first developer tool to allow programmers to write portable, but native, graphical user interfaces for Windows, Macintosh OS, OS/2, X/Motif, OpenLook, and character displays. Methods and concepts from XVT have influenced contemporary user-interface systems such as Java AWT and KDE Qt. Mr. Rochkind's publications include a 1985 textbook, Advanced UNIX Programming (Prentice-Hall), which explained how to program UNIX applications at the system-call level. In 1998 he authored Advanced C Programming for Displays, also published by Prentice-Hall. He rewrote Advanced UNIX Programming in 2004 to bring it up to date and to specifically cover Linux and FreeBSD. In the 2004 Linux Journal 2004 Readers' Choice Awards, Advanced UNIX Programming won third place for "Most Indispensable Linux Book." Mr. Rochkind has delivered numerous technical papers on UNIX, software development, and graphical user interfaces, and has taught professional seminars on UNIX and computer science at the University of Colorado. In addition to his work as a consultant and author, Mr. Rochkind continues to develop computer software. He has designed and implemented applications for UNIX, Windows, Macintosh OS X, and Linux servers, including a high-capacity web-based grading and report-card application for a large school district, applications for digital photography, and database utilities. 10 Marc Rochkind's UNIX-Related Publications Rochkind, M.J., "The Source Code Control System," IEEE Transactions
on Software Engineering, Vol. SE-1, Number 4, pp. 364-370, Dec.,
1975. 11 EXHIBIT B
12
13
14
15
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
I thought you'd be interested in knowing that the Wallace v. FSF case has been dismissed, with Mr. Wallace ordered to pay the Free Software Foundation's costs. Mr. Wallace's application to file a fourth Amended Complaint was denied and the Free Software Foundation's Motion to Dismiss was granted. ... The judge himself explains the standard of review:
When ruling on a motion to dismiss under Federal Rule of Civil Procedure 12(b)(6), the court must accept as true the factual allegations contained in the complaint, as well as the inferences reasonably drawn therefrom. A dismissal is appropriate only if the plaintiff can establish no set of facts, even if hypothesized, consistent with the allegations of the complaint that would entitle him or her to relief.... Moreover, the court must examine only the complaint, and not the merits of the lawsuit.
ENTRY GRANTING REASSERTED MOTION TO DISMISS (Docket No. 34)1 ___________________
On November 30, 2005, Plaintiff Daniel Wallace filed pro se his Fourth Amended Complaint, in which he seeks injunctive relief to remedy alleged violations of Section 1 of the Sherman Act, 15 U.S.C. § 1. Two days earlier, in its Entry Granting Motion to Dismiss the Complaint (“Entry”), the court had dismissed the previous iteration of Mr. Wallace’s complaint, and granted him leave to amend the complaint to cure its deficiencies. The Fourth Amended Complaint purportedly cures those deficiencies, and again seeks to enjoin “the restraint of trade by way of a licensing scheme to fix the prices of computer software products” allegedly perpetuated by Defendant Free Software Foundation, Inc. (“FSF”). (Fourth Am. Compl. 1.)
On December 29, 2005, FSF moved to dismiss the Fourth Amended Complaint, arguing that it fails to state a claim upon which relief can be granted under Federal Rule
of Civil Procedure 12(b)(6). Mr. Wallace responded to the motion on January 3, 2006, with a reply brief being filed on January 24, 2006. The motion to dismiss therefore is fully briefed and ripe for determination.
I. PLAINTIFF’S FOURTH AMENDED COMPLAINT
The allegations raised for the first time in the Fourth Amended Complaint are set forth below. Rather than repeat its previous summation of the remaining allegations, the court instead refers the parties to its November 28, 2005 Entry.
Mr. Wallace now contends that FSF has conspired with International Business Machines Corporation, Red Hat Inc., Novell Inc. and other individuals to “pool and cross license their copyrighted intellectual property in a predatory price fixing scheme.” (Fourth Am. Compl. 2-3.) He contends that the scheme is carried out through a “predatory price fixing agreement . . . to pool and cross license . . . intellectual property with others” (id. 3) known as the GNU General Public License (“GPL”).
Mr. Wallace adds a section in the Fourth Amended Complaint entitled “INJURY,” in which he states that the predatory price fixing scheme is “foreclosing competition in the market for computer operating systems.” (Id.) Specifically, it “prevents Plaintiff Daniel Wallace from marketing his own computer operating system as a competitor.” (Id.)
2
II. MOTION TO DISMISSIn its Reasserted Motion to Dismiss, FSF requests that the court dismiss the Fourth Amended Complaint for failure to state a claim upon which relief can be granted under Federal Rule of Civil Procedure 12(b)(6). FSF contends that the complaint fails to address the deficiencies identified by the court in its November 28, 2005 Entry, including that the “injury allegedly suffered by Plaintiff is not one that the antitrust laws were meant to address.” (Mot. Dismiss 5.) Furthermore, FSF argues that Mr. Wallace lacks standing to bring the Fourth Amended Complaint because he does not allege “any facts to show that in fact he is prepared to enter the market for providing computer operating systems.” (Id. (citations omitted).) FSF requests not only that the court dismiss the Fourth Amended Complaint, but also that it deny Mr. Wallace leave to further amend the complaint.
Mr. Wallace responds that his Fourth Amended Complaint adequately sets forth the three material elements of his claim under § 1 the Sherman Act. He states that he has alleged 1) that the GPL constitutes a “contract, combination or conspiracy” (Resp. 2); 2) that the GPL creates an unreasonable restraint of trade (id. 6); and 3) that the GPL has caused him injury (id.10). As a result, Mr. Wallace contends that he has “directly or inferentially alleged that the defendant has used an express contractual agreement to conspire with named co-conspirators and engage in an unreasonable restraint of trade by fixing prices at predatory levels.” (Id. 13-14.)
3
A. Standard of ReviewWhen ruling on a motion to dismiss under Federal Rule of Civil Procedure 12(b)(6), the court must accept as true the factual allegations contained in the complaint, as well as the inferences reasonably drawn therefrom. Forseth v. Vill. of Sussex, 199 F.3d 363, 368 (7th Cir. 2000); Baxter by Baxter v. Vigo County Sch. Corp., 26 F.3d 728, 730 (7th Cir. 1994). A dismissal is appropriate only if the plaintiff can establish no set of facts, even if hypothesized, consistent with the allegations of the complaint that would entitle him or her to relief. See Sanjuan v. Am. Bd. of Psychiatry & Neurology, Inc., 40 F.3d 247, 251 (7th Cir. 1994). Moreover, the court must examine only the complaint, and not the merits of the lawsuit. See Autry v. Nw. Premium Servs., Inc., 144 F.3d 1037, 1039 (7th Cir. 1998).
B. The Plaintiff Again Has Not Alleged An Antitrust Injury.
In its November 28, 2005 Entry, the court pointed to a fatal flaw in Mr. Wallace’s Third Amended Complaint — he did not allege an antitrust injury upon which his claim under Section 1 of the Sherman Act could move forward. (Entry 11.) The court noted that in order to assert a Section 1 claim, a plaintiff must allege that he or she suffered “injury of the type the antitrust laws were intended to prevent and that flows from that which makes defendants’ act unlawful.” Brunswick Corp. v. Pueblo Bowl-O-Mat, Inc., 429 U.S. 477, 486 (1977). This generally means an anticompetitive effect. Id. at 489. The court found that Mr. Wallace’s purported injury, that he was “threaten[ed] from entering into the market with his own computer operating system” (Third Am. Compl. 3),
4
was not of the sort that antitrust laws were intended to prevent, and dismissed his complaint with leave to amend. (Entry 11.)Mr. Wallace has amended the complaint to add more detailed allegations relating to his injury. He now asserts that the GPL is “foreclosing competition in the market for computer operating systems.” (Fourth Am. Compl. 3.) Specifically, it “prevents Plaintiff Daniel Wallace from marketing his own computer operating system as a competitor.” (Id.) Mr. Wallace argues that this amendment saves his complaint from dismissal. The court disagrees. The injury set forth in the Fourth Amended Complaint, which the court acknowledges is subtly different than that alleged in the previous complaint, still suffers from the same infirmity identified in the court’s November 28, 2005 Entry — it does not state an injury cognizable under antitrust laws.
First, while Mr. Wallace contends that the GPL is “foreclosing competition in the market for computer operating systems” (id.), his problem appears to be that GPL generates too much competition, free of charge. The court’s understanding from the GPL itself2 is that it is a software licensing agreement through which the GNU/Linux operating system may be licensed and distributed to individual users so long as those users “cause any work that [they] distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.” (GPL 3.) The GPL
5
purportedly functions to “guarantee [users’] freedom to share and change free software.” (GPL Preamble.) As alleged, the GPL in no way forecloses other operating systems from entering the market. Instead, it merely acts as a means by which certain software may be copied, modified and redistributed without violating the software’s copyright protection. As such, the GPL encourages, rather than discourages, free competition and the distribution of computer operating systems, the benefits of which directly pass to consumers. These benefits include lower prices, better access and more innovation. See Jason B. Wacha, Taking the Case: Is the GPL Enforceable, 21 Santa Clara Computer & High Tech L.J. 451, 487 (2005). And the Sherman Act “was enacted to assure customers the benefits of price competition, and . . . prior cases have emphasized the controlling interest in protecting the economic freedom of participants in the relevant market.” Assoc.’d Gen. Contractors v. Cal. State Council of Carpenters, 459 U.S. 519, 528 (1983). Therefore, the court finds that the Fourth Amended Complaint does not adequately set forth an injury to competition as a whole.The allegation in the Fourth Amended Complaint that the GPL is foreclosing Mr. Wallace from entering into the market for operating systems also is not a cognizable antitrust injury. The court understands Mr. Wallace’s argument that the GPL may be preventing him from marketing his own operating system, and, for the purposes of the instant motion, accepts that allegation as true. However, while this may be significant enough from Mr. Wallace’s perspective, a plaintiff must prove not only an injury to him or herself, but to the market as well, Martin v. Am. Kennel Club, Inc., 697 F. Supp. 997, 1003 (N.D. Ill. 1988), which Mr. Wallace has failed to do. As the court stated in its
6
November 28, 2005 Entry, reduced opportunity as a competitor does not necessarily equate to an antitrust injury as recognized by the courts. Brunswick, 429 U.S. at 488. Indeed, injury in fact is “a different beast” than antitrust injury. Prof’l Sports Ltd. P’ship v. Nat’l Basketball Assoc., 961 F.2d 667, 669 (7th Cir. 1992). And “whenever the plaintiff and consumers have divergent rather than congruent interests, there is a potential problem in finding ‘antitrust injury’. . . . When the plaintiff is a poor champion of consumers, a court must be especially careful not to grant relief that may undercut the proper functions of antitrust.” Ball Mem’l Hosp., Inc. v. Mutual Hosp. Ins., Inc., 784 F.2d 1325, 1334 (7th Cir. 1986).Mr. Wallace has not alleged that anyone interfered with his freedom to compete in computer software market by creating his own operating system, one perhaps with features different from, or in addition to, that of the GNU/Linux operating system. Indeed, Mr. Wallace has that ability, regardless of whether the GPL is in force or not.
For these reasons, the court finds that Mr. Wallace’s Fourth Amended Complaint does not adequately allege an antitrust injury upon which his Section 1 claim may move forward. 3 The complaint therefore must be dismissed.
7
C. The Plaintiff is Denied Leave to Further Amend the Complaint.FSF requests that the court deny Mr. Wallace leave to further amend his complaint, arguing that any fifth or subsequent amendment would be futile, particularly given Mr. Wallace’s failure to state a claim thus far. Even though Federal Rule of Civil Procedure 15(a) provides that “leave shall be freely given when justice so requires,” a court may deny leave to amend for undue delay, bad faith, dilatory motive, prejudice, or futility. See Foman v. Davis, 371 U.S. 178, 182 (1962); Arazie v. Mullane, 2 F.3d 1456, 1464 (7th Cir. 1993). The opportunity to amend a complaint is futile if “the complaint, as amended, would fail to state a claim upon which relief could be granted.” Glassman v. Computervision Corp., 90 F.3d 617, 623 (1st Cir. 1996)). This standard is the same standard of legal sufficiency that applies under Rule 12(b)(6). Id at 623.
In this case, Mr. Wallace has had five opportunities to state a claim under Rule 12(b)(6). And the court twice has determined that he failed to do so. The court’s November 28, 2005 Entry even specifically highlighted Mr. Wallace’s failure to allege an antitrust injury, but Mr. Wallace’s subsequent complaint did not adequately address that failure. In such a situation, where Mr. Wallace has failed to remedy a deficiency expressly noted by the court, he should not, and will not, be granted leave to further amend his complaint. See Shanahan v. Chicago, 82 F.3d 776, 781 (7th Cir. 1996) (a district court need not permit a plaintiff to amend a complaint if the amended complaint suffers from the same defects as the original complaint).
8
III. CONCLUSIONFor the reasons stated above, the court finds that Mr. Wallace has failed to allege an antitrust injury such that his claim under Section 1 of the Sherman Act may move forward. The court therefore GRANTS the Reasserted Motion to Dismiss (Docket No. 34), filed December 29, 2005. Mr. Wallace is DENIED leave to further amend his complaint.
An appropriate judgment will be entered.
ALL OF WHICH IS ENTERED this 20th day of March 2006.
___[signature]____
John Daniel Tinder, Judge
United States District CourtElectronic copies to:
Curtis W. McCauley
Ice Miller
[email]Philip A. Whistler
Ice Miller
[email]Copy mailed to:
Daniel Wallace
[address]
1 This Entry is a matter of public record and will be made available on the court’s web site. However, the discussion contained herein is not sufficiently novel to justify commercial publication.
Authored by: Anonymous on Tuesday, March 21 2006 @ 04:20 AM EST
The judge in this ruling cites "Jason B. Wacha, Taking the Case: Is the GPL Enforceable, 21 Santa Clara Computer & High Tech L.J. 451, 487 (2005)." Expanding that, that's the Santa Clara Computer and High Tech Law Journal, volume 21 (published in 2005), starting at page 451. It looks like copies are available from my university library connection; it may be possible to find a copy at a large public library as well. Anyhow, since I've got access to a copy, I'll write out some stream-of-consciousness notes as I read through it....
Briefly, Mr. Wacha is the General Counsel for MontaVista Software, which does embedded Linux stuff. He starts out by noting that much of the legal analysis of the GPL that's available starts out with the acronym "IANAL", and ranges from "completely off the mark to well-informed solid arguments." I find that sort of amusing, given how frequently the acronym shows up here!
He also notes a court case, MontaVista vs. Lineo, in which a part of the question was whether Lineo had violated the terms of the GPL. (Apparently both parties agreed that the GPL was valid, so that was not in question; Mr. Wacha says that this is typical for court cases involving the GPL. I wonder what that does to the "The GPL has not been tested in court" claims!) Much reference is made to the SCO case, and the relatively novel claim of SCO that the GPL is unenforcable.
Mr. Wacha claims that, because the GPL imposes obligations on the licensee, which they accept by distributing or modifying the licensed software, it is effectively a contract, and should be treated as such. (He also notes that a "conditional license" -- that is, one which can be revoked based on certain conditions -- is in general effectively a contract.)
The bulk of the article is a set of 11 challenges to the GPL, and discussions of these challenges with rebuttals. The one ranked most ludicrous is "The GPL violates the U.S. Constitution," which Mr. Wacha dismisses with a flat "No, it does not," before going on to explain in detail, including some explanations of flaws in SCO's pleadings.
Again with the "The GPL has never been tested in court," Mr. Wacha cites Computer Associates v. Quest Software as an indirect test in U.S. courts, which concluded that (to quote Mr. Wacha's summary), "use of software subject to the GPL in the development of ... software programs did not render the resulting software subject to the GPL." (I presume this is rejecting the "If you compile your code with GCC, you must release it under the GPL" FUD, or something close to it.)
Back to the "Is the GPL a valid contract?" question, he notes that there is legal precedent for the idea that contracts can be accepted by one's actions, and that exchange of "something of value" does not only mean money, and can almost certainly include the licensee's promise to abide by the terms of the GPL. (In addition, the distinction between license and contract is apparently something of some peculiarity to U.S. law; German law, for instance, does not have such a distinction, and the GPL was considered to be a contract in Welte v. Sitecom.)
One of the two challenges that Mr. Wacha finds potentially meaningful is the challenge that the GPL does not adequately define "derived work". This he dismisses, though admitting that the GPL is vague on this point, with a claim that it is not so vague that a court would invalidate it on those grounds -- and, in particular, that it can probably be clarified by reference to the specific facts of any given case that might be brought. (I presume there might be a basis for some argument at the edges, such as where SCO is making its "methods and concepts" argument.)
The other most-meaningful challenge, in Mr. Wacha's estimation, is the claim that the GPL does not meet the requirements for a valid click-through or shrink-wrap "license" contract. One particular question is whether it can be assured that the licensee has recieved and accepted a copy of the GPL prior to accepting it by copying or distributing the software in question. He concludes that, in some cases, this could be a valid argument -- but that, in many cases, a court is likely to be able to determine that the licensee was aware that the GPL covered the software in question. This is probably something worth paying attention to, though!
Overall, this seems like a quite well-written article, and something that I think PJ would find rewarding to follow up on -- both on the article itself, and the court cases I mentioned. (I also would note that, unlike most scientific journals, the authors in law reviews retain copyright to their articles; perhaps Mr. Wacha would consent to having his article republished here?)
- Brooks
Silly me, thinking that Mr. Wacha might be amenable to republication of his article, and then not actually checking to see if he'd already done that somewhere! He has, indeed, already done so, and a copy of the article is here: http://www.open-bar.o rg/docs/GPL-enforceability.pdf.
That's provided by the Open-Bar Organization, which I'd never heard of before, but looks like it has a good bit of stuff on law related to open-source software that's worth looking at.
- Brooks
If not, here's the courthouse, for those with Pacer accounts. I notice on the docket sheet the magistrate judge offers to handle the thing: Here's Wallace's most recent amended complaint [PDF] against the Free Software Foundation, which had the gall to come up with a license a lot of people like to use for their software, which they[Feb 10, 2006] Richard Stallman casts aspersions using Mace of Dissing
'An impractical, "my way or the highway" approach to the problems of intellectual property is becoming dangerously common' GPL approach that can aptly called "My way or highway" so typical of RMS views: "copyright is dead, screw the big corporations, long live piracy because it's my right,".
Richard M. Stallman, known succinctly as RMS in many technology circles, is one of those EF Hutton types; when he talks, people listen. Of course, as the founder of the GNU project and the Free Software Foundation, this is to be expected, but his magnetic pull is also enhanced by a punchy attitude that usually takes the form of a rain cloud forming over a parade. Sometimes this can be good; there can be little doubting his importance in the early years of the open source "boom (if you will), even if the entire Linux versus GNU versus GNU/Linux debacle seemed a little pointless. Sometimes, however, taking on the air of a grand provocateur hurts more than it helps.Stallman recently decided to do an e-mail interview with LinuxP2P.com, touching on P2P, DRM, the GPL, Creative Commons, and a handful of other topics primarily relating to the world of intellectual property. The interview touches on a number of topics that I won't repeat here, but I do want to just briefly comment on one trend that I see solidifying in discussions of intellectual property law that is coincidentally represented by Stallman's comments.
Knowing Stallman's rather extremist views on the property classified often as intellectual in nature, I wasn't surprised to see him respond to a question about the merits of DRM with a quick and dismissive "it is fundamentally unjust." He followed with an auto-hagiographical account of his refusal to purchase DRMed CDs and DVDs. Just in case you were worried, he has never bought a DVD with CSS encryption. Awww, yeah. The appropriate emoticon is: \m/ (>.<) \m/
All spirited ribbing aside, Stallman does have some interesting things to say about Creative Commons, the open license for content that bloggers love to talk about, but don't love to adopt. Creative Commons is a powerful idea, and an interesting non-profit organization. It's also rejected by Stallman, though the reasons may surprise you.
Stallman told LinuxP2P.com that "people have a tendency to disregard the differences between the various Creative Commons licenses, lumping them together as a single thing." He adds, "some Creative Commons licenses are free licenses; most permit at least noncommercial verbatim copying. But some, such as the Sampling Licenses and Developing Countries Licenses, don't even permit that, which makes them unacceptable to use for any kind of work. All these licenses have in common is a label, but people regularly mistake that common label for something substantial."
Stallman here is getting at one of the best features of Creative Commons: choice. If you publish the written word, for instance, you can use Creative Commons to devise a license that fits your needs. Do you allow commercial reuse or not? What about modifications, sharing, or performance? Creative Commons is an attempt to put tools in the hands of creators so that they can feel legally safe and competent to specify how they would like their works to be treated. Stallman is correct: there is no single license, and if someone says that they have their writings available under Creative Commons, it's not entirely clear what that means. For Stallman, however, this is a bad thing.
Stallman continues, "I no longer endorse Creative Commons. I cannot endorse Creative Commons as a whole, because some of its licenses are unacceptable. It would be self-delusion to try to endorse just some of the Creative Commons licenses, because people lump them together; they will misconstrue any endorsement of some as a blanket endorsement of all. I therefore find myself constrained to reject Creative Commons entirely."
Stallman's comments admittedly surprise me. Is pedestrian confusion coupled with flexible licensing options really grounds for rejecting something like Creative Commons?
In a word, no. As a historian, I look at the balkanized state of Creative Commons licensing and cannot help but see something rather exciting: everyday people have different expectations of how their work should be valued, protected, and distributed. This manifests itself in different licensing decisions made by content producers, which on the 'net includes anyone who wants to create. In the past, you could slap the old © on your work and that was about it. Creative Commons, on the other hand, starts with the general protections afforded by copyright, and then allows users to build licenses that are less restrictive. A Creative Commons license can't be more restrictive than standard copyright affords, but it can certainly be less restrictive. And this is something to reject? Of course not.
While it may be fashionable to bash the pro-DRM lobby as economically fascist (you vill like zee HDCP!), is it any better to assert that opinions over the quality and nature of licenses are ethically absolute matters? As I mentioned above, there is a solidifying approach to copyright and intellectual property issues that is merely dismissive. "I don't buy those things, so it doesn't matter." "I reject such a scheme, for it is unjust!" "The flying spaghetti monster says it must be so!" They're also all, I would submit, myopic and dangerous.
Without a doubt, Stallman's views are extreme (generally speaking), but hardly unique. My concern with this brand of engagement, though, is that it is ultimately polarizing, and runs close to being another "baby with bathwater" approach to the problem. In our own discussions here on Ars, debates on intellectual property often end up between the two poles of "copyright is dead, screw the big corporations, long live piracy because it's my right," and "why don't you try working for free and see how you like it, loser." Sure, that's a caricature, but if you have ventured into our discussions, you've probably seen the evidence of this polarization. It's nothing shameful; indeed, looking at the state of the country as a whole, it's de rigueur. But that's what has me concerned. If you've been paying attention, then you know that getting caught up in the extremes means that you miss most of what constitutes reality.
Most of our representatives in government are already poised to take the views of Big Content more seriously than those of the citizenry. An impractical, "my way or the highway" approach to the problems of intellectual property is becoming dangerously common, partially on account of our representatives' relative lack of action, and partially on account of the rhetorical successes of the content industry. As so-called consumers, we all risk running into the trap unwittingly when we're too eager to attack progress for not being progressive enough.
Comparing Open Source Licenses GPL vs. BSDL
the free and open source software (F/OSS) communities, there are two common free software licenses, originating from two very different philosophies:
- The Berkeley Software Distribution License (BSDL) is a very simple license. It states that you may not claim that you wrote the software under the license, and that you must state somewhere who did write it, but apart from that you can do anything you like with the code—including distributing binary copies of it and any derived works.
- The GNU General Public License (GPL) is based on the idea of copyleft—the philosophical opposite of copyright, built using existing copyright laws. This aspect of the GPL is sometimes referred to as "viral," since any derived work of a GPL’d product is covered under the GPL, including the parts not originally licensed under the GPL. For example, it’s possible to take the Linux kernel (GPL) and add some BSDL code to it. The result, as a whole, is licensed under the GPL; however, the BSDL component on its own is also still covered by the BSDL.
The reason the GPL exists is to enforce the four freedoms of the Free Software Foundation, which I’ve outlined in a previous article. These freedoms are expressly granted by the GPL. The copyleft nature of the GPL means that any derived work of GPL software must also respect the four freedoms—in effect, it says that if you want to benefit from free software, you must play by the rules of free software.
These two licenses are not the only ones used by F/OSS. Others licenses are similar:
- The MIT license under which X11 is distributed is a slightly more lenient version of the BSD license, removing the requirement for attribution in binary-only distributions.
- The Lesser GPL (LGPL) removes some of the constraints of the GPL, and is intended for libraries that might be used in non-libre software.
- There are also a whole set with slightly differing terms, including some—such as Apple’s and Sun’s licenses—which expressly allow the inclusion of closed-source components
Linux Today - eWeek Solaris and Linux No Code Swapping
Orlando Native - Subject: Define "better" ( Feb 1, 2006, 20:11:57 ) Perhaps, at some future point, you might be right... :)
However, in the present, someone like me who has worked with BOTH might tend to differ.There are features built into Solaris that Linux does not yet have... ...or are not yet at 'enterprise level' stability levels. 'Domains' and dtrace are just 2 of them. Also, I've found that in many cases where comparable functions DO exist, configuring them within a Solaris environment is much easier and logically intuitive than their Linux counterparts.
So while there may be no TECHNICAL barrier to a claim such as yours being correct in the FUTURE, it's certainly not true NOW. And, of course, Solaris, like any other OS not controlled by Microsoft, *IS* subject to further innovation and improvement...To be perfectly honest, the licensing issue is something entirely different. Personally I can't see ANYTHING in GPLV3 that would recommend it to Sun vs. V2; but, perhaps, there's some ongoing stuff to which I'm not privy. Obviously, there were some problems with V2 that caused them not to use it; and I doubt the 'fear' of 'code stealing' (interesting that someone brought up that issue, IMHO, given the 'anti code stealing' stance that most of the GPL 'bigots' chant that their license supposedly prevents) was the major consideration. More likely there were still portions of code that they, due to previous licensing/copyright concerns, COULDN'T GPL without creating some licensing violation.
Actually, what I find MOST interesting about the whole thing is that the 'bigots' always seem to refer to code transfers from "something else" to GPL'd Linux, as 'code sharing'; while code transfers FROM GPL'd code to ANYTHING else is 'code stealing' :D
I find that truly an interesting dichotomy. And not really any different from the stance they decry in 'proprietary software' LOL
I R A Darth Aggie - Subject: Re: Define ( Feb 2, 2006, 04:36:37 ) Actually, what I find MOST interesting about the whole thing is that the 'bigots' always seem to refer to code transfers from "something else" to GPL'd Linux, as 'code sharing'; while code transfers FROM GPL'd code to ANYTHING else is 'code stealing' :D I find that truly an interesting dichotomy. And not really any different from the stance they decry in 'proprietary software' LOL
Your dichotomy is false. If the borrowers of GPL'd code live up to the requirements of the license, that's cool. Which also means that their software is also going to be licensed under the GPL. Thus the so-called viral nature of the GPL.
You're right that in this case, it is similar to proprietary software, in that you're expected to live up to the license.
Except, of course, that the average proprietary license forbids you from looking at the source, let alone reusing code assuming you could lay your hands on the source. And you're probably prohibited from reverse engineering or even writing a review without prior permission.
Oh, yes, the free software crowd is soooo much like the proprietary crowd...
[Jan 28, 2006] NewsForge POV-Ray illustrates complexity of changing licenses
The Persistence of Vision Raytracer (POV-Ray) graphics software has existed for 15 years under a license designed to keep it free and open. But with continued confusion as to what that license allows, the POV-Ray developers are looking for something new.Although the license has remained virtually the same over the life span of POV-Ray, Chris Cason, team leader on the project, said the main developers of POV-Ray are in agreement that the software needs a new license. While he said they agree that a license recognized as an open source license would be ideal -- such as the GNU General Public License (GPL) -- that is not necessarily the direction they will go in.
POV-Ray is actually distributed under two licenses, one for personal use and the other for distribution.
Cason said the POV-Ray licenses are intended to protect the work of developers on the project. He said the developers want the software to be used freely by people who share freely, including developers who share or even sell Linux distributions -- the POV-Ray developers just want credit for having created the application, he said.
"We've had a lot of people in the past try to rip us off," Cason said. "We have a problem with people taking without giving back. There are organizations out there who would like to take something like a raytracer, or photo-quality graphics [application], and whack it into their application and just sell the entire application without any acknowledgment."
The licenses they wrote to protect themselves are now working against them, however. Other developers are leery of touching software that does not fall under a license approved by the Open Source Initiative (OSI).
POV-Ray developers want an OSI-approved license that covers all of their concerns, Cason said, most notably in relation to the concept of a shared library being considered a derivative work. Cason said the Mozilla Public License (MPL) and Sun's Common Distribution and Development License (CDDL) were lacking some of the protections the POV-Ray team desires.
Why not use the GPL?
Russell Nelson, a member of the OSI Board of Directors and licensing committee, said it took many years for people to get comfortable with the meaning of the GPL -- and that the GPL did not really become accepted until Linus Torvalds adopted it for the Linux kernel.
Nelson said that while different people have different expectations about the amount of sharing in the community, sharing is the primary focus and burden. He said, however, that this has nothing to do with the restrictions of use and protection of developers' work provided for in the GPL -- and called the license more of a rallying cry than the literal gospel many of its supporters see it as.
"I think that the actual terms of the license itself aren't so important," Nelson said. "It's more important that community values are reflected by the license."
POV-Ray, however, predates the widespread usage of the GPL, the open source community as it is now known, and the values the community has adopted over time. All this despite the fact that the POV-Ray licenses are relatively similar to the GPL, Cason said, adding that the only reason the rendering software is not licensed under the GPL in the first place was the original developers' lack of knowledge of its existence.
Although the POV-Ray project started in 1991, the software's roots are in DKBTrace, an application started in 1987 by developer David Buck, according to the code history on the POV-Ray Web site. Buck passed DKBTrace onto Aaron Collins in 1988, who used it as the basis for POV-Ray.
Buck licensed the software "to be used freely by end-users, and freely distributed, as long as it was not sold, included with a commercial program, or used in certain other ways that contravened the concept of the software being freely available," according to the history.
Development for POV-Ray continued with a group of developers over the CompuServe online service provider under the POV-Ray license. The POV-Ray developers were not aware the GPL existed, and so could not contemplate whether to use it. Cason said, however, that the POV-Ray licenses and GPL have similarities.
"We've always said, 'If you change it, and keep those things inside your business [that's fine],'" Cason said. "'But if you want to distribute it, you have to release the source.' You've probably heard that before -- because it's in the GPL."
For the most part, the latest licenses allowing use and distribution of POV-Ray follow the same lines as the original POV-Ray license. Cason said that sale of the software as part of a larger product is permitted, as long as licensing information is provided with the software and that customers are alerted to the fact that POV-Ray is available for free.
The developers clarified the POV-Ray distribution license for the 3.6 release in February 2005. Cason said that the project wanted to allow free and open use of POV-Ray, but prevent developers from using code from POV-Ray and calling it their own.
"We wanted to make sure, when we put out the version 3.6 license, that it was absolutely clear that we want open source-based distributions to include POV-Ray."
The license for version 3.6 includes a specific list of Linux distributions that may distribute POV-Ray, as well as a general clause that allows distribution by operating systems with a kernel licensed under an OSI-approved license or a license that fits the Free Software Foundation's free software definition. While allowing distribution, the license rules out changes to the software itself.
Debating the meaning of a license
Although the license allows distribution, some developers and project administrators are fearful to ship the application because they claim the license is confusing -- and that it's not the GPL.
"The controversy with the existing license -- I honestly don't know," Cason said. "There been a lot of people who've really been absolutely ... foaming at the mouth [with] hatred over our license, and I really can't understand it."
Knoppix, one of the distributions specifically permitted to redistribute POV-Ray, doesn't include the raytracer. Knoppix creator Klaus Knopper said he is concerned that either he, or someone who creates a Knoppix derivative, could run into trouble with the license.
"In my understanding, in its current form, the POV-Ray license is not even remotely compatible with the Open Source Definition [from OSI]," Knopper said. "The redistribution license that is required for distributors puts too many restrictions on commercial use and redistribution of the software. This makes it impossible, at least for me, to include POV-Ray on Knoppix, because I want to keep Knoppix freely redistributable for all purposes, commercial or noncommercial."
Knopper said that of the dozen or so derivatives of Knoppix available, most use the distribution as a base and don't check the licenses for each individual application included with it -- so developers may never know if another license or other permission is needed to continue using the things included with Knoppix.
In attempting to show the difference between the POV-Ray license and "any open source license" approved by OSI, Knopper used a fictional derivative to illustrate his point: If a developer creates a Knoppix-based distribution, advertises it as a rendering-improved platform for graphic designers and sells it, with commercial support, he would be violating the POV-Ray redistribution license because the software was sold and the form of distribution is not covered in the license.
According to Cason, the distribution license allows this scenario so long as the primary intent of the distribution is not the use of POV-Ray itself, or that the purported graphic design distribution could still function as such without POV-Ray.
He added, however, that Knopper's example is permitted by the license, as is charging a fee for the distribution -- though section 4.3 of the license restricts the fee to "reasonable costs incurred by the Distributor in making the reproduction, or in the provision, of that copy." Cason said the section would not apply to the fictional derivative because it falls under section two of the license, "Open Source Distributions," which allows for this sort of distribution.
"It appears to me that Klaus has not read the license in full," Cason said. "It's not reasonable to read bits of it and take them out of context -- the license must be taken as a whole."
Knopper, Cason, and members of the OSI license-discuss mailing list have carried on the debate for some time since mid-November, following Cason's post to the list seeking assistance in figuring out a new license for POV-Ray.
Knopper said that while a downstream developer working with Knoppix might be the one violating a license by not doing the things POV-Ray requires for use and distribution, it becomes his problem because he "wasn't able to properly indicate that there are additional conditions to obey because of [the potential for] tainting third-party software."
Other voices
"I think the POV-Ray users would be well-served by an OSD-compliant license," said Chuck Swiger, a member of the license-discuss mailing list who has participated in the POV-Ray discussion. "But it is at least conceivable that a license that contains some term which is not completely OSD-compliant might work better for the POV-Ray community."
Swiger said POV-Ray could use some sort of "source available" license, rather than an open source one, to prevent commercial use of the software if that is what it seeks to do. Regardless, he said the current license "is fairly complex and a simpler license would probably address the concerns that Knoppix and others seem to have."
POV-Ray entirely relicensing to something that is already approved and supported by OSI would be ideal because it would offer conditions that are already more clear and more clearly defined, Knopper said. And, OSI-approved licenses are more well-known and accepted almost universally in the open source community.
"Speaking for me, the GPL would be my favorite choice," Knopper said. "But any other [OSI]-compatible license that does not restrict commercial use, distribution, and modification, would also suffice. But it is, of course, the POV-Ray author's decision whether or not they can change their license to be open source."
Searching for the right license
The POV-Ray team is looking into changing the license entirely for version 4.0, and possibly putting parts of POV-Ray 3.7 under the new license when it is released in the first quarter of this year. However, Cason said changing the license isn't that easy.
"It's no different than something released under the GPL -- you can't un-GPL it," Cason said. "And we can't un-POV-Ray the POV-Ray code. Short of finding every single person who's ever touched it, we can't do that."
Cason said all of the primary developers who have worked on the software, which accounts for about 90% of the code, have been contacted by POV-Ray and agree that the license needs to be changed. All it would take to stop the change, he said, is one of the people who worked on the other 10%. And while it is debatable that somebody who contributed a few lines to the application's code could stop the license change, Cason does not want POV-Ray to be the project to find out in court.
According to Nelson, several theories exist on whether a license can be changed without permission from all contributors. He pointed to two theories in particular: one is that a project is a collective work, rather than a derived one, and anybody can license the entire work as they wish; the other is that each contributed piece of a project is in itself a work, and the license used for the entire work is a union of the licenses each of the pieces has been contributed under.
The only way to prove a theory, Nelson said, is through the evidence of either existing case law or new case law. And while plenty of theories exist, there isn't much case law in this area, he said.
"Nobody ever wants to set new case law," Nelson said. "[The POV-Ray developers] are pursuing a conservative path, which is reasonable."
Trying to work around this issue, Cason said he is hopeful that a new license can be found before version 3.7 is put out because it includes newly written code that can be put under the new license. And with some of the POV-Ray code coming up on 20 years old, he said the application needs to be cleaned up in parts and rewritten in others, which could later be put under the new license as well.
Cason said the "entire guts of the program, the way the code fits together," has had to be changed and rewritten to work with multiple processors. The infrastructure that these new "guts" will form is to be the core of version 4.0. With a new license in place for 3.7, 4.0 could be put under the same new license when it is released -- though he doesn't know if that will actually happen.
"I'm not optimistic that we will get one done in time [for the release of version 3.7]," Cason said. "It's possible. [But] I don't think we've found one that completely suits us at this stage."
In the end, Cason said he knows that it may not make a difference how open their license choice turns out, because for some the debate is about what it says at the top of the document, and not what that document actually means. And this is the reason that he and other POV-Ray developers are looking into an OSI-approved license, or combination of more than one, for the next versions of the software.
"It's clear that it doesn't matter what the license actually says," Cason said. "Because it's not the GPL, it's bad. [POV-Ray] is not an evil license, but we get these people saying it is."
My very first try at blogging, and I made a blatant mistake. In talking about the Free Software Foundation’s move from Version 2 to Version 3 of the GPL, I pointed out that Section 9 of Version 2 provided for automatic updating of the license. I said “This means that Linus Torvalds doesn’t have to decide to release Linux under V3, The GPL is a license, not a contract. anyone who has a copy of source code under V2 can release that code under V3!”
This is true of most GPL’d software out there and many components of Linux. However, a few projects have elected to be “Version 2” only and Linux is among them (For discussion see: http://www.uwsg.iu.edu/hypermail/linux/kernel/0009.1/0096.html, http://www.ussg.iu.edu/hypermail/linux/kernel/0208.1/1287.html and http://people.redhat.com/arjanv/COPYING.modules)
The joy of the interactive – within a few hours I had an email pointing out, strongly, that I was wrong. I hadn’t written that line out of complete ignorance. I knew there was some feeling that Linus Torvalds might not move the Linux kernel to V3. As a lawyer, I checked the license that accompanied the kernel and relied on that document alone. Unfortunately, the license I checked (http://www.kernel.org/pub/linux/kernel/COPYING) turns out to be missing some key text present in other Linux distributions (see http://glide.stanford.edu/lxr/source/COPYING?v=linux-2.6.10 for a ‘correct’ version).
However, now that I have focused on the issue, I think there are some legal complexities. Perhaps interesting only to lawyers, but instructive nonetheless.
Let’s start with the facts:
- Section 2b of the GPL provides:
“2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: …
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
- Section 6 of the GPL provides:
"6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. …"
- Section 9 of the GPL provides:
“9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
- Linus’ version of the kernel has a slightly modified GPL which accompanies it. Specifically, the header provides in part:
Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.
In my mind, the legal analysis would run something like this:
First, according to the FSF, the GPL is a license, not a contract. It is merely the sole set of permissions under which you are permitted to use, modify, or distribute GPL’d code. By redistributing GPL'd code, you accept the terms of the license. Otherwise, you have no right to redistribute the code, and are subject to suit for copyright infringement.
Pursuant to Section 2b of GPL v2, the GPL licenses you to redistribute GPL’d code (and derivative works of it) only "under the terms of this License" So, according to Section 2b alone, the only terms you can use for your derivative work are GPL v2.
However, Section 9 provides an additional freedom. It states that "If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation [when you redistribute code]." Nowhere, however, does the GPL give you a right to pick a single version. Instead, in the previous sentence in Section 9, you are given the implied right to limit distribution to "a version number of this License which applies to it and 'any later version'".
Section 6 provides " You may not impose any further restrictions on the recipients' exercise of the rights granted herein." So presumably, if you wish to redistribute code you received under v2, you cannot limit the recipients right to use any FSF license they wish, except that you may limit them to using v2 and "any later version."
None of this permits Linus' language which limits redistribution of the kernel to only v2!
Now, of course, the original author of code can pick any license he or she wishes. Presumably you can use parts of the GPL or you can use the GPL plus additional terms if you wish. (Although the GPL does provide "Copyright (C) 1989, 1991 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed" which means that distributing modified versions of the GPL without permission is, itself, infringement…)
So I’ll read Linus’ header exclusion to mean that for all kernel code of which he is the copyright owner, Section 9 does not apply and, in order to comply with Section 2, any and all derivative works of his kernel code need to be released under GPL v2 only. I don’t know if he got express permission from the FSF to change the GPL in this way, but let’s assume time, acquiescence, and practicality stop any claim there.
However, Linus' language does included the exception“unless explicitly otherwise stated.” Indeed, in rolling out this change to the license, Linus invited “If anybody wants to explicitly state that their code will be valid under any version of the GPL (current or future - whatever they may look like), please send patches to say so for the code in question. ” And, although I haven’t done the search myself, according to debian-legal there are a number of packages in Linux licensed under v2 “or later.” Also, there is the question of whether Linus went back in 2000 to all of the copyright owners who had contributed under v2 prior to 2000 to redistribute the code under the modified license? I know the kernel maintainers are way out in front in controlling copyright issues in the kernel, but that seems to be a fairly daunting task.
Where does that leave us, legally? Well, for Linus’ code, and anything derivative of it, you have to distribute pursuant to version 2 of the GPL alone (“unless explicitly otherwise stated.”) However, for those packages in Linux submitted under classic GPL v2 and their derivatives? You can use any version of the GPL set forth by the FSF – which doesn’t include Linus’ version. The fact that, most likely, Linus’ code is derivative of the base GPL code and vice versa - making the contrary licenses apply to one another? That just makes my head spin.
From a practical standpoint, none of this matters. Linus is the most recognized opinion leader on the GPL’s mainstay product. His opinions will reverberate through the chat rooms, IRC channels, listserves and wikis that give laborious birth to GPL v3. But from a legal standpoint, this is the type of unintended ambiguity that makes it long past time to retire GPL v2 to the licensing hall of fame. v2 is a notoriously unlitigated document, but if it ever were, there would be no way to predict many of the outcomes.
Whether you agree with the FSF's stance on Software Patents or DRM, participate in the comment process being applied to v3 to avoid at least this type of ambiguity at the start.
David G. Rickerby, Esq. is the head of IT Licensing at Choate, Hall & Stewart LLP in Boston, Massachusetts. The opinions stated here are his own and do not represent the views of his firm or his clients. They certainly don't represent legal advice. If you need a lawyer, go get one!
The definition of "illegal"
in reference to spyware is potentially messy.
1. Illegal usage will change over time, and vary quite
widely across different jurisdictions. For example something
as mundane as a web proxy log may be illegal depending
on the context and jurisdiction.
2. Restrictions on use in that it can not be an effective
copy control mechanism.
the freedom to run the program for any purpose (called
"freedom 0")
I understand the intent, however such a restriction
IMAO violates a fundamental principal of free software.
Date Wed, 25 Jan 2006 17:39:16 -0500 (EST) From Linus Torvalds <> Subject Re: GPL V3 and Linux - Dead Copyright Holders On Wed, 25 Jan 2006, Chase Venters wrote: > > This means that when the code went GPL v1 -> GPL v2, the transition was > permissible. Linux v1.0 shipped with the GPL v2. It did not ship with a > separate clause specifying that "You may only use *this* version of the GPL" > as it now does. (I haven't done any research to find out when this clause was > added, but it was after the transition to v2). Bzzt. Look closer. The Linux kernel has _always_ been under the GPL v2. Nothing else has ever been valid. The "version 2 of the License, or (at your option) any later version" language in the GPL copying file is not - and has never been - part of the actual License itself. It's part of the _explanatory_ text that talks about how to apply the license to your program, and it says that _if_ you want to accept any later versions of the GPL, you can state so in your source code. The Linux kernel has never stated that in general. Some authors have chosen to use the suggested FSF boilerplate (including the "any later version" language), but the kernel in general never has. In other words: the _default_ license strategy is always just the particular version of the GPL that accompanies a project. If you want to license a program under _any_ later version of the GPL, you have to state so explicitly. Linux never did. So: the extra blurb at the top of the COPYING file in the kernel source tree was added not to _change_ the license, but to _clarify_ these points so that there wouldn't be any confusion. The Linux kernel is under the GPL version 2. Not anything else. Some individual files are licenceable under v3, but not the kernel in general. And quite frankly, I don't see that changing. I think it's insane to require people to make their private signing keys available, for example. I wouldn't do it. So I don't think the GPL v3 conversion is going to happen for the kernel, since I personally don't want to convert any of my code. > If a migration to v3 were to occur, the only potential hairball I see is if > someone objected on the grounds that they contributed code to a version of the > kernel Linus had marked as "GPLv2 Only". IANAL. No. You think "v2 or later" is the default. It's not. The _default_ is to not allow conversion. Conversion isn't going to happen. Linus
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Created June 1, 1998; Last modified: March 12, 2019
January 27th, 2006 at 8:42am
Linux will not be placed under the terms of GPL v3. Linux himself said so: Lihttp://lkml.org/lkml/2006/1/25/273
January 27th, 2006 at 11:38am
You’re misunderstanding something. The TiVo application itself need not be released, but if they use any packages licensed under GPLv3 (say, shellutils, since it seems the kernel itself is unlikely to be relicensed), then according to the proposed terms they won’t be able to “deny users that run covered works the full exercise of the legal rights granted by this License”, namely the right to modify the shellutils on the device.
January 27th, 2006 at 1:08pm
Here’s my understanding: let’s assume that some component that Tivo needs to run is licensed under GPLv3. Tivo makes a modified version of it. They digitally sign the executable, and the Tivo box checks that signature before agreeing to run the application.
Under GPLv2, they can release the source, and people can read the source, but they can’t use that source to build code that will run in a Tivo, because they don’t have the appropriate key to sign the executable with.
Under GPLv3, they can no longer use this approach. Since the executable won’t run without a signature, they have to either provide all recipients of the binary with the means to produce their own modified, signed, runnable executables, or they can’t distribute.
However, it appears Linus objects to this model, so the kernel will continue to use GPLv2. If he does, then RMS’s plan to take free software away from the DRM people will fail, as there is too much free software they can still use.