A Linux User's Open Response to Darl McBride's Open Letter
A Linux User's Response to Darl McBride's Open Letter to the Open Source Community
By John Gabriel, NYC, 9/11/03
"What comes of litigation? Poverty and degradation to any community that will encourage it. Will it build cities, open farms, build railroads, erect telegraph lines and improve a country? It will not; but it will bring any community to ruin." -- Brigham Young, JD 11:259.
"Contracts are what you use against those with whom you have relationships." -- Darl McBride
Dear Mr. McBride,
First, let me introduce myself. My name is John Gabriel. I have been working in the technical field for 15 years, as a Network Administrator, Applications Manager, Network Manager, Sr. Networking Engineer, and now, Freelance Consultant. And, yes, I'm an MCSE.
My first experiences with Unix occurred in the late 1970's, during school field trips to local colleges. I also did Unix technical support for students while taking a class in Pascal in the late 1980's. My first experience with Linux dates to 1994, when I downloaded whatever Linux kernel was available at that time.
While I did install it successfully, on a Compaq Deskpro 386/25, I quickly abandoned it as the Deskpro didn't have enough memory to support the X Windows System. Several years later, in 1998, I became a Caldera customer, with a purchase of Caldera OpenLinux Base ver. 1.22, with Linux kernel 2.0.33. I ran into similar problems once more.
About a year ago, I again became interested in Linux, and now run Linux on my home workstation in a dual-boot configuration with Windows XP.
About 4-5 months ago, I began following the SCO v. IBM story. I was at first inclined to be open-minded towards SCO's claims. It wouldn't be the first time a small company has had its copyrights violated by a larger vendor, though the violator is usually, in my experience, Microsoft, as exemplified by Caldera's history with DR-DOS.
However, the more I researched the story and SCO's claims, the more convinced I became that SCO's claims were, well, baseless. Being the type that usually likes to "root for the underdog", I was surprised by my conclusions.
Anyway, that's enough introduction. What follows is an Open Response to your Open Letter to the Open Source Community, refuting your arguments paragraph by paragraph. I grant everyone, including you, permission to re-publish it, or quote from it, without restriction, except that my comments be properly attributed to myself. Consider it under a "BSD-style" license if you like.
1) The most controversial issue in the information technology industry today is the ongoing battle over software copyrights and intellectual property. This battle is being fought largely between vendors who create and sell proprietary software, and the Open Source community. My company, the SCO Group, became a focus of this controversy when we filed a lawsuit against IBM alleging that SCO's proprietary Unix code has been illegally copied into the free Linux operating system. In doing this we angered some in the Open Source community by pointing out obvious intellectual property problems that exist in the current Linux software development model.
Response to Paragraph 1 of your "Open Letter":
This is very difficult to respond to, because your analysis of the issues and of the reasons for the Open Source community's anger is so bad, in the words of the great physicist Wolfgang Pauli, "it's not even wrong."
For instance, your own lawsuit against IBM does not allege that "SCO's proprietary Unix code has been illegally copied into Linux" -- it alleges that code *owned* by IBM but under contractual "control" rights to SCO has been copied into Linux. Surely, you don't dispute that IBM owns the relevant copyrights and patents to NUMA, JFS, and RCU?
Or do you dispute Section 2 of Exhibit C on your web site, the ATT-IBM sideletter agreement, which states in part, "we (ATT) agree that modifications and derivative works prepared by or for you (IBM) are owned by you"?
The truth is there are many reasons the open source community is angered with you and the actions of The SCO Group and The Canopy Group, none of which have to do with "intellectual property problems that exist in the current Linux software development model." We don't believe such problems exist. We do believe that The SCO Groups legal theories of what constitutes "derivative works" have no basis in copyright, patent, or trademark law, have no basis in SCO's contracts with various licensees, and are frivolous in the legal sense.
We are further angered by your statements in the press comparing us to communists, thieves, and terrorists, and implying that we knowingly aid terrorists. We also object to statements that we do not care about intellectual property. As I think you will discover, if you read this response all the way through, we not only care about it very deeply, but are quite knowledgeable on the subject.
Finally, we are angry because of statements such as those contained in your opening paragraph, throughout the rest of the Open Letter, and elsewhere, that can at best be construed as ignorant of the underlying issues and documents, somewhat less charitably as technological, managerial, and communicative incompetence, or, at worst, willful and deceitful misstatement and manipulation of the known facts.
2) This debate about Open Source software is healthy and beneficial. It offers long-term benefits to the industry by addressing a new business model in advance of wide-scale adoption by customers. But in the last week of August two developments occurred that adversely affect the long-term credibility of the Open Source community, with the general public and with customers.
Response to Paragraph 2:
There is nothing "new" about the Open Source business model. The Open Source business model is much older than the proprietary software business model. The Free Software Foundation was first founded in 1985. Before that, at the dawn of the electronic computer era in the 1930's and 40's, research, ideas, and source code was shared freely in order to propel the advancement of computer architectures. This continued well into the present, and other projects that would be considered "Open Source" now, though the term was not widespread at the time, would include the Apple I, and the Altair -- the first inexpensive and programmable electronic computers for consumers.
3) The first development followed another series of Denial of Service (DDoS) attacks on SCO, which took place two weeks ago. These were the second and third such attacks in four months and have prevented Web users from accessing our web site and doing business with SCO. There is no question about the affiliation of the attacker - Open Source leader Eric Raymond was quoted as saying that he was contacted by the perpetrator and that "he's one of us." To Mr Raymond's partial credit, he asked the attacker to stop. However, he has yet to disclose the identity of the perpetrator so that justice can be done.
Response to Paragraph 3:
Eric Raymond's attribution of the recent SCO downtime to a DDoS attack by a senior networking engineer is regarded by many in the community as unreliable. I, myself, ran some traceroutes while SCO's website was down, reported them at Groklaw and Slashdot, and determined that if there was a DoS attack in progress, it was like none ever seen before: despite the traffic that would be necessary to shut down SCO's web site, no other close sites on the Center 7 network appeared to be affected. Furthermore, repeated calls to SCO confirmed that the site was down for maintenance. Until SCO provides logs to prove it was under a DoS attack, I'm afraid many in the community will regard SCO's accusations as spurious. So, you see, there are questions as to the reasons for, and provenance of, SCO's downtime in late August and early September.
4) No one can tolerate DDoS attacks and other kinds of attacks in this Information Age economy that relies so heavily on the Internet. Mr Raymond and the entire Open Source community need to aggressively help the industry police these types of crimes. If they fail to do so it casts a shadow over the entire Open Source movement and raises questions about whether Open Source is ready to take a central role in business computing. We cannot have a situation in which companies fear they may be next to suffer computer attacks if they take a business or legal position that angers the Open Source community. Until these illegal attacks are brought under control, enterprise customers and mainstream society will become increasingly alienated from anyone associated with this type of behavior.
Response to Paragraph 4:
Anyone would agree with the general tenor of your statements, Mr. McBride. However, it looks like misdirection to many of us, since the provenance of SCO's downtime remains in doubt, since your statements do not address the issues of SCO's case against IBM nor SCO's accusations about misappropriation of intellectual property rights in general, and since such attacks are frowned upon and abhorred by the large majority of the open source community.
5) The second development was an admission by Open Source leader Bruce Perens that UNIX System V code (owned by SCO) is, in fact, in Linux, and it shouldn't be there. Mr Perens stated that there is "an error in the Linux developer's process" which allowed Unix System V code that "didn't belong in Linux" to end up in the Linux kernel (source: ComputerWire, August 25, 2003). Mr Perens continued with a string of arguments to justify the "error in the Linux developer's process." However, nothing can change the fact that a Linux developer on the payroll of Silicon Graphics (SGI) stripped copyright attributions from copyrighted System V code that was licensed to Silicon Graphics under strict conditions of use, and then contributed that source code to Linux as though it was clean code owned and controlled by SGI. This is a clear violation of SGI's contract and copyright obligations to SCO. We are currently working to try and resolve these issues with SGI.
Response to Paragraph 5:
The code you refer to was traced back to Dennis Ritchie and Ken Thompson, who created Unix for Bell Labs in 1969. It far precedes the development of System V, the *only* Unix to which SCO can conceivably claim any rights. This also illustrates a major problem with SCO's claims to "ownership" of Unix. The Unix System V source code is itself derivative of previous Unixes. Whether or not SCO's system for identifying similar and "obfuscated" code in Linux is reliable, and there are very strong doubts in the community about that as well, the system you are using makes no attempt to verify the provenance of the code. So far, SCO has yet to publicly identify a single snippet of code that has been both copied into Linux, and verified to have originated in System V.
You have also taken Mr. Perens' statements completely and egregiously out of context. For the record, the quote comes from his analysis of the code snippets presented at SCOForum, and the full quote is: "In this case, there was an error in the Linux developer's process (at SGI), and we lucked out that it wasn't worse. It turns out that we have a legal right to use the code in question, but it doesn't belong in Linux and has been removed."
In other words, the code in question was released, by Caldera among others interestingly enough, for use in open source projects, and does not illegally infringe on SCO's intellectual property. Mr. Perens' statement that it does not belong in Linux is due to there being no necessity to support the hardware platform for which is was written, and that the code itself is "ugly" in the sense of being poorly written by today's standards and not conforming to the usual coding style of Linux.
"Nothing can change the fact that a Linux developer on the payroll of Silicon Graphics stripped copyright attributions from copyrighted System V code..." Nothing, except, inconveniently, that it is not a fact. The fact is that SGI did extensive due diligence before contributing any code to Linux, and the code in question long precedes the development of Unix System V. SGI have themselves publicly disputed your contentions, and seem prepeared to do so in court as well.
6) This improper contribution of Unix code by SGI into Linux is one small example that reveals fundamental structural flaws in the Linux development process. In fact, this issue goes to the very heart of whether Open Source can be trusted as a development model for enterprise computing software. The intellectual property roots of Linux are obviously flawed at a systemic level under the current model. To date, we claim that more than one million lines of Unix System V protected code have been contributed to Linux through this model. The flaws inherent in the Linux process must be openly addressed and fixed.
Response to Paragraph 6:
"This improper contribution of Unix code by SGI into Linux..." As this statement has already been refuted in response to the previous paragraph, no further comment on it is necessary. Your further observations regarding the "structural" and "systemic" "flaws in the Linux development process" relying on this incorrect "fact" are also refuted.
Your claim that over "one million lines of Unix System V protected code have been contributed to Linux" is, as you know, strongly contested by the Linux community in general, and in court by Red Hat and IBM. The SCOForum presentation strongly suggests that this number was determined by simply adding up all the lines of code contributed by System V licensees without regard for the provenance of the code they contributed or the due diligence they practiced before releasing it.
7) At a minimum, IP sources should be checked to assure that copyright contributors have the authority to transfer copyrights in the code contributed to Open Source. This is just basic due diligence that governs every other part of corporate dealings. Rather than defend the "don't ask, don't tell" Linux intellectual property policy that caused the SCO v IBM case, the Open Source community should focus on customers' needs. The Open Source community should assure that Open Source software has a solid intellectual property foundation that can give confidence to end users. I respectfully suggest to Open Source developers that this is a far better use of your collective resources and abilities than to defend and justify flawed intellectual property policies that are out of sync with the needs of enterprise computing customers.
Response to Paragraph 7:
"At a minimum, IP sources should be checked to assure that copyright contributors have the authority to transfer copyrights in the code contributed to Open Source."
They are. The Linux kernel is built and maintained by some of the best and most experienced coders in the world. Code contributions are regularly debated in the Linux Kernel Mailing List (henceforth LKML). If none of the coders object to the insertion of a particular piece of code in the kernel, it is, and can be safely assumed, that the kernel contributors recognize it as either original or legally unencumbered.Furthermore, all contributions to the kernel are required to be accompanied by a hard copy statement that the contributor owns the code and has the rights to contribute it. A good example is the Read, Copy, Update module (RCU) which SCO has consistently claimed violates their IP rights. The insertion of this code into the Linux kernel source base was debated on the LKML and it was not accepted until IBM proved its ownership of the code and delivered a hard copy patent agreement allowing it to be released under the GPL.
There is no "don't ask, don't tell" policy amongst the Linux kernel contributors. The due diligence practiced by them far exceeds the standard level of diligence generally practiced in the industry. The source code is also freely available, allowing anyone to verify whether the code is infringing on their copyrights or patents, which provides a further diligence check on the code. You know this well, for your abuse of this privilege would not otherwise have been possible. And, in the unlikely event that SCO actually does provide evidence that code originating in Unix System V has been copied into Linux, all you will have proved is that the system does indeed work.
8) I believe that the Open Source software model is at a critical stage of development. The Open Source community has its roots in counter-cultural ideals - the notion of "Hackers" against Big Business - but because of recent advances in Linux, the community now has the opportunity to develop software for mainstream American corporations and other global companies. If the Open Source community wants its products to be accepted by enterprise companies, the community itself must follow the rules and procedures that govern mainstream society. This is what global corporations will require. And it is these customers who will determine the ultimate fate of Open Source - not SCO, not IBM, and not Open Source leaders.
Response to Paragraph 8:
"The Open Source community has its roots in counter-cultural ideals..."
As noted above, in response to paragraph 2, the open source community's ideals are rooted in mainstream academic and research practice. While I profess to be socially liberal and fiscally moderate, the open source community's political and social ideals run the gamut from libertarian to anarchist, and conservative to liberal. Many have become part of the open source community because they believe the process advocated within it constitutes the best way to do business within the technical community. There is no doubt within the community that the creation of software is undergoing a commodification process. We believe that the best response is to participate in that process, which enables the quickest advancement of technical excellence.
"If the Open Source community wants its products to be accepted by enterprise companies..."
It is already accepted by enterprise companies. Deal with it. Try to understand it and understand why.
"... the community itself must follow the rules and procedures that govern mainstream society."
See the response to paragraph 7. You are repeating yourself.
"This is what global corporations will require. And it is these customers who will determine the ultimate fate of Open Source..."
A statement that we can both agree on. And the fate being determined for open source appears to be that of rapidly accelerating adoption.
9) Some enterprise customers have accepted Open Source because IBM has put its name behind it. However, IBM and other Linux vendors are reportedly unwilling to provide intellectual property warranties to their customers. This means that Linux end users must take a hard look at the intellectual property underpinnings of Open Source products and at the GPL (GNU General Public License) licensing model itself.
Response to Paragraph 9:
Most enterprise customers have accepted Open Source because of unreasonable proprietary licensing obligations, and because Linux has proven to be more robust than most proprietary Unixes. For instance, Cisco switched to Linux on its internal print servers when, after a blackout, its Linux servers came back up without any administrative interaction; Cisco's Solaris print servers did not.
So you see, enterprise customers did not accept "Open Source because IBM has put its name behind it"; IBM put its name behind Linux because enterprise customers already accepted it. This is known as "meeting customer demand", which is generally considered a good business practice. You may want to consider emulating it.
"...Linux end users must take a hard look at the intellectual property underpinnings of Open Source products and at the GPL (GNU General Public License) licensing model itself."
Yes, let's take a "hard look" at the GPL. The GPL grants end-users the ability to do anything they want with GPL'd code without restriction except distribute it. This means they can modify it, put it on as many machines as they want, hell, they can even copy the code to CD's and throw a big GPL Bonfire Party, local fire codes permitting.
What they can't do is *distribute* it without restriction. This is the case with any copyrighted work. The "price" (speaking metaphorically) is that if original or modified GPL code is distributed, it must be distributed on the same terms under which it was received -- the GPL. Copyrights must be preserved. If you have modified the code, copyright for your modifications must be included. Source code must be available. Any warranty disclaimers must be preserved. A copy of the GPL must be included. The end-user must be granted all the same rights to do whatever they want with the code without restriction, except distribute it. To distribute it, they must do so under the terms of the GPL. Repeat recursively.
Distributing GPL'd code under conditions which do not meet its requirements violates the copyrights of all other contributors to the GPL'd code.
As per Section 4 of the GPL: "You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License..."
Section 5 of the GPL further stipulates: "You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it."
Your attempts to sublicense SCO's alleged intellectual property in Linux violates section 4 of the GPL. Your continued distribution of the Linux kernel via your ftp site violates the copyright of all other contributors to the kernel.
It seems that a "hard look" at the GPL leaves SCO in violation of copyright and in breach of the GPL's distribution terms.
It also appears that the only reason to object to the GPL is if SCO wishes to distribute GPL'd code without crediting the authors of said code, or to do so without regard for the conditions under which the authors have chosen to license it.
10) If the Open Source community wants to develop products for enterprise corporations, it must respect and follow the rule of law. These rules include contracts, copyrights and other intellectual property laws. For several months SCO has been involved in a contentious legal case that we filed against IBM. What are the underlying intellectual property principles that have put SCO in a strong position in this hotly debated legal case? I'd summarize them in this way:
Response to Paragraph 10:
"If the Open Source community wants to develop products for enterprise corporations, it must respect and follow the rule of law."
"These rules include contracts,..."
It is unreasonable to hold the open source community liable for violations of contracts to which they are not a party and are not privy. Your assertions to the contrary are legally frivolous.
The Linux, Open Source, and Free Software communities all have a high regard for copyright. Indeed, they must. Their own contributions are not protectable under the GPL unless they copyright their own code. Your continued assertions that they do not respect copyright are unreasonable, frivolous, fly in the face of their own needs to respect copyright, and in this case, are slanderous.
"... and other intellectual property laws."
The other intellectual property laws that would concern us here are trademark and patent.
As far as patent law goes, SCO has made no claims of patent violation in court, for the simple reason that SCO owns no Unix related patents. Therefore, in relation to SCO's claims, patents are a moot issue. SCO's claims in interviews that Linux is violating its patents are libelous, since, again, SCO has no Unix related patents to violate.
The Unix trademark, and the specification under which products can be advertised under the Unix trademark, are both owned by The Open Group. Again, SCO has no claims, and has filed no claims, under trademark law. SCO's repeated public statements that it "owns Unix" or is the "owner of Unix", however, are arguably violations of The Open Group's trademarks, especially since the only part of any Unix SCO can defensibly, and only potentially, lay claim to are original portions of the System V source code, i.e., those portions not derived from previous Unixes available through open source licenses or public domain.
"What are the underlying intellectual property principles that have put SCO in a strong position in this hotly debated legal case?"
SCO is not in a strong position.
A) SCO does not "own" Unix; it merely, and debatably, owns the Unix System V source code and the licensing contracts related to it. In the BSD case, the presiding judge ruled that ATT was unlikely to be able to defend its copyrights. Nothing has occurred in the past 10 years to make those copyrights more defensible and much has occurred to make them even less defensible. Any attempt by SCO to defend such copyright is likely to end with the entirety of Unix System V source code being declared public domain. Perhaps this is why you have not filed for any copyright violations in the IBM or Red Hat suits yet, Mr. McBride?
B) SCO's right to terminate IBM's Unix System V license, and by extension AIX and Dynix, have been contested by IBM and a third party to the controlling contract, Novell.
C) IBM's contract grants it a "perpetual" and "irrevocable" license (Amendment X).
D) SCO has made no attempt to mitigate its alleged damages by identifying the allegedly infringing code portions under reasonable conditions. No, Mr. McBride, the NDA under which SCO allows perusal of the allegedly infringing code is not reasonable. Nor did SCO extend even that offer to IBM before filing suit.
E) SCO's lack of mitigatory action leaves it in violation of its contractual obligation to IBM to exert "mutual good faith best efforts to resolve any alleged breach" (ATT-IBM Sideletter agreement, section 5).
F) SCO must defend itself against patent violations claimed by IBM in its counter-suit.
G) SCO's release of "ancient Unixes", its distribution of Linux under the GPL, and its historical abrogation of due diligence activities that could have identified any allegedly infringing code *years* earlier, leave it with "unclean hands".
H) The code base in question, Unix System V, is itself derived from previous Unixes that have since been made available under open source licenses, leaving very little System V code protectable. Much of the System V codebase was also illegally misappropriated from BSD Unix, as discovered during the BSD case. Unixware's Linux Kernel Personality is widely believed to include uncredited and misappropriated GPL code from Linux, violating the copyrights of the kernel contributors and breaching the GPL.
And so on. Etcetera ad finis.
In short, SCO is not in a strong position.
11) "Fair use" applies to educational, public service and related applications and does not justify commercial misappropriation. Books and Internet sites intended and authorized for the purpose of teaching and other non-commercial use cannot be copied for commercial use. We believe that some of the SCO software code that has ended up in the Linux operating system got there through this route. This violates our intellectual property rights.
Response to Paragraph 11:
The "Fair Use" doctrine applies only in cases of copyright violation. Again, SCO has filed no claims yet of copyright violation. Bringing it up in the context of the IBM case is misleading and manipulative.
Furthermore, your explanation of the "Fair Use" doctrine is completely incorrect. "Fair Use" applies to any quotation and/or use of copyrighted work that does not unduly infringe the copyright holder's rights. It is not restricted to "educational, public service, and related applications".
"Books and Internet sites intended and authorized for the purpose of teaching and other non-commercial use cannot be copied for commercial use."
Code taught in schools is effectively public domain -- students cannot be held liable for infringing "authorization" contracts they know nothing about and are not party to. Any code that ended up in Linux through this route is either public domain, or under an open source license. It cannot violate your intellectual property rights, since you have none under these conditions.
12) Copyright attributions protect ownership and attribution rights -they cannot simply be changed or stripped away. This is how copyright owners maintain control of their legal rights and prevent unauthorized transfer of ownership. Our proprietary software code has been copied into Linux by people who simply stripped off SCO's copyright notice or contributed derivative works in violation of our intellectual property rights. This is improper.
Response to Paragraph 12:
Again, you have not filed for any copyright violations in court. Perhaps you are preparing the ground for adding such charges to the responses due 9/25 in the Red Hat and IBM cases? Or perhaps you never will file any copyright charges, knowing that ATT already found out the hard way that if they tried to defend their copyrights in court, they would come under considerable risk of having those copyrights placed under public domain?
In any case, your accusations that ATT, SCO, or Caldera code has been stripped of copyrights and inserted into Linux is slanderous and libelous until you file for copyright violations in court and successfully defend those copyrights
Furthermore, no one is claiming that SCO transferred ownership of its copyrights. What is being claimed is the unarguable fact that SCO itself distributed Linux under the GPL, and that SCO cannot retroactively "unlicense" it..
13) In copyright law, ownership cannot be transferred without express, written authority of a copyright holder. Some have claimed that, because SCO software code was present in software distributed under the GPL, SCO has forfeited its rights to this code. Not so - SCO never gave permission, or granted rights, for this to happen.
Response to Paragraph 13:
You are still being misleading about the status of your copyright claims, since you have not filed for any copyright violations anywhere. Nor has anyone claimed that SCO transferred its copyrights to anyone else, but that SCO itself licensed its code under the GPL. Furthermore, any claim that SCO didn't realize for 3 years that it was releasing it's own code under the GPL is likely to be laughed out of court. You had the code, you could compare the System V and Linux code bases, SCO had previously featured in its public statements its intent to combine the Unix and Linux code bases, and now you claim you didn't know?
Mr. McBride, the only way to defend this in court is to tell the judge that you are a complete idiot, and that all previous mangement was equally incompetent. Even if a court and jury buys that explanation, I hardly think they'll reward SCO's utter stupidity to the tune of 3 billion dollars. It's far more likely they will require SCO to pay IBM's court costs instead.
14) Transfer of copyright ownership without express written authority of all proper parties is null and void.
Response to Paragraph 14:
And distributing your own product under an open source license, then claiming that you didn't know it was your own product, that you thought it was someone else's, makes you look like a jackass. I suspect it will provide evidence for a class action suit on the part of your shareholders.
I mean, Mr. McBride, do you really have no idea how clueless these arguments make you look?
15) Use of derivative rights in copyrighted material is defined by the scope of a license grant. An authorized derivative work may not be used beyond the scope of a license grant. License grants regarding derivative works vary from license to license - some are broad and some are narrow. In other words, the license itself defines the scope of permissive use, and licensees agree to be bound by that definition. One reason SCO sued IBM is due to our assertions that IBM has violated the terms of the specific IBM/SCO license agreement through its handling of derivative works. We believe our evidence is compelling on this issue.
Response to Paragraph 15:
"Use of derivative rights in copyrighted material is defined by the scope of a license grant."
Such as SCO's distribution of the Linux kernel under the GNU General Public License, again in the unlikely event that any origianl System V source code is ever found within Linux.
"An authorized derivative work may not be used beyond the scope of a license grant. License grants regarding derivative works vary from license to license - some are broad and some are narrow. In other words, the license itself defines the scope of permissive use, and licensees agree to be bound by that definition."
Unless otherwise defined within the contract, derivative works are understood in case law to be works that include code from the original work. Just because a program or portion of code provides functionality within a work does not mean it is a "derived" work. There is no definition of derived works in the contracts made publicly available at SCO's web site, and also by the US Federal Court System through PACER, on which to base such claims. Thus, your evidence so far is not compelling.
Furthermore, contracts cannot typically override copyright law, nor can the terms defined within them typically override precedent.
"One reason SCO sued IBM is due to our assertions that IBM has violated the terms of the specific IBM/SCO license agreement through its handling of derivative works."
In fact, the evidence you have made publicly available includes the ATT-IBM sideletter agreement, in Section 2 of which ATT grants IBM "ownership" of all works derived by or for IBM. In other words, rather than being compelling, your own evidentiary exhibits contradict your claim.
16) The copyright rules that underlie SCO's case are not disputable. They provide a solid foundation for any software development model, including Open Source. Rather than ignore or challenge copyright laws, Open Source developers will advance their cause by respecting the rules of law that built our society into what it is today. This is the primary path towards giving enterprise companies the assurance they need to accept Open Source products at the core of their business infrastructure. Customers need to know that Open Source is legal and stable.
Response to Paragraph 16:
"The copyright rules that underlie SCO's case are not disputable."
So far, SCO's case has been based on contract law, with nary a copyright claim in sight. Therefore, there are no "copyright rules" underlying SCO's case at all, much less any to dispute.
The copyright claims SCO has made in press release, public announcements, interviews, and, now, open letter, are based on legal theories, such as SCO's definition of "derivative work" that are clearly disputable, since they make assertions that are not supported by previous case law, and are not supported by the controlling contracts.
17) Finally, it is clear that the Open Source community needs a business model that is sustainable, if it is to grow beyond a part-time avocation into an enterprise-trusted development model. Free Open Source software primarily benefits large vendors, which sell hardware and expensive services that support Linux, but not Linux itself. By providing Open Source software without a warranty, these largest vendors avoid significant costs while increasing their services revenue. Today, that's the viable Open Source business model. Other Linux companies have already failed and many more are struggling to survive. Few are consistently profitable. It's time for everyone else in the industry, individuals and small corporations, to under this and to implement our own business model - something that keeps us alive and profitable. In the long term, the financial stability of software vendors and the legality of their software products are more important to enterprise customers than free software. Rather than fight for the right for free software, it's far more valuable to design a new business model that enhances the stability and trustworthiness of the Open Source community in the eyes of enterprise customers.
Response to Paragraph 17:
"Finally, it is clear that the Open Source community needs a business model that is sustainable,
It's been sustaining itself for 20 years; Linux, for 12 years. The SCO Group has never claimed a profitable quarter until this year, and those profits were due to one-time sales of perpetual licenses to Microsoft and Sun. Where will future revenues for SCO come from, Mr. McBride? It seems that The SCO Group itself needs to find "a business model that is sustainable."
"... if it is to grow beyond a part-time avocation into an enterprise-trusted development model."
It is clearly enterprise-trusted already. Were this not the case, you would be unable to claim that Linux has taken revenue away from SCO.
"Free Open Source software primarily benefits large vendors..."
Funny, but I find it very beneficial to have an operating system that I can legally use for free, that comes with source code so I can make my own modifications if desired, and that allows me to use my system without regard to proprietary end-user license obligations. But, hey, maybe I'm just a freak.
"By providing Open Source software without a warranty, these largest vendors avoid significant costs while increasing their services revenue."
Hmm, well, let's take a look at the warranty provided in Microsoft's End-User License Agreement for Windows XP Home. After all, that's got to be one of the most widely published and accepted warranty agreements in the world, right?
WARRANTY AND SPECIAL PROVISIONS FOR
THE UNITED STATES OF AMERICA
AND ANY OTHER COUNTRY
LIMITED WARRANTY. Manufacturer warrants that (a) the SOFTWARE will perform substantially in accordance with the accompanying written materials for a period of ninety (90) days from the date of receipt, and (b) any Microsoft hardware accompanying the SOFTWARE will be free from defects in materials and workmanship under normal use and service for a period of one (1) year from the date of receipt. Any implied warranties on the SOFTWARE and Microsoft hardware are limited to ninety (90) days and one (1) year, respectively. Some states/jurisdictions do not allow limitations on duration of an implied warranty, so the above limitation may not apply to you.
CUSTOMER REMEDIES. Manufacturer's and its suppliers' entire liability and your exclusive remedy shall be, at Manufacturer's option, either (a) return of the price paid, or (b) repair or replacement of the SOFTWARE or hardware that does not meet this Limited Warranty and which is returned to Manufacturer with a copy of your receipt. This Limited Warranty is void if failure of the SOFTWARE or hardware has resulted from accident, abuse, or misapplication. Any replacement SOFTWARE or hardware will be warranted for the remainder of the original warranty period or thirty (30) days, whichever is longer.
NO OTHER WARRANTIES. To the maximum extent permitted by applicable law, Manufacturer and its suppliers disclaim all other warranties, either express or implied, including, but not limited to implied warranties of merchantability and fitness for a particular purpose, with regard to the SOFTWARE, the accompanying written materials, and any accompanying hardware. This limited warranty gives you specific legal rights. You may have others which vary from state/jurisdiction to state/jurisdiction.
NO LIABILITY FOR CONSEQUENTIAL DAMAGES. To the maximum extent permitted by applicable law, in no event shall Manufacturer or its suppliers be liable for any damages whatsoever (including without limitation, special, incidental, consequential, or indirect damages for personal injury, loss of business profits, business interruption, loss of business information, or any other pecuniary loss) arising out of the use of or inability to use this product, even if Manufacturer has been advised of the possibility of such damages. In any case, Manufacturer's and its suppliers' entire liability under any provision of this agreement shall be limited to the amount actually paid by you for the SOFTWARE and/or Microsoft hardware. Because some states/jurisdictions do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation may not apply to you.
Looks pretty minimal, doesn't it, Mr. McBride? Well, Microsoft is not SCO, to state the obvious. I'm sure SCO provides better warranties. Let's look at the warranties supplied in the SCO License for Intellectual Property in Linux:
7.0 LIMITATION OF WARRANTY
SCO MAKES NO WARRANTIES OF ANY KIND EXPRESSED OR IMPLIED WITH RESPECT TO ANY SOFTWARE OTHER THAN THE SCO INTELLECTUAL PROPERTY DEFINED BY THIS AGREEMENT.
SCO WARRANTS THAT IT IS EMPOWERED TO GRANT THE RIGHTS GRANTED HEREIN. SCO DOES NOT WARRANT THAT THE FUNCTION CONTAINED IN SCO PRODUCT WILL MEET YOUR REQUIREMENTS OR THAT ITS OPERATION WILL BE UNINTERRUPTED OR ERROR FREE.
ALL WARRANTIES, TERMS, CONDITIONS, REPRESENTATIONS, INDEMNITIES AND GUARANTEES WITH RESPECT TO THE SOFTWARE, WHETHER EXPRESS OR IMPLIED, ARISING BY LAW, CUSTOM, PRIOR ORAL OR WRITTEN STATEMENTS BY ANY PARTY OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OR ANY IMPLIED WARRANTY OF NON-INFRINGEMENT OF THIRD PARTY INTELLECTUAL PROPERTY RIGHTS) ARE HEREBY OVERRIDDEN, EXCLUDED AND DISCLAIMED. SOME STATES OR COUNTRIES DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS AND YOU MAY ALSO HAVE OTHER RIGHTS WHICH VARY FROM STATE TO STATE OR COUNTRY TO COUNTRY.
8.0 LIMITATION OF LIABILITY
UNDER NO CIRCUMSTANCES WILL SCO OR ITS REPRESENTATIVES BE LIABLE FOR ANY CONSEQUENTIAL, INDIRECT, SPECIAL, PUNITIVE, OR INCIDENTAL DAMAGES, WHETHER FORESEEABLE OR UNFORESEEABLE, BASED ON YOUR CLAIMS OR THOSE OF YOUR CUSTOMERS (INCLUDING BUT NOT LIMITED TO, CLAIMS FOR LOSS OF DATA, GOODWILL, PROFITS, USE OF MONEY OR USE OF THE SCO PRODUCTS, INTERRUPTION IN USE OR AVAILABILITY OF DATA, STOPPAGE OF OTHER WORK OR IMPAIRMENT OF OTHER ASSETS), ARISING OUT OF BREACH OR FAILURE OF EXPRESS OR IMPLIED WARRANTY, BREACH OF CONTRACT, MISREPRESENTATION, NEGLIGENCE, STRICT LIABILITY IN TORT OR OTHERWISE, EXCEPT ONLY IN THE CASE OF PERSONAL INJURY WHERE AND TO THE EXTENT THAT APPLICABLE LAW REQUIRES SUCH LIABILITY. IN NO EVENT WILL THE AGGREGATE LIABILITY WHICH SCO MAY INCUR IN ANY ACTION OR PROCEEDING EXCEED THE TOTAL AMOUNT ACTUALLY PAID BY YOU TO SCO FOR THE LICENSE OF THE SCO PRODUCT THAT DIRECTLY CAUSED THE DAMAGE.
SOME JURISDICTIONS DO NOT ALLOW THE LIMITATION OF EXCLUSION OF LIABILITY FOR INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES SO THE ABOVE LIMITATION MAY NOT APPLY TO YOU.
Hmm, "SCO makes no warranties of any kind..."? Just what are purchasers of the SCO IP license getting for their money, Mr. McBride?
Anyway, it looks like the GPL's warranty policy is right in line with industry standards, Microsoft and SCO included.
"Other Linux companies have already failed and many more are struggling to survive."
As in any business. And other Linux companies, such as Red Hat and SUSE are clearly quite successful. Last time I checked, for instance, Red Hat's market capitalization was roughly ten times that of SCO's.
"Few are consistently profitable."
The same can be said of most businesses, such as restaurants, book stores, and SCO.
"It's time for everyone else in the industry, individuals and small corporations, to under this..."
"...and to implement our own business model - something that keeps us alive and profitable."
SCO's business model has proven to be not profitable. Why would anyone else want to implement it? The profits SCO did achieve in the most recent quarter are, arguably, due to SCO slashing its personel and associated office costs. Shrinking your assets is not generally considered a sustainable method for achieving profits over the long term; eventually, you tend to run out of assets.
"In the long term, the financial stability of software vendors and the legality of their software products are more important to enterprise customers than free software."
Agreed. This explains SCO's poor performance in the enterprise market.
"Rather than fight for the right for free software, it's far more valuable to design a new business model that enhances the stability and trustworthiness of the Open Source community in the eyes of enterprise customers."
From the point of view of the open source community, it seems pretty silly to abandon a business model that works.
18) A sustainable business model for software development can be built only on an intellectual property foundation. I invite the Open Source community to explore these possibilities for your own benefit within an Open Source model. Further, the SCO Group is open to ideas of working with the Open Source community to monetize software technology and its underlying intellectual property for all contributors, not just SCO.
Response to Paragraph 18:
"A sustainable business model for software development can be built only on an intellectual property foundation."
Such as the GPL's foundation on copyright law.
"I invite the Open Source community to explore these possibilities for your own benefit within an Open Source model."
We've been doing so for 20 years. We invite you, Mr. McBride, to explore our principles and ideas yourself, with an open mind and without the defamatory comments denigrating the open source community.
"Further, the SCO Group is open to ideas of working with the Open Source community to monetize software technology and its underlying intellectual property for all contributors, not just SCO."
Monetize: 1. To legalize as money 2. To coin into money: for example, to monetize gold 3. to give the character of money to. Random House Unabridged Dictionary, 1967.
Mr. McBride, I suspect that you are simply using the word "monetize" incorrectly. It's become a bad, sloppy, fashion among MBA's in recent years to use it as a synonym for the phrase "make profit from."
But, on the off chance that you chose the word with careful consideration and are using it metaphorically, the Linux, Open Source, and Free Software communities are already "monetizing" software technology. It is "monetized" every time a company saves several thousand dollars on software purchasers that can be used instead to further build the business and/or hire more employees, or share the savings in terms of higher salaries, or greater shareholder profits. It is "monetized" every time an administrator or developer customizes source code to enhance productivity for a company, an option not available under proprietary, closed source, code. It is "monetized" every time a technological enhancement or bug fix is contributed to the wider community, enabling the software to develop quicker pace than any proprietary company could achieve on its own, and saving the company the cost of applying the enhancement or bug fix again whenever it upgrades.
Your failure to grasp this concept, that "monetization" occurs at a faster pace and is shared more equitably under open source, and the GPL in particular, is one of the sorest points of contention between you and the open source community.
19) In the meantime, I will continue to protect SCO's intellectual property and contractual rights. The process moving forward will not be easy. It is easier for some in the Open Source community to fire off a "rant" than to sit across a negotiation table. But if the Open Source community is to become a software developer for global corporations, respect for intellectual property is not optional - it is mandatory. Working together, there are ways we can make sure this happens.
Response to Paragraph 19:
"In the meantime, I will continue to protect SCO's intellectual property..."
If you find any, please let us know. We would love to see it. Show it to us, so we can respect your copyrights by removing it from the Linux code base. But as long as you fail to show it to us, without NDA, then forgive us if the only rational response we can make is to ignore you as we would the boy who cried wolf.
"...and contractual rights."
Go to it. Just be sure to confine the remedies to people with whom you actually do have contracts. Seeking remedies from both the people you have contracts with and the end-users is considered "double-dipping", and is generally frowned upon in the courts.
"The process moving forward will not be easy. It is easier for some in the Open Source community to fire off a "rant" than to sit across a negotiation table."
Perhaps. However, if I may raise a counter-point, it would seem that SCO's problem is that SCO's onerous negotiating conditions have made it easier for IBM and Red Hat to fire off claims and counter-claims in court and in response. I suggest to you that SCO may want to reconsider it's own negotiating strategies and conditions.
"But if the Open Source community is to become a software developer for global corporations, respect for intellectual property is not optional - it is mandatory."
Agreed. Perhaps this explains Linux's global success in contrast to SCO's failures.
"Working together, there are ways we can make sure this happens."
Mr. McBride, working together, the Linux community is already making sure this happens. They are just doing it without you. Working with you is no longer an option. Your credibility is shot, and no one in the community will enter into a contractual agreement with a partner whose philosophy has been publicly stated to be "Contracts are what you use against those with whom you have relationships."
Best regards to all,
The SCO Group
With all truth and sincerity,
Computer, Networking, and Technical Consultant
Manhattan Borough, New York City