Could the real intent of free kernel code or software be to deprive the Federal Government, AT&T (ultimately consumers?) and Novell of licensing fees? COULD THIS BE IN COMPLETE CONFLICT WITH THE INTENT OF THE ORIGINAL CONSENT DECREE REGARDING THE BREAKUP OF THE BELL TELEPHONE SYSTEM, AND MAKING BELL LABS’ PATENTS, including the Unix kernel software or code, which was to be AVAILABLE FOR A FEE?

 

Or is free Linux kernel software keeping consumer prices down, and/or is part of a marketing plan that mostly benefits the richest computer industry insiders? 

 

A complex retracing the history of the code and some litigation about the code will hopefully answer some of these questions.  IT MAY ALSO POINT TO A PATTERN OF CRIMINAL ACTIVITY WITHIN THE INDUSTRY BY VARIOUS AND/OR NEARLY ALL ENTITIES MAKING THE GREATEST PROFITS! There may be indications there is a complex variety of crimes as a result of various long term problems regarding the Consent Decree and richest computer industry insiders.

 

THE rarely recognized ISSUES regarding the SCO Litigation likely are:

 

(1) Does the Federal Government actually OWN SOME, OR MOST, of the Unix kernel code created at CAL for the DARPA contract due to Joy’s actions at CAL?  This issue may be obscured by many of the other issue surrounding various SCO Group (SCO) based litigation. WOULD THIS BE IN COMPLETE CONFLICT WITH THE INTENT OF THE ORIGINAL CONSENT DECREE REGARDING THE BREAKUP OF THE BELL TELEPHONE SYSTEM, AND MAKING BELL LABS’ PATENTS (only AT&T kernel code made modular by Bill Joy and others created at CAL for the DARPA contract) AVAILABLE FOR A FEE BECAUSE IT MAKES SOFTWARE AVAILABLE TO MANY AT NO COST?  

 

(2) WHY WOULD AT&T SELL ITS CODE TO NOVELL, WHICH allegedly PUT A SLANDER ON THE TITLE against SCO? Is it true that NOVELL falsely stated they owned through copyrights rather than SCO?  Later SCO allegedly sold the code to Microsoft (Bill Joy allegedly had a heavy investment in Microsoft around 1989 likely due to this, and this may have brought on emotional, ethical, or territorial problems for Bill Joy).  WOULD THIS not BE IN CONFLICT WITH THE INTENT OF THE ORIGINAL CONSENT DECREE REGARDING THE BREAKUP OF THE BELL TELEPHONE SYSTEM, AND MAKING BELL LABS’ PATENTS (only non-Unix AT&T kernel code) AVAILABLE FOR A FEE?   

http://216.109.125.130/search/cache?ei=UTF-8&p=bill+joy+invested+in+microsoft&fr=ush1-mail&u=www.cedsolutions.com/birmingham/java_faq.shtm&w=bill+joy+invested+microsoft&d=T-ykEWP9NDVK&icp=1&.intl=us

 

(3) AND THEN why would Caldera (WHICH became The SCO Group) ALLOW IT TO BECOME FREE IN LINUX under the GPL?   WOULD THIS BE not IN CONFLICT WITH THE INTENT OF THE ORIGINAL CONSENT DECREE REGARDING THE BREAKUP OF THE BELL TELEPHONE SYSTEM, AND MAKING BELL LABS’ PATENTS (only non-Unix AT&T kernel code) AVAILABLE BECAUSE IT MAKES SOFTWARE AVAILABLE TO MANY AT NO COST?    

 

(4) Should the GPL be an unenforceable contract?  WOULD THIS not BE IN CONFLICT WITH THE INTENT OF THE ORIGINAL CONSENT DECREE REGARDING THE BREAKUP OF THE BELL TELEPHONE SYSTEM, AND MAKING BELL LABS PATENTS (only non-Unix AT&T kernel Code) AVAILABLE FOR FREE BECAUSE IT MAKES SOFTWARE AVAILABLE TO MANY AT NO COST?)   

 

(5) Why would various universities (especially the State of California) seem to support open source, the GPL, or Royalty free software?  (WOULD THIS not BE IN CONFLICT WITH THE INTENT OF THE ORIGINAL CONSENT DECREE REGARDING THE BREAKUP OF THE BELL TELEPHONE SYSTEM, AND MAKING BELL LABS’ PATENTS (especially if this consists of almost no AT&T Unix kernel Code) AVAILABLE FOR FREE BECAUSE IT MAKES SOFTWARE AVAILABLE TO MANY AT NO COST?  

 

(6) Why would private industry, such as IBM, Redhat, support free software? WOULD THIS not BE IN CONFLICT WITH THE INTENT OF THE ORIGINAL CONSENT DECREE REGARDING THE BREAKUP OF THE BELL TELEPHONE SYSTEM, AND MAKING BELL LABS’ PATENTS (only non-Unix AT&T kernel code, and may, or may not, also apply to derivative code, especially for more advanced hardware applications) AVAILABLE FOR FREE BECAUSE IT MAKES SOFTWARE AVAILABLE TO MANY AT NO COST?

 

(7) WOULD the Linux code partly not BE IN CONFLICT WITH THE INTENT OF THE ORIGINAL CONSENT DECREE REGARDING THE BREAKUP OF THE BELL TELEPHONE SYSTEM, AND MAKING BELL LABS’ PATENTS (only non-Unix AT&T kernel code, and may, or may not, also apply to derivative code, especially for more advanced hardware applications) AVAILABLE FOR FREE BECAUSE IT MAKES SOFTWARE AVAILABLE TO MANY AT NO COST?

 

Some of these issues border on UNIX Monopoly issues, even if they are not being introduced in the SCO v. IBM Linux lawsuit, which is a strange and tangled tale partly well described in SCO v. IBM at wikipedia.org as follows:

 

On August 6, 2003, IBM filed its counterclaims against SCO. It made 10 counterclaims:

·         breach of contract

·         Lanham Act violation

·         Unfair competition

·         Intentional interference with prospective economic relations

·         Unfair and deceptive trade practices

·         Breach of the GNU General Public License

·         and four counts of patent infringement

In response to these counterclaims, SCO has asserted that the GPL is unenforceable, void, and violates the United States Constitution. If these claims are true, then the GPL'd applications that SCO continues to distribute (like Samba) are being distributed without the permission of the copyright owners of those applications (since the permission was the GPL itself), which would be illegal. Thus some speculate that, in order to remain legally consistent, SCO will claim that software that has been GPL'd is actually in the public domain.

On September 25, 2003 IBM amended its counterclaims bringing the total number of counterclaims to 13. The new counterclaims are:

·         Copyright infringement

o        This counterclaim involves an alleged copyright infringement by SCO of GPL-licensed IBM code in the Linux kernel. Some commentators have pointed out that if SCO manages to invalidate the GPL, they are highly likely to be caught by this counterclaim, as it is of the same form as their claim against IBM.[13]

·         Promissory estoppel

·         Declaratory judgment

On March 29, 2004 IBM amended its counterclaims again. It dropped one of the patent infringement claims, but added 2 new Declaratory judgments of Noninfringement of Copyrights. One of these seeks a declaration that IBM's AIX-related activities do not infringe any of SCO's copyrights. The other one seeks a similar declaration about IBM's Linux-related activities.

…

A number of Linux supporters have characterized SCO's actions as an attempt to create fear, uncertainty and doubt about Linux. Many believe that SCO's aim is to be bought out by IBM. Others have pointed to Microsoft's subsequent licensing of the SCO source code as a possible quid pro quo for SCO's action.

Univention GmbH, a Linux integrator, reported on May 30, 2003 it was granted an injunction by a Bremen court under German competition law that prohibits the SCO Group's German division from saying that Linux contains illegally obtained SCO intellectual property. If the SCO Group continues to express this position, they would have to pay a fine of €250,000. A similar injunction was sought around the same time in Poland.

…

SCO's major claims have now been reported as relating to the following components of the Linux kernel:

• symmetric multiprocessing (SMP),
• non-uniform memory access (NUMA) multiprocessing,
• the read-copy-update (RCU) locking strategy,
• This technique is widely believed to have been developed at Sequent Computer Systems, who were then bought by IBM, who holds several patents (including 5,442,758) on this technique.
• SGI's Extended File System (XFS),
• IBM's JFS journaling file system

These claims flow from the accusation of breach of contract. The contract between IBM and AT&T (to which SCO claims to be successor in interest) allows IBM to use the SVR4 code, but the SVR4 code, plus any derivative works made from that code, must be held confidential by IBM. According to IBM's interpretation of the contract, and the interpretation published by AT&T in their "$ echo" newsletter in 1985, "derivative works" means any works containing SVR4 code. But according to SCO's interpretation, "derivative works" also includes any code built on top of SVR4, even if that does not contain, or even never contained, any SVR4 code. Thus, according to SCO, any AIX operating system code that IBM developed must be kept confidential, even if it contains nothing from SVR4.

…

SCO currently claims:

 

Any code belonging to SCO that might have been GPL'd was done by SCO employees without proper legal authorization, and thus is not legally GPL'd.

That for code to be GPL'd, the code's copyright owner must put a GPL notice before the code, but since SCO itself wasn't the one to add the notices, the code was never GPL'd.

http://en.wikipedia.org/wiki/SCO_v._IBM_Linux_lawsuit

 

Some of these issues border on SCO Monopoly issues described in SCO_v._Novell at wikipedia.org as follows:

 

On April 10, 2006, SuSE (part of Novell) filed a Request for Arbitration with the Secretariat of the ICC International Court of Arbitration in Paris, France. Years earlier SCO (then named Caldera) had signed contracts with SuSE (now owned by Novell) involving UnitedLinux. In this contract the UnitedLinux members agreed that each member would have broad licenses to exploit and distribute Linux products that include UnitedLinux technology, and they agreed to arbitration of disagreements. This request by SuSE was in response to SCO's amended complaint against Novell alleging copyright infringement. The arbitration process has relatively strict timelines, unlike the U.S. courts' procedures. Novell filed a "Motion to Stay Claims Raising Issues Subject to Arbitration" in the U.S. courts, saying that four of five SCO claims (including copyright infringement) have been brought to arbitration, and thus can be stayed in the U.S. court until the Arbitration Tribunal renders its decision. Novell also filed an "Answer to SCO's 2d Amended Complaint and Counterclaims", claiming a large number of affirmative defenses, one of which accuses SCO of conducting fraud on the U.S. copyright office.

 

http://en.wikipedia.org/wiki/SCO_v._Novell

 

Some of these issues border on Microsoft Monopoly issues, suggesting major investment and involvement by Microsoft in the various SCO Linux lawsuits, explained in SCO-Linux_controversies at wikipedia.org as follows:

 

SCO and BayStar Capital

 

In October 2003, BayStar Capital and Royal Bank of Canada invested USD$50 million in The SCO Group to support the legal cost of SCO's Linux campaign. Later it was shown that BayStar was referred to SCO by Microsoft, whose proprietary Windows operating system competes with Linux. In 2003, BayStar looked at SCO on the recommendation of Microsoft, according to Lawrence R. Goldfarb, managing partner of BayStar Capital: "It was evident that Microsoft had an agenda".

 

On April 22, 2004, The New York Times (p.C6) reported that BayStar Capital, a private hedge fund which had arranged for $50M in funding for SCO in October 2003, was asking for its $20M back. The remainder of the $50M was from Royal Bank of Canada. SCO stated in their press release that they believed that BayStar did not have grounds for making this demand.

On August 27, 2004 SCO and BayStar resolved their dispute.

 

SCO and Canopy Group

 

The Canopy Group is an investment group with shares in a trust of different companies. It is a group owned by the Noorda family, also founders of Novell.

Until February 2005, Canopy held SCO shares, and the management of SCO held shares of Canopy. The two parties became embroiled in a bitter dispute when the Noorda family sought to oust board member Ralph Yarro III on claims of misappropriation. With internal problems not made public (which included the suicides of an employee and the daughter of Ray Noorda), the Canopy Group agreed to buy back all the shares that SCO had in Canopy in exchange for their SCO shares and cash.

SCO and the Canopy Group are now completely independent.

 

Microsoft funding of SCO confirmed

 

On March 4, 2004, a leaked SCO internal e-mail detailed how Microsoft has paid SCO over $100 million, via the BayStar deal and other means. Blake Stowell of SCO confirmed the memo was real. BayStar claimed the deal was suggested by Microsoft, but that no money for it came directly from them. Microsoft, at the time, had $550 million invested with BayStar.

 

http://en.wikipedia.org/wiki/SCO-Linux_controversies

 

The hacking (The author I USES THE TERM HACKING TO PARTLY AVOID LITIGATION, WHICH CAN MEAN STEALING CODE, OR PUTTING TOGETHER CODE INEFFICIENTLY AND UNINTELLEGENTLY, AND IS SOMETIMES REFERRED TO AS WRITING UGLY OR SPAGETTI CODE.) may partly be due to a complex industry problem that also involves various entities in the computer industry, who profited off of massive amounts of operating system code that may have been stolen, misappropriated, or have complex copyright issues that were ROUTINELY NOT PROPERLY ENFORCED OR OBTAINED UNDER FALSE PRETENSES (USUALLY BY industry insiders, ACADEMIA, THE UNITED STATES GOVERNMENT, and/or even FOREIGN INTERESTS); THIS MAY BE DUE TO POLITICAL INTIMIDATION (or controlling the federal elective processes which usually decides which cases gets prosecuted by the U.S. Attorney General) BY MANY LEADERS IN THE COMPUTER INDUSTRY.  

 

PART OF THE INTIMIDATION MAY BE IN THE FORM OF CONSENT DECREES (This caused the divestiture of the twenty-two Bell Operating Companies –BOCs– from AT&T, prohibited AT&T from providing local exchange services, and UNQUELY demanded Bell Labs’ PATENTS become available for nominal cost; IT ALSO banned the BOCs from equipment manufacturing, long-distance services, and information services.), MONOPOLY LITIGATION (mostly against Microsoft), AND CORPORATIONS SIGNING CONTRACTS THAT WERE UNFAVORABLE TO THEM WITH MINOR ENTITES, SUCH AS THE MICROSOFT/IBM/Intel DEAL IN CREATING THE PC MARKET KNOWN AS WinTel (Microsoft, IBM and Intel are often referred to as WinTel, which is usually short for Windows and Intel computer and software design.) IBM LIKELY HOPED TO CREAT NEW MARKETS, WHICH LATER BECAME VERY BIG MARKETS THAT INTENDED TO COMPETE WITH LARGE ENTITIES, SUCH AS IBM, AND TO ENTER ENTERPRISE COMPUTING (USUALLY CONSISITNG OF ADVANCED HARDWARE OR SERVER DESIGN WITH MANY TERMINALS OR COMPUTERS LINKED TOGETHER IN A NETWORK) RATHER THAN THE HOME ENTERTAINMENT OR OFFICE, STUDENT, AND/OR SMALL BUSINESS APPLICATIONS. 

http://66.218.69.11/search/cache?ei=UTF-8&p=consent+decrees+AT%26T+information+services+computer&fr=ush1-mail&u=www.law.fsu.edu/journals/lawreview/frames/241/hughfram.html&w=consent+decrees+at%26t+information+services+computer&d=KnBr6WP9NM2H&icp=1&.intl=us

 

The Consent Decrees may have actually allowed other monopolies to be almost impossible to prevent, breakup, or excessive prices in the telecommunications, computer, software, or information industries.  The business plans for these industries may tend to favor high-priced consulting fees rather than high-priced consumer fees in the low end of the information, software and computer industries; initial low-cost software and information services often need overpriced security,  hardware, and networking fees.

 

The industry tends to demand extensive education to produce any valuable product or service, and then over-compensate those who have deeper insight into the industries.  A NEAR COMPLETE FAILURE TO REGULATE THESE INDUSTRIES, usually ALLOWS COST-SIFTING TO THE GOVERNMENT AND/OR CONSUMMERS BEYOND THAT SEEN IN THE AUTOMOBILE INDUSTRY which usually consists of SUBSIZIED PARKING, GAS PRICING, AND HOSPITAL CARE COSTS DUE TO ILLESSES CAUSED BY AIR POLLUTION,  AUTOMOBLE ACCIDENTS, AND also COSTS SHIFTED TO THE INSURANCE INDUSTRY.   This is a result of the various criminal activity that is rampant on the Internet and in the computer industry, such as identity thief, false advertising, and  fraud and extortion, often in the form of computer worms, Trojans, viruses that tend to cost shift to the health care system or to the insurance industry.   The cost-shifting may be approaching the billion dollar market, but is often considered justifiable because computers are believed to bring important efficiencies, such as better inventory control, and/or reduced labor costs, and/or reduced transportation costs to name some of the perceived most popular benefits of the so-called computerized information age.

 

This has been a long term problem and may involve government corruption, and consent decrees perhaps NOT BEING PROPERLY ENFORCED AND/OR THE STATE and/or Federal Government may BE OWED MASSIVE LICENSING FEES PERHAPS FOR TECHNOLOGY CREATED WHEN BILL JOY WAS A CAL (UNIVERSITY OF CALIFORNIA at Berkeley) EMPLOYEE.  

 

This was due to AT&T’s operating system being worked on by Joy while he was at CAL, which was brought top CAL by his professor, IN A HIGHLY UNIQUE SITUTATION who was on sabbatical from AT&T as part of a Defense Advanced Research Projects Agency (DARPA), a United States Government Agency, contract with CAL.

 

This may be considered an attempt to commercialize the Linux operating system, which is given out freely with certain conditions that the Linux code stays free of commercialization, or free of purchase price; this is known as Open Source.  (Interestingly, Bill Joy has been inconsistent about whether he maintains copyright on his software or is a big supporter of Open Source or government supported free code and/or research that he receives freely but is allowed to commercially profit from and his is covered in detail later in this book.)

 

The UNIVERSITY OF CALIFORNIA  at Berkeley Office of Technology Licensing (OTL) states (AND THIS IS IMPORTANT BECAUSE SOME UNIVERSITIES HAVE SPENT MORE MONEY IN LAWSUITS REGARDING LICENSED TECHNOLOGY THAN THEY RECEIVED IN ROYALITIES FROM LICENSES ACCORDING TO THE ATLANTIC MONTHLY ARTICLE “KEPT UNIVERSITIES”):

 

A U.S. patent alone can cost $20,000 to obtain (over a three to four year period). The University cannot justify the considerable expense of patenting unless the patent forms the basis for a commercial R&D program and provides an incentive to a commercial licensee to commercialize the invention. We work with approximately 30 patent law firms and dozens of patent attorneys (all with technical backgrounds and many with Ph.D.s) to obtain patent rights...

 

For example, software may be released as object code for one purpose and as source code for another application, or may be released at one fee for commercial users and at a reduced fee or for no charge under a license that allows only academic use...

 

Another common licensing approach is to establish separate fee structures for academic use and commercial use, or for internal use only versus distribution rights. Fees may be based on use at a specific site (site licenses) or use on a server or computer (seat licenses)...

 

Other authors might wish to request release of the object code at no charge and provide for fees or royalties for source code licensing with modification and distribution rights...

http://otl.berkeley.edu/page.php?nav=28

 

Copyright gives a copyright holder exclusive rights in some uses of the copyrighted work. This means that others may not engage in these uses without the copyright holder's permission (i.e., a license).

These rights are:

 

The right of reproduction (i.e., the right to copy the work);

The right to create derivative works (such as modifications);

The right to distribute the work;

The right to perform the work in public;

The right to display the work publicly; and

A digital transmission performance right.

http://otl.berkeley.edu/page.php?nav=28#1

 

They further state the “institution owns the copyright”:

 

The "author" of software is generally the original creator or creators of the code (note that a piece of software may have several different authors). The author(s) own(s) the copyright in the program. Under U.S. Copyright Law, when software is created in the course of the creator's employment, however, the employing institution (such as a company or academic institution) is considered the "author" of the code for copyright purposes under the "work made for hire" doctrine. This means that the institution owns the copyright, rather than the individual creator(s). Consistent with U.S. Copyright Law, University of California (UC) policy provides that the University owns software that is created by employees in the course of their employment or created using University resources and facilities; however, the authors are entitled to a share of the revenue from licensing of University-owned software that they create.

 

They may hint that the University supports "Open source", the Berkeley Software Distribution (BSD) license, and the General Public License, (GPL), and this may be partly to have an alternative to the possible overpriced Microsoft products: 

 

"Open source" is a term that loosely describes software that is licensed under terms that allow the user of the software to look at the source code and modify it, and to distribute the modifications. Beyond these general characteristics, open source licenses vary widely in their requirements. Some open source licenses (BSD license) allow modifications to be kept proprietary; some (such as the General Public License, or GPL) require that the source code for any modifications also be distributed and modifiable by users. Open source licenses generally allow the distributor to charge a distribution fee.

A wide range of licenses could theoretically be called "open source," so the Open Source Initiative (OSI) provides a certification mark for licenses that meet its definition of "Open Source." OSI has approved the most commonly used open source licenses. More information about OSI and approved licenses are available at http://www.opensource.org.

If you are developing some software that you think you would like to release under an open source license, the OTL can help you find the best distribution model and identify in advance any potential conflicts and restrictions resulting from the use of such a model (for example, encumbrances created by sponsored research agreements or issues created by the requirements of the license you would like to use) in advance.

 

Wikipedia.com’s definition of Berkeley Software Distribution (BSD) is:

 

(Note to editor: could the BSD mascot be included in hope of making this book as visual as possible)

http://en.wikipedia.org/wiki/Image:BSD-daemon-rendering.png

http://en.wikipedia.org/wiki/Berkeley_Software_Distribution

 

A judge made an unusual decision to make all of AT&T and/or all of Bell Labs patents available to the public at perhaps nominal cost to help create innovation.  Therefore, there may be complex arguments about who owns the code that Bill Joy worked with while at CAL, and if he had a right to send it out without, or without, a license and/or permission from Cal, AT&T and/or the United States Government, and/or who ordered the creation of the code?  Did DARPA (a United States Government Agency) order the code created, partly from AT&T code at CAL?

 

Later was part of that code stunningly sold to Novell (WHERE BILL JOY MAY HAVE CONNECTIONS DUE TO RELATIONSHIPS WITH THE PREVIOUS CEO AND AS A FORMER DIRECTOR AT NOVELL) by AT&T for about $750 million (PERHAPS FOR FAR BELOW THE USUAL MARKET RATES OR STANDARDS)?  Then did Novell sell part or all of that code bought by SCO Group (SCO), which was previously known as Santa Cruz Operation,  which was previously known Caldera (which later changed its name to The SCO Group), so does SCO have the right to copyright protection and licensing fees for the operating system code?

 

ALL THE OTHER ISSUES regarding the SCO Litigation MAY, or May NOT BE, OF IMPORTANCE, or accurate, or a diversion in the controversy, but they do give an indication of how complex the some of issues may be:

 

(1) Caldera OpenLinux from 2001, predate SCOs code, and embraced did not embrace opensource concept, and even used the GPL licensing contract.  In 1993, USL sold all UNIX rights and assets to Novell, including copyrights, trademarks, and active licensing contracts also know as UNIX System V Release 4, which SCO acquired through an "Asset Purchase Agreement". 

 

(2) The lawsuit didn’t cause both SCO’s and Microsoft’s website to be targeted, most likely by Bill Joy; and that wouldn’t show a pattern of criminal intent on Joy’s part regarding his involvement in BSD, etc. 

 

(3) Secrecy around the code seems to be an important and suspicious issue.  SCO is claiming not copyright but "trade secret" infringement, but trade secret infringement seems unlikely because Novell may own the actual copyright, and SCO may act as a sales agent for Novell. 

 

(4) Almost everyone does not want to embrace FREE Linux, so they want to accept the issues around this case! SCO continues to pay royalties to Novell, so likely Novell controls copyrights to at least some of the code, but some think USL v. BSD suggests those copyrights are not very enforceable; for example: “SCO was to turn over 100% of the revenue to Novell, and then Novell would return 5% as an Administration Fee.” 

 

(5) Novell claims that SCO has profited from Unix SVR4 licensing agreements with Microsoft and Sun Microsystems, but those funds were not paid Novell by SCO and that has put SCO in breach of contract!

 

6) This is actually mostly not a Breach of Contract case that does not go back to Bill Joy’s original actions regarding the code becoming free while he was at CAL because Linux is an operating system that was initially created as a hobby by a young student, Linus Torvalds, at the University of Helsinki in Finland.

 

7) Indemnification by major computer Industry Corporation for the use of Linux means that they do not think the SCO lawsuit is important even if they paid substantial royalties to SCO.

 

8) The outcome of the cases will not ultimately become obvious to the general public.

 

http://216.109.125.130/search/cache?ei=UTF-8&fr=ush1-mail&p=SVRX+source+code+sco&u=members.cox.net/docs2wilkerson/pdf/sco%2520overview.pdf&w=svrx+source+code+sco&d=ZbcxtTmtMwfh&icp=1&.intl=us

 

WE MAY NEED TO LOOK AT THE LITIGATION SURROUNDING THE SCO GROUP’S ASSERTIONS ABOUT THE LINUX CODE, ESPECIALLY REGARDING POSSIBLE COPYING DIRECTLY FORM THE UNIX CODE, TO NARROW DOWN THE SUSPECTS REGARDING VARIOUS MIXED AND BLENDED THREATS AGAINST MICROSOFT, SCO AND OTHER ENTITIES, AND TO SEE IF ROUTINELY BUSINESS IS CONDUCTED IN THE COMPUTER INDUSTRY AND SILICON VALLEY THE THE USE OF EXTORTION.  Strangely, the author of the worm may have had very little motive to create a blended threat against MICROSOFT and SCO, other than personal, and in doing some may have exposed him/hershelf to litigation on many other fronts!  This could allow a narrowing down of suspects on many, many other complex unsolved cases, possibly murder, arson, power outages, bomb threats, fraud and/or extortion just to name a few!

 

http://216.109.125.130/search/cache?_adv_prop=web&x=op&ei=UTF-8&fr=ush1-mail&va=novell+sco&va_vt=any&vp=++5%25+as+an+Administration+Fee&vp_vt=any&vo=trade+secret&vo_vt=any&ve_vt=any&vst=0&vf=all&vm=i&fl=0&n=10&u=en.wikipedia.org/wiki/SCO-Linux_controversies&w=novell+sco+trade+secret+%225+as+an+adm

inistration+fee%22&d=T9Lq4DmtNAXG&icp=1&.intl=us

 

Let’s look at various opinions regarding the four major pieces of litigation involving the SCO group:

 

SCO alleges they own all the UNIX Operating System:

 

“SCO is the owner of the UNIX Operating System Intellectual Property that dates back to 1969, when the UNIX System was created at AT&T's Bell Laboratories. Through a series of mergers and acquisitions, SCO has acquired ownership of the copyrights and core technology associated with the UNIX System.”

http://www.sco.com/scosource/

 

As gathered from the letter SCO sent out December 19 about copyright Infringement SCO also thinks Linux files contain their Unix code:

 

Any part of any Linux file that includes the copyrighted binary interface code must be removed.  Files in Linux version 2.4.21 and other versions that incorporate the copyrighted binary interfaces include:

 

Any part of any Linux file that includes the copyrighted binary interface code must be removed.  Files in Linux version 2.4.21 and other versions that incorporate the copyrighted binary interfaces include:

include/asm-alpha/errno.h include/asm-arm/errno.h include/asm-cris/errno.h include/asm-i386/errno.h include/asm-ia64/errno.h include/asm-m68k/errno.h include/asm-mips/errno.h include/asm-mips64/errno.h include/asm-parisc/errno.h include/asm-ppc/errno.h include/asm-ppc64/errno.h include/asm-s390/errno.h include/asm-s390x/errno.h include/asm-sh/errno.h include/asm-sparc/errno.h include/asm-sparc64/errno.h include/asm-x86_64/errno.h include/asm-alpha/signal.h include/asm-arm/signal.h include/asm-cris/signal.h include/asm-i386/signal.h include/asm-ia64/signal.h include/asm-m68k/signal.h include/asm-mips/signal.h include/asm-mips64/signal.h include/asm-parisc/signal.h include/asm-ppc/signal.h include/asm-ppc64/signal.h include/asm-s390/signal.h include/asm-s390x/signal.h include/asm-sh/signal.h include/asm-sparc/signal.h include/asm-sparc64/signal.h include/asm-x86_64/signal.h include/linux/stat.h include/linux/ctype.h lib/ctype.c

include/asm-alpha/ioctl.h include/asm-alpha/ioctls.h include/asm-arm/ioctl.h include/asm-cris/ioctl.h include/asm-i386/ioctl.h include/asm-ia64/ioctl.h include/asm-m68k/ioctl.h include/asm-mips/ioctl.h include/asm-mips64/ioctl.h include/asm-mips64/ioctls.h include/asm-parisc/ioctl.h include/asm-parisc/ioctls.h include/asm-ppc/ioctl.h include/asm-ppc/ioctls.h include/asm-ppc64/ioctl.h include/asm-ppc64/ioctls.h include/asm-s390/ioctl.h include/asm-s390x/ioctl.h include/asm-sh/ioctl.h include/asm-sh/ioctls.h include/asm-sparc/ioctl.h include/asm-sparc/ioctls.h include/asm-sparc64/ioctl.h include/asm-sparc64/ioctls.h include/asm-x86_64/ioctl.h include/linux/ipc.h include/linux/acct.h include/asm-sparc/a.out.h include/linux/a.out.h arch/mips/boot/ecoff.h include/asm-sparc/bsderrno.h include/asm-sparc/solerrno.h include/asm-sparc64/bsderrno.h include/asm-sparc64/solerrno.h

 

However, others dispute SCO’s contention that Linux contains Unix code; for instance, according to rickbradley.com errno.h from the above seems to atand for error responses, such as bad file number, invalid argument, arg list too long, math result not representable, no such file, no such process, file too large,  protocol error, broken pipe or no such device or address.

The above signal.h matches for bus error suggests similar design and naming practices are common in the industry and that headers may consist of unoriginal and uncopyrightable concepts  (I have highlighted signal.h which is the file name at the end of a path, so the reader gets a feel of what the paths and code looks like): 

Matches for [bus error]:

./32v/32vsrc/usr/include/signal.h

./sysiii/sys3src/usr/include/signal.h

./sysiii/sys3src/usr/src/head/signal.h

./v7/v7src/usr/include/signal.h

http://66.218.69.11/search/cache?_adv_prop=web&x=op&ei=UTF-8&fr=op&va=signal.h+&va_vt=any&vp=rickbradley.com&vp_vt=any&vo_vt=any&ve_vt=any&vst=0&vf=all&vm=i&fl=0&n=10&u=www.rickbradley.com/misc/sco-linux-source.txt&w=signal+h+%22rickbradley+.com%22&d=NLSHWjmtNHoU&icp=1&.intl=us

 

http://www.rickbradley.com/misc/sco-linux-source.txt

 

[K]ernel23.sourcesdb.com should contain source code, mostly for drivers, (and results in Internet Explorer icon with the message: “You are not authorized to view this page” for this url: http://kernel23.sourcesdb.com/s17.php).

 

This is a small sample of what is listed on the URL, also know as a Universal Resource Locator (about half of which seems to contain code for divers at the end of the page) http://kernel23.sourcesdb.com/s17.php;

           

linux include asm-sparc64 pgalloc.h
linux include asm-sparc64 sembuf.h
linux include asm-sparc64 shmbuf.h
linux include asm-arm a.out.h
linux include asm-arm ioctls.h

 

[K]ernel23.sourcesdb.com contains the following suggesting within the comments on the code that Linux is more powerful than SunOS for include/asm-sparc/ioctls.h:

 

/* Note that all the ioctls that are not available in Linux have a

* double underscore on the front to: a) avoid some programs to

* think we support some ioctls under Linux (autoconfiguration stuff)…

/* SCARY Rutgers local SunOS kernel hackery, perhaps I will support it

* someday. This is completely bogus, I know...

*/

#define __TCGETSTAT _IO('T', 200) /* Rutgers specific */

#define __TCSETSTAT _IO('T', 201) /* Rutgers specific */

 

/* Linux specific, no SunOS equivalent. */

 

Notice all begin with the word “#define” and  about half of them have a double underscore (I have highlighted the first double underscore, so the reader gets a feel of what the paths and code looks like):

 

#define TIOCGETD_IOR('t', 0, int)
#define TIOCSETD_IOW('t', 1, int)
#define __TIOCHPCL _IO('t', 2) /* SunOS Specific */
#define __TIOCMODG _IOR('t', 3, int) /* SunOS Specific */
#define __TIOCMODS _IOW('t', 4, int) /* SunOS Specific */
#define __TIOCGETP _IOR('t', 8, struct sgttyb) /* SunOS Specific */
#define __TIOCSETP _IOW('t', 9, struct sgttyb) /* SunOS Specific */
#define __TIOCSETN _IOW('t', 10, struct sgttyb) /* SunOS Specific */
#define TIOCEXCL_IO('t', 13)
#define TIOCNXCL_IO('t', 14)
#define __TIOCFLUSH _IOW('t', 16, int) /* SunOS Specific */
#define __TIOCSETC _IOW('t', 17, struct tchars) /* SunOS Specific */
#define __TIOCGETC _IOR('t', 18, struct tchars) /* SunOS Specific */
#define __TIOCTCNTL _IOW('t', 32, int) /* SunOS Specific */
#define __TIOCSIGNAL _IOW('t', 33, int) /* SunOS Specific */
#define __TIOCSETX _IOW('t', 34, int) /* SunOS Specific */
#define __TIOCGETX _IOR('t', 35, int) /* SunOS Specific */
#define TIOCCONS_IO('t', 36)
#define __TIOCSSIZE _IOW('t', 37, struct sunos_ttysize) /* SunOS Specific */
#define __TIOCGSIZE _IOR('t', 38, struct sunos_ttysize) /* SunOS Specific */
#define TIOCGSOFTCAR_IOR('t', 100, int)
#define TIOCSSOFTCAR_IOW('t', 101, int)
#define __TIOCUCNTL _IOW('t', 102, int) /* SunOS Specific */
#define TIOCSWINSZ_IOW('t', 103, struct winsize)
#define TIOCGWINSZ_IOR('t', 104, struct winsize)
#define __TIOCREMOTE _IOW('t', 105, int) /* SunOS Specific */
#define TIOCMGET_IOR('t', 106, int)
#define TIOCMBIC_IOW('t', 107, int)
#define TIOCMBIS_IOW('t', 108, int)
#define TIOCMSET_IOW('t', 109, int)
#define __TIOCSTART _IO('t', 110) /* SunOS Specific */
#define __TIOCSTOP _IO('t', 111) /* SunOS Specific */
#define TIOCPKT_IOW('t', 112, int)
#define TIOCNOTTY_IO('t', 113)
#define TIOCSTI_IOW('t', 114, char)
#define TIOCOUTQ_IOR('t', 115, int)
#define __TIOCGLTC _IOR('t', 116, struct ltchars) /* SunOS Specific */
#define __TIOCSLTC _IOW('t', 117, struct ltchars) /* SunOS Specific */
/* 118 is the non-posix setpgrp tty ioctl */
/* 119 is the non-posix getpgrp tty ioctl */
#define __TIOCCDTR _IO('t', 120) /* SunOS Specific */
#define __TIOCSDTR _IO('t', 121) /* SunOS Specific */
#define TIOCCBRK _IO('t', 122)
#define TIOCSBRK _IO('t', 123)
#define __TIOCLGET _IOW('t', 124, int) /* SunOS Specific */
#define __TIOCLSET _IOW('t', 125, int) /* SunOS Specific */
#define __TIOCLBIC _IOW('t', 126, int) /* SunOS Specific */
#define __TIOCLBIS _IOW('t', 127, int) /* SunOS Specific */
#define __TIOCISPACE _IOR('t', 128, int) /* SunOS Specific */
#define __TIOCISIZE _IOR('t', 129, int) /* SunOS Specific */
#define TIOCSPGRP_IOW('t', 130, int)
#define TIOCGPGRP_IOR('t', 131, int)
#define TIOCSCTTY_IO('t', 132)
#define TIOCGSID_IOR('t', 133, int)
/* Get minor device of a pty master's FD -- Solaris equiv is ISPTM */
#define TIOCGPTN_IOR('t', 134, unsigned int) /* Get Pty Number */
#define TIOCSPTLCK_IOW('t', 135, int) /* Lock/unlock PTY */…

 

http://kernel23.sourcesdb.com/r.php?num=1623

 

In the following from the URL http://attrition.org/security/denial/w/20xpanic.dos.html Floody seems to hint that Unix programming in linux has caused security problems:

   From: Floody 

To: linux-alert@redhat.com, linux-security@redhat.com

Date: Wed, 3 Dec 1997 15:47:35 -0500 (EST)

Subject: [linux-alert] Insufficient allocations in net/unix/garbage.c

 

[Mod: linux-kernel removed from To: list. --alex]

 

 

-----BEGIN PGP SIGNED MESSAGE-----

 

Kernels 2.0.x do not sufficiently allocate space for the internal stack

used for garbage collection on unix domain sockets.  I have neither

tested 2.1.x kernels.

 

http://216.109.125.130/search/cache?fr=ush2-mail&ei=UTF-8&p=linux+net+unix+garbage.c+&u=attrition.org/security/denial/w/20xpanic.dos.html&w=linux+net+unix+garbage+c&d=K74jHGP9NDd2&icp=1&.intl=us

 

The URL http://www.x86-64.org/cgi-bin/cvsweb.cgi/abitest/ allows one to view code as stated by clicking on the Rev. column.  Therefore, much of the code is not really secret, and can likely can be viewed without signing a nondisclosure agreement with the SCO Group. 

 

http://www.x86-64.org/cgi-bin/cvsweb.cgi/abitest/

 

The CVS log for linux/include/asm-ppc64/ioctls.h, which seems to be a file  found from the SCO group letter shown above page and if you click on “Revision 1.3” of the above URL you can look at the code, which consists of about 100 short lines of definitions (this author suspects definitions resemble concepts, such as numbers, and may not be copyrightable).  Here is a short sample:

#define FIOCLEX         _IO('f', 1)

#define FIONCLEX        _IO('f', 2)

#define FIOASYNC        _IOW('f', 125, int)

#define FIONBIO         _IOW('f', 126, int)

#define FIONREAD        _IOR('f', 127, int)

#define TIOCINQ         FIONREAD

#define FIOQSIZE        _IOR('f', 128, loff_t) 

 

http://www.x86-64.org/cgi-bin/cvsweb.cgi/linux/include/asm-ppc64/ioctls.h?rev=1.3&content-type=text/x-cvsweb-markup

 

http://www.x86-64.org/cgi-bin/cvsweb.cgi/linux/include/asm-ppc64/ioctls.h?r1=1.1

 

 

Analyzing the file names from the “The Files in Linux version 2.4.21 and other versions that incorporate the copyrighted binary interfaces” above compared against the below include “Matches for [is a directory]… errno.h” may be meant to be matches for both directories in both the Linux and Unix code; whereas both have a series (alpha through cris; these may be the names of chips or architecture for similar code) which seems to repeat (about three or four times) with similar paths; a path consists of linked files or directories; usually the first two or three names in the path (path format usually  consists of a word or symbol then a “/” and then a word)  resembling include/asm-alpha “errno.h”  and “signal.h” at the end of path names.  Both the “errno.h”  and “signal.h” may have been original coding by its alleged creator Linus Trovolds. 

 

After those paths mentioned the coding may consist of mostly definitions used by in other systems may stand for various systems, such as: include/linux, 32v/32vsrc/usr/include, sysiii, v4, v5, v7, 32v or architectures (hardware design, or chip used).  Below we see there may be over a hundred matches, and below is a sample of some of the matches (I have highlighted paths with the word linux in them so the reader gets a feel of what the paths, code, especially different syntax for Linux looks like):

 

Matches for [is a directory]:

./include/asm-alpha/errno.h

./include/asm-arm/errno.h

./include/asm-cris/errno.h

./include/asm-i386/errno.h

./include/asm-ia64/errno.h

./include/asm-m68k/errno.h

./include/asm-mips/errno.h

./include/asm-mips64/errno.h

./include/asm-parisc/errno.h

./include/asm-ppc/errno.h

./include/asm-ppc64/errno.h

./include/asm-s390/errno.h

./include/asm-s390x/errno.h

./include/asm-sh/errno.h

./include/asm-sparc/bsderrno.h

./include/asm-sparc/errno.h

./include/asm-sparc64/bsderrno.h

./include/asm-sparc64/errno.h

./include/asm-x86_64/errno.h

./sysiii/sys3src/usr/include/errno.h

./sysiii/sys3src/usr/src/head/errno.h

…

Matches for [interrupt priority level]:

./32v/32vsrc/usr/include/sys/psl.h

./32v/32vsrc/usr/src/slowsys/h/mtpr.h

./32v/32vsrc/usr/src/slowsys/h/psl.h

./32v/32vsrc/usr/src/sys/h/mtpr.h

./32v/32vsrc/usr/src/sys/h/psl.h

./include/linux/dio.h

./sysiii/sys3src/usr/include/sys/mtpr.h

./sysiii/sys3src/usr/include/sys/psl.h

./sysiii/sys3src/usr/include/sys/psl.h

./sysiii/sys3src/usr/src/head/sys/mtpr.h

./sysiii/sys3src/usr/src/head/sys/psl.h

./sysiii/sys3src/usr/src/head/sys/psl.h

…

Matches for [accounting command name]:

./32v/32vsrc/usr/include/sys/acct.h

./32v/32vsrc/usr/src/slowsys/h/acct.h

./32v/32vsrc/usr/src/sys/h/acct.h

./include/linux/acct.h

./v7/v7src/usr/include/sys/acct.h

./v7/v7src/usr/sys/h/acct.h

…

Matches for [major device number]:

./include/linux/tty_driver.h

./sysiii/sys3src/usr/src/cmd/fsdb.c

…

Matches for [statistics counters]:

./include/linux/cyclades.h

./sysiii/sys3src/usr/src/cmd/text/roff.d/bldtab.c

…

Matches for [size of hash table]:

./32v/32vsrc/usr/src/cmd/refer/inv1.c

./include/linux/affs_fs_sb.h

./include/linux/atalk.h

./v7/v7src/usr/src/cmd/refer/inv1.c

…

Matches for [command to send]:

./include/linux/mtio.h

./sysiii/sys3src/usr/src/rje/kmcrje.d/util/rjestat.c

…

Matches for [owners group id]:

./32v/32vsrc/usr/include/sys/ino.h

./32v/32vsrc/usr/src/slowsys/h/ino.h

./32v/32vsrc/usr/src/sys/h/ino.h

./arch/parisc/kernel/sys_parisc.c

./include/linux/efs_fs_i.h

./sysiii/sys3src/usr/include/sys/ino.h

./sysiii/sys3src/usr/src/head/sys/ino.h

./v7/v7src/usr/include/sys/ino.h

./v7/v7src/usr/sys/h/ino.h

 

http://www.rickbradley.com/misc/sco-linux-source.txt

 

These libraries are needed to develop programs Files in Linux version 2.4.21, which use the standard C Library from SUSE LINUX Enterprise Server 9 for IBM® POWER™ Service Pack 3 is about 10 times the amount in the in the Novell enterprise code seen in the following link, which may suggest that LINUX Enterprise is more valuable than Novell Enterprise software partly due to more device driver programming:

http://www.novell.com/products/linuxpackages/enterpriseserver/SP3/ppc/glibc-devel.html

 

http://216.109.125.130/search/cache?ei=UTF-8&fr=ush1-mail&p=UNIX+Derived+Files+copied&u=lwn.net/Articles/64052/&w=unix+derived+files+copied&d=XKsz2zmtNDPG&icp=1&.intl=us

 

The files “include/asm-parisc/ioctl.h” and “include/asm-parisc/ioctl.h” seem to be device driver programming.  This may be the main thing Sun and Microsoft might not to infringement on copyright ownership, which Linus Torvalds doesn’t seem to comment on in his letter bellow.  Linus Torvalds argues the code shows immature, embarrassing programming (buggy) that he did on the Linux kernel in an emailed dated Mon, 22 Dec 2003 denying he copied Unix:

 

Date Mon, 22 Dec 2003 13:31:51 -0800 (PST)

From Linus Torvalds <>

Subject Re: hmm..

 

On Mon, 22 Dec 2003, John Dee wrote:

>

> I know you guys have already probably seen this.. figured I'd share with

> the class, so the big kids can tear it apart.

> http://lwn.net/Articles/64052/

 

I spent half an hour tearing part of it apart for some journalists. No guarantees for the full accuracy of this write-up, and in particular I don't actually have "original UNIX" code to compare against, but the files I checked (ctype.[ch]) definitely do not have any UNIX history to them.

 

The rest of the files are mostly errno.h/signal.h/ioctl.h (and they are

apparently the 2.4.x versions, before we moved some common constants into "asm-generic/errno.h"), and while I haven't analyzed them, I know for a fact that

 

 - the original errno.h used different error numbers than "original UNIX"

 

   I know this because I cursed it later when it meant that doing things like binary emulation wasn't as trivial - you had to translate the error numbers.

 

 - same goes for "signal.h": while a lot of the standard signals are well documented (ie "SIGKILL is 9"), historically we had lots of confusion  (ie I think "real UNIX" has SIGBUS at 10, while Linux didn't originally  have any SIGBUS at all, and later put it at 7 which was originally  SIGUNUSED.

 

So to me it looks like

 - yes, Linux obviously has the same signal names and error number names that UNIX has (so the files certainly have a lot of the same

identifiers)

 

 - but equally clearly they weren't copied from any "real UNIX".

 

(Later, non-x86 architectures have tried harder to be binary-compatible with their "real UNIX" counter-parts, and as a result we have different errno header files for different architectures - and on non-x86 architectures the numbers will usually match traditional UNIX).

 

For example, doing a "grep" for SIGBUS on the kernel shows that most architectures still have SIGBUS at 7 (original Linux value), while alpha, sparc, parisc and mips have it at 10 (to match "real UNIX").

 

What this tells me is that the original code never came from UNIX, but some architectures later were made to use the same values as UNIX for binary compatibility (I know this is true for alpha, for example: being compatible with OSF/1 was one of my very early goals in that port).

 

In other words, I think we can totally _demolish_ the SCO claim that these 65 files were somehow "copied". They clearly are not.

 

Which should come as no surprise to people. But I think it's nice to see just _how_ clearly we can show that SCO is - yet again - totally incorrect.

 

                        Linus

 

----

For example, SCO lists the files "include/linux/ctype.h" and "lib/ctype.h", and some trivial digging shows that those files are actually there in the original 0.01 distribution of Linux (ie September of 1991). And I can state

 

 - I wrote them (and looking at the original ones, I'm a bit ashamed:

   the "toupper()" and "tolower()" macros are so horribly ugly that I

   wouldn't admit to writing them if it wasn't because somebody else

   claimed to have done so ;)

 

 - writing them is no more than five minutes of work (you can verify that  with any C programmer, so you don't have to take my word for it)

 

 - the details in them aren't even the same as in the BSD/UNIX files (the approach is the same, but if you look at actual implementation details you will notice that it's not just that my original "tolower/toupper"  were embarrassingly ugly, a number of other details differ too).

 

In short: for the files where I personally checked the history, I can definitely say that those files are trivially written by me personally, with no copying from any UNIX code _ever_.

 

So it's definitely not a question of "all derivative branches". It's a question of the fact that I can show (and SCO should have been able to see) that the list they show clearly shows original work, not "copied".

 

 

            Analysis of "lib/ctype.c" and "include/linux/ctype.h".

 

 

First, some background: the "ctype" name comes "character type", and the whole point of "ctype.h" and "ctype.c" is to test what kind of character we're dealing with. In other words, those files implement tests for doing things like asking "is this character a digit" or "is this character an uppercase letter" etc. So you can write thing like

 

            if (isdigit(c)) {

                        .. we do something with the digit ..

and the ctype files implement that logic.

 

Those files exist (in very similar form) in the original Linux-0.01 release under the names "lib/ctype.c" and "include/ctype.h". That kernel was released in September of 1991, and contains no code except for mine (and Lars Wirzenius, who co-wrote "kernel/vsprintf.c").

 

In fact, you can look at the files today and 12 years ago, and you can see clearly that they are largely the same: the modern files have been cleaned up and fix a number of really ugly things (tolower/toupper works properly), but they are clearly incremental improvement on the original one.

 

And the original one does NOT look like the unix source one. It has several similarities, but they are clearly due to:

 

 - the "ctype" interfaces are defined by the C standard library.

 

 - the C standard also specifies what kinds of names a system library    interface can use internally. In particular, the C standard specifies that names that start with an underscore and a capital letter are "internal" to the library. This is important, because it explains why

both the Linux implementation _and_ the UNIX implementation used a  particular naming scheme for the flags.

 

 - algorithmically, there aren't that many ways to test whether a    character is a number or not. That's _especially_ true in C, where a macro must not use it's argument more than once. So for example, the "obvious" implementation of "isdigit()" (which tests for whether a character is a digit or not) would be

 

            #define isdigit(x) ((x) >= '0' && (x) <= '9')

 

   but this is not actually allowed by the C standard (because 'x' is  used twice).

 

 This explains why both Linux and traditional UNIX use the "other"  obvious implementation: having an array that describes what each of the possible 256 characters are, and testing the contents of that array (indexed by the character) instead. That way the macro argument is only used once.

 

The above things basically explain the similarities. There simply aren't that many ways to do a standard C "ctype" implementation, in other words.

 

Now, let's look at the _differences_ in Linux and traditional UNIX:

 

 - both Linux and traditional unix use a naming scheme of "underscore and a capital letter" for the flag names. There are flags for "is upper case" (_U) and "is lower case" (_L), and surprise surprise, both UNIX and Linux use the same name. But think about it - if you wanted to use a short flag name,, and you were limited by the C standard naming, what  names _would_ you use? Maybe you'd select "U" for "Upper case" and "L" for "Lower case"?

 

 Looking at the other flags, Linux uses "_D" for "Digit", while traditional UNIX instead uses "_N" for "Number". Both make sense, but they are different. I personally think that the Linux naming makes more sense (the function that tests for a digit is called "isdigit()", not

"isnumber()"), but on the other hand I can certainly understand why

 UNIX uses "_N" - the function that checs for whether a character is

 "alphanumeric" is called "isalnum()", and that checks whether the

 character is a upper case letter, a lower-case letter _or_ a digit (aka "number").

 

In short: there aren't that many ways you can choose the names, and there is lots of overlap, but it's clearly not 100%.

 

 - The original Linux ctype.h/ctype.c file has obvious deficiencies, which  pretty much point to somebody new to C making mistakes (me) rather than any old and respected source. For example, the "toupper()/tolower()" macros are just totally broken, and nobody would write the "isascii()" and "toascii()" the way they were written in that original Linux. And you can see that they got fixed later on in Linux development, even though you can also see that the files otherwise didn't change.

  

For example: remember how C macros must only use their argument once (never mind why - you really don't care, so just take it on faith, for now). So let's say that you wanted to change an upper case character  into a lower case one, which is what "tolower()" does. Normal use is just a fairly obvious

 

            newchar = tolower(oldchar);

 

   and the original Linux code does

 

            extern char _ctmp;

            #define tolower(c) (_ctmp=c,isupper(_ctmp)?_ctmp+('a'+'A'):_ctmp)

 

which is not very pretty, but notice how we have a "temporary character" _ctmp (remember that internal header names should start with  an underscore and an upper case character - this is already slightly broken in itself). That's there so that we can use the argument "c" only once - to assign it to the new temporary - and then later on we use that temporary several times.

  

Now, the reason this is broken is

 

    - it's not thread-safe (if two different threads try to do this at once, they will stomp on each others temporary variable)

 

    - the argument (c) might be a complex expression, and as such it should really be parenthesized. The above gets several valid (but unusual) expressions wrong.

 

Basically, the above is _exactly_ the kinds of mistakes a young programmer would make. It's classic.

 

And I bet it's _not_ what the UNIX code looked like, even in 1991. UNIX by then was 20 years old, and I _think_ that it uses a simple table lookup (which makes a lot more sense anyway and solves all problems). I'd be very susprised [sic] had those kinds of "beginner mistakes" in it, but I don't actually have access to the code, so what do I know? (I can look up some BSD code on the web, it definitely does _not_ do anythign [sic] the above).

 

The lack of proper parenthesis exists in other places of the original Linux ctype.h file too: isascii() and toascii() are similarly broken.

 

In other words: there are _lots_ of indications that the code was not copied, but was written from scratch. Bugs and all.

 

Oh, another detail: try searching the web (google is your friend) for

"_ctmp". It's unique enough that you'll notice that all the returned hits are all Linux-related. No UNIX hits anywhere. Doing a google for

 

            _ctmp -linux

 

shows more Linux pages (that just don't happen to have "linux" in them), except for one which is the L4 microkernel, and that one shows that they used the Linux header file (it still says "_LINUX_CTYPE_H" in it).

 

So there is definitely a lot of proof that my ctype.h is original work.

 

http://lkml.org/lkml/2003/12/22/137

 

In a commentary called: “WHY IS SUN AND MICROSOFT PAYING LICENSING FEES TO SCO IF THEY DO NOT THINK THERE IS SOME NEED TO?” by- linux-watch.com the author writes:

 

“Sun also paid SCO in 2003 approximately $13.3 million for UNIX SVR4 (System V Release 4) code licensing rights, which was, at the time, said to be used for drivers for Solaris on Intel. As part of the deal, Sun also received a warrant to buy as many as 210,000 shares of SCO stock at $1.83 per share…Before the 2003 contract was signed, Sun had spent $82 million acquiring rights to use Unix, Smith said. Among Sun's privileges is the right to show Solaris's underlying source code to customers, SCO said.”

 

http://216.109.125.130/search/cache?_adv_prop=web&x=op&ei=UTF-8&fr=op&va=SVR4+licensing+agreements+Microsoft+Sun+Microsystems&va_vt=any&vp=SCO&vp_vt=any&vo_vt=any&ve_vt=any&vst=0&vf=all&vm=i&fl=0&n=10&u=www.linux-watch.com/news/NS5890077128.html&w=svr4+licensing+agreements+microsoft+sun+microsystems+sco&d=agQ_xDmtNCBM&icp=1&.intl=us

 

There are allegations of a massive amount of source code contributed to Linux by IBM:

 

“SCO has identified no more than around 3,700 lines of code in 17 AIX or Dynix files - all copyright IBM - that it alleges were improperly contributed for use in Linux. After publicly claiming that they owned all of the UNIX copyrights, and that Novell had slandered their title by suggesting otherwise, they asked the court to order Novell to assign the UNIX operating system copyrights which Novell still holds to SCO”

 

“SCO has no business trying to restrict access to Linux source code on the basis of state law UNIX contract claims against IBM. They have no basis upon which to collect additional licensing fees from customers for non-existent trade secrets, or copyright that are still held by Novell either. Unfortunately there are six thousand organizations with UNIX licenses, so this sort of thing could go on for quite some time. SCO still continues to claim that Linux contains UNIX System V source code.”

http://search.yahoo.com/search?p=SCO+has+identified+no+more+than+around+3%2C700+lines+of+code+in+17+&prssweb=Search&ei=UTF-8&fr=ush1-mail&x=wrt

 

http://216.109.125.130/search/cache?ei=UTF-8&fr=ush1-mail&p=SVRX+source+code+sco&u=members.cox.net/docs2wilkerson/pdf/sco%2520overview.pdf&w=svrx+source+code+sco&d=ZbcxtTmtMwfh&icp=1&.intl=us

Andrew Grygus has done an unusually comprehensive page about Sun Microsystem's, HP's (Hewlett Packard), Research Firms, lawfirms motivation or opinions regarding SCO and Linux:

Like Microsoft, Sun Microsystem's business model is directly and severely threatened by Linux, but unlike Microsoft, they are of two minds about it. The evidence is that there are two powerful tribes within Sun locked in a power struggle, the Solaris tribe and the Linux tribe. This causes rather erratic behavior.

Like Microsoft, Sun contributed money through a licensing deal, but unlike Microsoft they actually had an excuse, though a weak one - saving money on developing certain device drivers for certain projects. Sun didn't need license for Unix itself because they'd paid Novell $100 million for ownership equivalence [sic] of the Unix code when Novell owned Unix.

 

SCO Group itself declared that all was right with Sun and they had no intellectual property beef with Sun at all.

Meanwhile, Sun signed an agreement with SuSE to provide Linux for a major push against Microsoft on the desktop - in complete and total violation of SCO Group's Linux claims. It's pretty obvious Sun isn't taking SCO Group's threats at all seriously…

 

On the other hand, HP sells a lot more servers running Linux, and to protect this business from SCO's Group's attacks, HP has become the first Linux provider to indemnify its customers against lawsuits by SCO Group…

 

Research Firms seem to form their advice depending on how close a relationship they have with Microsoft. Long term Microsoft promoter Gartner Group, for instance, is warning their clients to stick with Unix and Windows until this SCO Group flap is over - but given Gartner Group's track record for accuracy, few are worried.

 

Other research firms, like Meta Group, are advising their clients to move ahead with Linux implementation - the rewards are great and the risks are small… and Forester Research says Linux users have little to worry about…

 

Yankee Group's Laura DiDio is said not to have signed the NDA (Non Disclosure Agreement) because it's against Yankee Group policy, but gave her word she'd adhere to it … She has been almost completely uncritical of everything SCO Group has shown her and claims SCO Group has a "credible case"….She's a Microsoft analyst completely unqualified in matters of program code and I expect she anticipates favors from Microsoft for supporting their position.

 

Some other analysts also signed the NDA, including Aberdeen Group's Bill Clayton, and one representative of the open source community, Lance Taylor. Most have been far more critical of SCO Group's presentation than DiDio is. They said they were shown a block of code where about 80 lines were very similar but Claybrook expressed serious doubts about what he was shown and with SCO's behavior….Taylor also strongly doubts the ability of SCO's charges to stand up in court …

 

Writers for the technology press likewise have applied windage depending on their relationship with Microsoft, but the majority of articles advise continued implementation of Linux in the corporate environment. A number of columnists have ridiculed SCO Group strongly…

 

Even giant Ford Motor Company has recently announced it will be making major usage of Linux on its servers worldwide, and for Ford Europe it may extend far beyond the server. Government agencies worldwide, including the U.S. are rapidly adopting Linux for reasons of security, flexibility, cost, and to free their systems from proprietary data formats.

 

And SCO Group's customers? The rank and file at SCO Group genuinely want to serve their customers, are working hard and have a well laid out plan for updating and improving their products, as well as coming out with new products including Web services. Ironically, their modernization plans depend a lot on open source products, including products licensed under the GPL…

 

One of the earliest legal opinions was by lawyer Michael Overly of Foley & Lardner in Los Angeles. He states that SCO Group's code show under Non Disclosure "means absolutely, positively nothing"…

 

Novell agreed to purchase SuSE Linux. This shows just how seriously Novell is taking SCO Group's threats against Linux.

 

http://66.218.69.11/search/cache?p=BOIES%2C+SCHILLER+%26+FLEXNER+sco+complaint+novell&prssweb=Search&ei=UTF-8&fr=ush1-mail&x=wrt&u=www.aaxnet.com/editor/edit032.html%23ibm&w=boies+schiller+flexner+sco+complaint+novell&d=RCZBjzmtM_DY&icp=1&.intl=us

 

Lewis A. Mettler argues that SCO seems to be guilty of something close to extortion:

 

It is becoming all too apparent that SCO lawyers never intended to put their case before a judge much less a jury.  They know they could not convince anyone of their allegations.  This was a nuisance suit from the get go.  You know, a law suit that does not need to have any validity because the effort is just to get money in exchange for avoiding the hassle of the law suit.  Thus you have one inconsistent statement after another.  One claim defeating your own. Etc. Etc.   And SCO lawyers do not care.  They never plan to have to convince anyone of anything.  It is pure nuisance.  Clearly an effort to get something you do not have.

 

But, the nuisance has not worked.  At least not yet anyway.  And I doubt it ever will.  The impact upon the market has all but vanished because SCO itself has ruined its own creditability. And this article from Groklaw clearly illustrates that.  SCO tried first to extort consumers and have now been made the fools they are.  Suing IBM and even Novell initially might have worked but that effort is pretty much a bust as well.  There is no doubt that Novell and IBM lawyers see precisely what everyone else is seeing now.  A means to end these silly lawsuits just by allowing the issues to hit the mat and getting a decision on them.  And that is the way it will go in all likelihood.  Novell will get an arbitration award. And whatever is left from that will be handled via Summary Judgment.  And IBM is very likely to resolved [sic] almost all of its issues by Summary Judgment as well.  What will be left will not be worth two cents. 

 

SCO has made themselves to look the fools they are.

http://216.109.125.130/search/cache?ei=UTF-8&fr=ush1-mail&p=Lewis+A.+Mettler%2C+Esq.+sco&u=www.lamlaw.com/&w=lewis+mettler+esq+sco&d=NHgUfjmtNC3T&icp=1&.intl=us

 

Chandler in his analysis at Findlaw.com in a commentary called “Several Key Legal Principles May Undermine SCO's Case” claimed:

 

The first principle - which is also common sense - is that one cannot sell (or give away) a proprietary interest that one no longer possesses.

 

So even if companies purported to give UNIX rights to SCO, their supposed grant of interest would be void if they earlier had given the same rights to IBM or if they had otherwise relinquished them. You can't sell what you no longer own.

 

The second principle is that a party's rights can be affected by its later conduct - which can constitute a "waiver," giving away rights. Until recently, SCO was a willing player in the Linux movement, releasing code under the open source ("copyleft") license. Everything that happened to Linux was in the open. Yet SCO delayed in suing.

 

That delay triggers not only the waiver doctrine, but also similar equitable doctrines such as laches. Indeed, SCO may run afoul of the relevant statutes of limitations as well.

 

The third principle is that what's good for the goose is good for the gander. Here, IBM is not the only one who has to abide by its contracts; SCO does too. This may cause SCO problems.

 

When it used Linux in software it released, SCO - like everyone else - had to agree to Linux's "copyleft" licenses. In doing so, SCO arguably gave up prior rights: "Copyleft" licenses, as noted above, gave everyone the right to copy code freely, and to make improvements on it.

 

The fourth principle is that a suit must not only establish a right, it must also show the defendant violated it. The court must ask: Even if SCO had extensive rights to UNIX and never waived them, did IBM actually violate those rights by supporting Linux?

 

Again, the answer lies in the history and contracts, but a certain degree of skepticism seems warranted. Would IBM really have agreed to give up developing other operating systems, in exchange for being able to work on UNIX? IBM is, after all, the pioneer of such operating systems as OS/2….

Proprietary interests, especially in intellectual property, tend to breed confidentiality - as anyone who ever signed a nondisclosure agreement with a fledgling dotcom with a "brilliant business idea" well knows. And confidentiality, in turn, breeds conspiracy theories, and allegations of theft - or unfair competition, or breach of contract, or the like.

 

In contrast, if there is something amiss in open code, it will be more difficult to hide. Thus, Linus Torvalds retorted, "I allege SCO is full of it and that the Linux development model is the most transparent process in the whole industry." Torvalds himself has provided the most compelling reason SCO's suit must fail: Had information truly been misused in Linux's open source software, everyone and his brother - and his foreign penpal - would have been well aware of it.<

 

The final policy argument in favor of open source software is, of course, societal. At some point, information that is widely studied in universities, reprinted in college textbooks, and advanced through academic scholarship must be considered public domain.

 

For this reason, SCO's claims that its intellectual property rights extend to basic computing features of large operating systems cannot be allowed to stand. Otherwise, there will be no such thing as truly open, free software - and as a consequence, there will effectively be an economy-dragging tax on information technology.

http://writ.news.findlaw.com/commentary/20030626_chander.html

 

Taylor calls the code in question “trivial” in his analysis:

 

Taylor noticed another chink in SCO's argument: "The code is fairly trivial -- the kind of stuff I wrote in school," he wrote in Linux Journal. "The similar portions of the code were some 80 lines or so. Looking around the Net, I found close variants of the code, with the same comments and variable names, in sources other than Linux distributions. The code is not in a central part of the Linux kernel. The code does not appear to have been contributed to Linux by SCO or Caldera. The code exists in current versions of the Linux kernel." (Taylor also added that "SCO's example unsettled me by what it implies. Although in itself trivial, it does suggest that some Linux contributors may have been careless about copyright infringement. That is unfortunate.") In an interview, Taylor said that SCO told him there were many more examples of infringing code, but he wonders, he said, "why they wouldn't lead with their best stuff."

 

When asked about reactions like Taylor's, Blake Stowell, of SCO, gave a puzzling answer. Many of the people who have been unimpressed by SCO's presentation "have not been developers," he said, and they may not have understood the importance of what they were seeing. (Taylor, in fact, is a developer.) Stowell then pointed to several technology analysts who had seen the code and came away thinking that SCO could possibly have a case -- but none of these people are developers…

 

But if IBM truly believed that SCO's case was FUD, Laura DiDio wonders, why isn't it telling its customers that it will assume any legal risks they incur in using it? DiDio notes that this is a standard practice for proprietary operating system sales. "If Linux is going to take its place as an enterprise server and desktop operating system alongside Unix and Windows and Netware and Apple Macintosh, it has got to be certified ready and worthy not just from a technical standpoint but from a business standpoint," she says.

http://dir.salon.com/story/tech/feature/2003/08/18/sco_ibm/index1.html?pn=3

http://www.sco.com/scosource/complaint3.06.03.html

 

The evolution of the code is complex.  Hacking SCO’s website is possible intimidation in response to their lawsuit regarding the operating system Code and SCO seems to think some of the AT&T code is in the Linux code.

 

The opinions about Novell’s, SCO’s, IBM’s and Linux’s rights differ greatly as we see in various statements below:

 

Does Novell have the right to act on behalf of SCO and dismiss any claims against SVRx licensees?
No. Novell has attempted to interpret a single clause in the Purchase Agreement as freedom to do anything it wants in regards to the assets and copyrights it sold to SCO in 1995. Section 4.16 (b) contains language that gives Novell certain limited rights to protect its royalty stream in regards to the then existing UNIX SVRX licenses. Further clarification to this is found in Amendment No. 2 Section B (5) which states, “This Amendment does not give Novell the right to increase any SVRX license’s rights to SVRX source code, nor does it give Novell the right to grant new SVRX source code licenses. In addition, Novell may not prevent SCO from exercising its rights with respect to SVRX source code in accordance with the Agreement.” Novell’s recent actions to waive SCO’s rights to enforce its license agreements are in clear violation of the Agreement and will be dealt with accordingly through the courts.

http://66.218.69.11/search/cache?ei=UTF-8&fr=ush1-mail&p=SVRx+sco&u=www.sco.com/scosource/linuxlicensefaq.html&w=svrx+sco&d=axAq-DmtNAAx&icp=1&.intl=us

 

“SCO subsequently registered claims to the UNIX and UnixWare copyrights with the United States Copyright Office. Responding to that registration, Novell admits that Joseph LaSala sent a letter to Darl McBride on August 4, 2003, containing the following text:

We dispute SCO's claim to ownership of these copyrights. The Asset Purchase Agreement, in Schedule 1.1 (b), contains a general exclusion of copyrights from the assets transferred to Santa Cruz Operation. Amendment No. 2 provides an exception to that exclusion, but only for "copyrights...required for [Santa Cruz Operation] to exercise its rights with respect to the acquisition of UNIX and UnixWare technologies."

 

In other words, under the Asset Purchase Agreement and Amendment No. 2, copyrights were not transferred to Santa Cruz Operation unless SCO could demonstrate that such a right was "required for [Santa Cruz Operation]" to exercise the rights granted to it in the APA. Santa Cruz Operation has never made such a demonstration, and we certainly see no reason why Santa Cruz Operation would have needed ownership of copyrights in UNIX System V in order to exercise the limited rights granted SCO under the APA. Nor is there any reason to think that a transfer of the copyrights required for SCO to exercise its APA rights necessarily entails transfer of the entire set of exclusive rights associated with a particular copyrighted computer program.

 

Unless and until SCO is able to establish that some particular copyright right is "required" for SCO to exercise its rights under the APA, SCO's claim to ownership of any copyrights in UNIX technologies must be rejected, and ownership of such rights instead remains with Novell.”

http://www.finchhaven.com/TSCOG/SCO_Novell_side-by-side.html

 

“SCO has been showing examples of direct line-by-line copying of UNIX code into Linux to hundreds of industry analysts, reporters, customers, partners, and industry influencers since June of last year. To view certain parts of this code, interested parties have had to sign a non-disclosure agreement verifying that they would keep this code in confidence. SCO continues to identify and show this code to parties willing to sign a non-disclosure agreement. SCO has also publicly identified ABI header files that are copyrighted, but published and generally available for viewing. Portions of these files have been copied into Linux headers without permission. These files can be viewed at www.sco.com/scosource under “ABI Files Letter.” SCO has also shown on local media outlets examples of direct Unix copying into Linux.”

 

“SCO filed a Slander of Title lawsuit against Novell as they were intentionally attempting to interfere with SCO’s rights with respect to UNIX and UnixWare. The suit claims that Novell has improperly filed copyright registrations in the United States Copyright Office for UNIX technology covered by SCO's copyrights. A Slander of Title lawsuit does not contest ownership. It forces an entity to cease interference with rights already granted.”

http://www.sco.com/company/presskit/corrections/

Wikipedia, the free encyclopedia, definition of the  Application binary interface (ABI header files - referred to in the above paragraphs), which seems to be one of the core issues in the controversy, suggests it is very important code:

In computer software, an application binary interface (ABI) describes the low-level interface between an application program and the operating system, between an application and its libraries, or between component parts of the application. An ABI differs from an application programming interface (API) in that an API defines the interface between source code and libraries, so that the same source code will compile on any system supporting that API, whereas an ABI allows compiled object code to function without changes on any system using a compatible ABI.

ABIs cover details such as the calling convention, which controls how functions' arguments are passed and return values retrieved; the system call numbers and how an application should make system calls to the operating system; and in the case of a complete operating system ABI, the binary format of object files, program libraries and so on. A complete ABI, such as the Intel Binary Compatibility Standard (iBCS), allows a program from one operating system supporting that ABI to run without modifications on any other such system. Other ABIs standardize details such as the C++ name decoration and calling convention between compilers on the same platform, but do not require cross-platform compatibility.

Among Unix-like operating systems, where there are often many related but incompatible operating systems running on one hardware platform (particularly Intel 80386-compatible systems), there have been several attempts to standardize [sic] the ABI to reduce the effort required by application vendors to port their programs to different systems. However, to date none of these have met with much success, though the Linux Standard Base is trying to do this for Linux.

http://en.wikipedia.org/wiki/Application_binary_interface

 

From a Linux ABI history an interesting, even surprising explanation exists about the copyright issues:

 

AT&T had decided to forego copyright protection for many versions of UNIX, so use of the specifications or manuals in developing computer software wasn't automatically an infringement…. Old-SCO had partnered with AT&T and Intel in developing the Intel Binary Compatibility Specification 2nd Edition.

http://216.109.125.130/search/cache?p=Unix+System+V+kernel+infringement+linux+abi&ei=UTF-8&fr=ush1-mail&x=wrt&u=members.cox.net/docs2wilkerson/pdf/A%2520Linux%2520ABI%2520History%2520.pdf&w=unix+system+v+kernel+infringement+linux+abi&d=Gp9-OzmtMxuT&icp=1&.intl=us

 

Notice that oddly Linux is NOT mentioned as a viable operating system to use the Intel Binary Compatibility Specification Module, but SVR4 is mentioned, which suggests that Linux is not designed to work with complex chips or architecture, as found on the Debian site, which is a type of linux system:

 

Intel Binary Compatibility Specification Module

The iBCS Emulator runs binaries for other Unixes. Emulations provided:

 

 * Sparc Solaris

 * i386 BSD (386BSD, FreeBSD, NetBSD, BSDI/386) - very alpha, very old.

 * SVR4 (Interactive, Unixware, USL, Dell etc.)

 * SVR3 generic

 * SCO (SVR3 with extensions for symlinks and long filenames)

 * SCO OpenServer 5

 * Wyse V/386 (SVR3 with extensions for symlinks)

 * Xenix V/386 (386 small model binaries only)

 

http://216.109.125.130/search/cache?ei=UTF-8&fr=ush1-mail&p=Intel+Binary+Compatibility+Specification+&u=packages.debian.org/oldstable/otherosfs/ibcs-base&w=intel+binary+compatibility+specification&d=UF70xzmtM6Iv&icp=1&.intl=us

 

Wikipedia.org defines System V Release 4.0 (UNIX SVRX mentioned above  seems to be System V Release 4.0  that contains an application binary interface called the ABI header files which SCO seems to own) as:

 

System V Release 4.0 was announced on November 1, 1989 and was released in 1990. A joint project of Unix System Laboratories and Sun Microsystems, it combined technology from Release 3 as well as 4.3BSD, Xenix, and SunOS:

From BSD: TCP/IP support, sockets, csh

From SunOS: the Virtual file system interface (replacing the one in System V release 3, the "File System Switch"), Network File System (NFS), new virtual memory system including support for memory mapped files, an improved shared library system based on the SunOS 4.x model, the OpenLook GUI environment

From Xenix: x86 device drivers

Other improvements:

ksh

ANSI C compatibility

better internationalization support

an application binary interface (ABI)

support for standards such as POSIX, X/Open, and SVID3

The primary platforms for SVR4 were Intel x86 and SPARC; the SPARC version, called Solaris 2 (or, internally, SunOS 5.x), was developed by Sun. The relationship between Sun and AT&T was terminated after the release of SVR4, meaning that later versions of Solaris did not inherit features of later SVR4.x releases. Sun would in 2005 release most of the source code for Solaris 10 (SunOS 5.10) as the open source OpenSolaris project, creating the only open-source (heavily modified) System V implementation available.

Many versions of SVR4 appeared, because of hardware vendors (HP, SGI) adapting it to their platform, and because porting houses (SCO, Microport, ESIX, UHC) sold enhanced and supported x86 versions. SVR4 was even ported to the Amiga as Amiga Unix.

http://en.wikipedia.org/wiki/System_V

 

Loren Heal of healconsulting.com seems to think SCO doesn’t have a case:

 

The only items that appear in common throughout these files are the numeric values for constants specified in the industry standards documents.  I conclude that SCO is claiming ownership of the correspondence between the standard human-readable mnemonic labels and the actual values themselves. They are claiming, in essence, to own the use of a particular set of numbers.

 

The correspondence between mnemonic labels and a particular set of numeric values is a fact that has been widely published. It is my understanding SCO can claim copyright on the text and layout of their source and manuals, but not the facts they represent. That would require a patent or some other mechanism that can protect an idea or method; copyrights just protect expression. 

 

The ABIs are facts or ideas that are not copyrightable.  The documents which describe the ABIs and the source code which implements the ABIs can be copyrighted if they meet the other copyright criteria.  It is obvious that no piece of SCO UNIX source code has been copied into Linux.  SCO hasn't shown any evidence suggesting that any copying occurred, nor have they claimed a single line of copyrightable code from Linux.  What they actually claimed was copyright to a method of operation.

 

The argument that the ABIs are proprietary SCO code is obviously meritless.

http://healconsulting.com/SCO/sco-letter.html

 

The primary issue in the SCO v. IBM COMPLAINT may be:

 

5.      As set forth in more detail below, IBM has breached its obligations to SCO, induced and encouraged others to breach their obligations to SCO, interfered with SCO’s business, and engaged in unfair competition with SCO, including by:

a)      misusing UNIX software licensed by SCO to IBM and Sequent;

b)      inducing, encouraging, and enabling others to misuse and misappropriate SCO’s proprietary software; and

c)       incorporating (and inducing, encouraging, and enabling others to incorporate) SCO’s proprietary software into Linux open source software offerings.

 

IBM may be establishing UNIX-like competition by upgrading the Linux code as seen in the SCO v. IBM Amended COMPLAINT:

 

(“Novell”), acquired all right, title and interest in and to the UNIX Software Code from AT&T for $750 million in Novell stock…

 

83.   As long as the Linux development process remained uncoordinated and random, it posed little or no threat to SCO, or to other UNIX vendors, for at least two major reasons: (a) Linux quality was inadequate since it was not developed and tested in coordination for enterprise use and (b) enterprise customer acceptance was non-existent because Linux was viewed by enterprise customers as a “fringe” software product.

 

88.  In the process of moving from product offerings to services offerings, IBM dramatically increased its staff of systems integrators to 120,000 strong under the marketing brand “IBM Global Services.”  By contrast, IBM’s largest historic competitor as a seller of UNIX software, Sun Microsystems, has a staff of approximately 12,000 systems integrators.  With ten times more services-related personnel than its largest competitor, IBM sought to move the corporate enterprise computing market to a services model based on free software on Intel processors. 

 

89. By undermining and destroying the entire marketplace value of UNIX in the enterprise market, IBM would gain even greater advantage over all its competitors whose revenue model was based on licensing of software rather than sale of services…

 

91. Among other actions, IBM misappropriated the confidential and proprietary information from SCO in Project Monterey.  IBM thereafter misused its access to the UNIX Software Code.  On or about August 17, 2000, IBM and Red Hat Inc. issued a joint press release through M2 Presswire announcing, inter alia, as follows:

“IBM today announced a global agreement that enables Red Hat, Inc. to bundle IBM’s Linux-based software.

101. On information and belief, IBM has knowingly induced, encouraged, and enabled others to distribute proprietary information in an attempt to conceal its own legal liability for such distributions:

“What is wrong about this [Linux] distribution, is basically the millions of lines of code that we never have seen.  We don’t know if there are any patent infringements [in this code] with somebody we don’t know.  We don’t want to take the risk of being sued for a patent infringement.  That is why we don’t do distributions, and that’s why we have distributors.  Because distributors are not so much exposed as we are.  So that’s the basic deal as I understand it.”

 

102.  IBM is affirmatively taking steps to destroy all value of UNIX by improperly extracting and using the confidential and proprietary information it acquired from UNIX and dumping that information into the open source community.  As part of this effort, IBM has heavily invested in the following projects to further eliminate the viability of UNIX:

a) The Linux Technology Center was launched in 2001 with the advertised intent and foreseeable purpose of transferring and otherwise disposing of all or part of UNIX, including its concepts, ideas, and know-how, into an open source Linux environment; 

b)      The IBM Linux Center of Competency was launched to assist and train financial services companies in an accelerated transfer of UNIX to Linux with the advertised intent and foreseeable purpose of transferring and otherwise disposing of all or part of UNIX, including its concepts, ideas, and know-how, into an open source Linux environment;

c) A carrier-grade Linux project has been undertaken to use UNIX code, methods, concepts, and know-how for the unlawful purpose of transforming Linux into an enterprise-hardened operating system;

d)      A data center Linux project has been undertaken to use UNIX code, methods, concepts, and know-how for the unlawful purpose of transforming Linux into an enterprise-hardened operating system; and

e) Other projects and initiatives have been undertaken or supported that further evidence the improper motive and means exercised by IBM in its efforts to eliminate UNIX and replace it with free Linux.

 

http://www.sco.com/scosource/complaint3.06.03.html

16. During the past few years a competing, and free, operating system known as Linux has been transformed from a non-commercial operating system into a powerful general enterprise operating system.

17. Linux is a computer software operating system that, in material respects, is a variant or clone of UNIX System V. According to leaders within the Linux community, Linux is not just a “clone,” but is intended to displace UNIX System V.

http://66.218.69.11/search/cache?ei=UTF-8&fr=ush1-mail&p=BOIES%2C+SCHILLER+%26+FLEXNER+sco+complaint&u=news.findlaw.com/hdocs/docs/cyberlaw/scodchrys30304cmp.pdf&w=boies+schiller+flexner+sco+complaint&d=DNLLyDmtNAmV&icp=1&.intl=us

A variant or clone of UNIX currently exists in the computer marketplace called “Linux.”  Linux is, in material part, based upon UNIX source code and methods, particularly as related to enterprise computing methods found in Linux 2.4.x releases and the current development kernel, Linux 2.5.x.  Significantly, Linux is distributed without a licensing fee and without proprietary rights of ownership or confidentiality.

 

4.      The UNIX software distribution vendors, such as IBM, are contractually and legally prohibited from giving away or disclosing proprietary UNIX source code and methods for external business purposes, such as contributions to the Linux community or otherwise using UNIX for the benefit of others.  This prohibition extends to derivative work products that are modifications of, or based on, UNIX System V source code or technology.    IBM and certain other UNIX software distributors are violating this prohibition, en masse, as though no prohibition or proprietary restrictions exist at all with respect to the UNIX technology.  As a result of IBM’s wholesale disregard of its contractual and legal obligations to SCO, Linux 2.4.x and the development Linux kernel, 2.5.x, are filled with UNIX source code, derivative works and methods.  As such, Linux 2.4.x and Linux 2.5.x are unauthorized derivatives of UNIX System V… 

 

35.  Therefore, while other major UNIX vendors modified UNIX for their own respective RISC-based computing platforms, SCO developed and licensed the UNIX-based operating system for Intel-based processors for enterprise use that is now known as “SCO OpenServer.” …

 

46.  In creating the thousands of SCO OpenServer Applications, each designed for a specialized function in a vertical industry, software developers wrote software code which specifically made use of the SCO OpenServer shared libraries (hereinafter the “SCO OpenServer Shared Libraries”), and thus the presence of the SCO OpenServer Shared Libraries on a particular system is required in order for these applications to be able to run and function correctly.

 

47.  Linux offers a “SCO emulation module,” originally called “iBCS” and now known as “linux-abi” which enables applications which were originally developed to run on SCO OpenServer to be run on Linux.  However, in order for these applications to function, the SCO OpenServer Shared Libraries must also be copied onto the Linux system.  The SCO OpenServer Shared Libraries are the proprietary and confidential property of SCO.  SCO OpenServer has been licensed to numerous customers subject to restrictions on use that prohibit unauthorized use of any of its software code, including without limitation, the SCO OpenServer Shared Libraries.  SCO does not give permission for copying of the Shared Libraries for use outside OpenServer without payment of separate licensing fees.

Project Monterey

 

55.  As SCO was poised and ready to expand its market and market share for UnixWare targeted to high-performance enterprise customers, IBM approached SCO to jointly develop a 64-bit UNIX-based operating system for a new 64-bit Intel platform.  This joint development effort was widely known as Project Monterey. 

 

56.  Prior to this time, IBM had not developed any expertise to run UNIX on an Intel processor and instead was confined to its Power PC processor.

 

57.  SCO, on the other hand, had over 15 years of expertise in adapting UNIX to Intel based systems.  Moreover, SCO had spent the previous 18 months working closely with Intel to adapt its existing UnixWare product to work on the new 64-bit Intel processor. That project, known as "Gemini-64," was well underway when work on Project Monterey was started.  In furtherance of, and in reliance on, IBM’s commitment to Project Monterey, SCO ceased work on the Gemini-64 Project and expended substantial amounts of money and dedicated a significant portion of SCO's development team to Project Monterey.  Specifically, plaintiff and plaintiff’s predecessor provided IBM engineers with valuable information and trade secrets with respect to architecture, schematics, and design of UnixWare and the UNIX source code for both 32- and 64-bit Intel-based processors.

 

http://66.218.69.11/search/cache?ei=UTF-8&fr=ush1-mail&p=BOIES%2C+SCHILLER+%26+FLEXNER+sco+complaint&u=sco.tuxrocks.com/Docs/IBM/Doc-25.html&w=boies+schiller+flexner+sco+complaint&d=OWxIVDmtNC5s&icp=1&.intl=us

 

The Linux kernel needs support form IBM to support major applications and IBM has a motive to misappropriat[e] the confidential and proprietary information from SCO in Project Monterey:

 

Because IBM has failed to admit or deny these SCO-Caldera accusations, we apply our policy to consider unanswered questions in the light least favorable to the source. Thus, we take SCO's allegations that IBM misappropriated the confidential and proprietary information from SCO in Project Monterey [and] IBM thereafter misused its access to the UNIX Software Code as admitted and true -- unless and until IBM publicly denies these allegations.

 

If Linux had all of the capabilities of AIX, where we could put the AIX code at runtime on top of Linux, then we would.

Right now the Linux kernel does not support all the capabilities of AIX. We've been working on AIX for 20 years. Linux is still young. We're helping Linux kernel up to that level. We understand where the kernel is. We have a lot of people working now as part of the kernel team. At the end of the day, the customer makes the choice, whether we write for AIX or for Linux. We're willing to open source any part of AIX that the Linux community considers valuable. We have open-sourced the journal filesystem, print driver for the Omniprint. AIX is 1.5 million lines of code. If we dump that on the open source community then are people going to understand it?

 

http://216.109.125.130/search/cache?ei=UTF-8&fr=ush1-mail&p=confidential+and+proprietary+information+from+SCO+in+Project+Monterey+&u=www.mozillaquest.com/Linux03/ScoSource-08_Story04.html&w=confidential+proprietary+information+sco+project+monterey&d=e2Y9rDmtMwuV&icp=1&.intl=us

 

Australian who runs the Unix Heritage Society claims:

 

Dr Warren Toomey, now a computer science lecturer at Bond University, said today: "I'd like to point out that SCO (the present SCO Group) probably doesn't have an idea where they got much of their code. The fact that I had to send SCO (the Santa Cruz Organisation or the old SCO) everything up to and including Sys III says an awful lot."

 

He said that even though SCO owned the copyright on Sys III, a few years ago it did not have a copy of the source code. "I was dealing with one of their people at the time, trying to get some code released under a reasonable licence. I sent them the code as a gesture because I knew they did not have a copy," he said with a chuckle…

SCO was unaware of the origins of much of the code and this "explains how they could wheel out the old malloc() code and the BPF (Berkeley Packet Filter) code, not realising that both were now under BSD licences - and in fact they hadn't even written thhe BPF code," Dr Toomey said.

 

He said that there was lots of code which had been developed at the University of New South Wales in the 70s which went to AT&T and was incorporated into UNIX without any copyright notices.

 

"At that time the development that was going on was similar to open source - the only difference was that the developers all had to have copies of the code licensed from AT&T," he said.

 

Dr Toomey, who served 12 years with the Australian Defence Force Academy, an offshoot of the University of New South Wales, before joining Bond University, said he had source code for Unices from the 3rd version of UNIX which came out in 1974 to the present day. "I don't have Sys V code but there are people with licences for that code who are members of the Unix Heritage Society. We can compare code samples any time," he said.

 

He agreed that the codebase of Sys V was a terribly tangled mess. "It is very difficult to trace origins now. There is an awful lot of non-AT&T and non-SCO code in Sys V. There is a lot of BSD code there," he said.

http://www.smh.com.au/articles/2003/09/09/1062902037394.html

 

David Berlind’s, February 18, 2004, article “Is Red Hat the canary in SCO’s coal mine?” suggests all is not well with Red Hat’s case agaist SCO:

 

…Red Hat admits in its 10-Q may not be possible on a timely basis) in combination with Red Hat's failure to offer any indemnification to it's customers tells me that no matter how confident Red Hat CEO Matthew Szulik appears in public, the company is being much more cautious about that confidence with its shareholders and customers.

 

To gauge Red Hat's assessment of my theory regarding the value, or lack thereof, in its software warranty, I checked in with Red Hat spokesperson Leigh Day at LinuxWorld in January 2004. Not surprisingly, Day refuted my assertion that replacement of infringing code falls short of indemnification and spun it in the opposite way. "If you look at what the other companies are doing with indemnification, all they are doing is offering to cover the legal costs," said Day. "Instead, we're saying we're going to solve the problem. Isn't that the most important thing to say? That the platform is protected? We feel that our warranty is a comprehensive solution."

 

But nothing rattles a business like a lawsuit. It's one thing to promise that the software will work. But what good is a guarantee to replace infringing code if that turns out to not be enough to satisfy SCO or the courts? So, I asked Day what happens if SCO sues one of Red Hat's customers. "We can't comment on the hypothetical," Day said. " In talking with customers, they didn't demand indemnification. They just wanted assurances they could continue to use code. The best way to address this need was for us to announce that if a problem comes up, that Red Hat will replace the infringing code at no additional cost, thereby allowing customers to continue with uninterrupted use of the code." Day later summed up Red Hat's position by saying, "We're extremely confident that this is not an issue."

 

But apparently, not confident enough to protect its customers from liability. Am I dreaming, or was that a black dust ball that the canary just coughed up?

 

http://66.218.69.11/search/cache?p=sco+legal+opinion+red+hat+canary&ei=UTF-8&fr=ush1-mail&x=wrt&u=techupdate.zdnet.com/techupdate/stories/main/Red_Hat_the_canary.html&w=sco+legal+opinion+red+hat+canary&d=VZE47DmtNDGS&icp=1&.intl=us

 

On August 2004 in was written in theinquirer.net:

 

A STUDY by a firm offering insurance against litigation will claim this week that a total of 283 software patents could put Linux users at risk of being sued.

 

And of those patents, Microsoft owns 27, claims Open Source Risk Management in a report on its web site.

 

While around a third of the patents belong to Linux-friendly vendors, and 27 by the Vole, the rest belong to companies who might see the chance of a quick buck through big Linux users.

 

The report reminds us that HP suits said in 2002 that the Vole "intends to sue companies shipping Open Source products that potentially violate their patents".

 

http://216.109.125.130/search/cache?ei=UTF-8&p=27+Microsoft+patents+linux&fr=ush1-mail&u=www.theinquirer.net/%3Farticle%3D17586&w=27+microsoft+patents+linux&d=DhLS9mP9NSas&icp=1&.intl=us

 

The Open Source Risk Management (OSRM), with a possible conflict of interest due to it selling patent insurance’s opinion argues that the Linux Kernel may infringe on as many as 283 patents:

 

A recent report commissioned by Open Source Risk Management (OSRM) examined the Linux kernel for patent violations that patent holders could cite in lawsuits against distributors. Unsurprisingly, the report found 283 patents that might come into play.

 

Reactions to the report varied greatly. This was apparently the first broad study of its type, the first such study to clarify the risks that software patents pose to open development. Many longtime developers always suspected that this was the case. Other people took offense, as if the report suggested a flaw in the development of the kernel; suggested reasons not to use Linux or free software in general; or provided fear, uncertainty, and doubt in an attempt to sell OSRM's legal insurance.

 

Dan Ravicher is the patent attorney who conducted the study. By day, Ravicher is the executive director of the non-profit Public Patent Foundation, working to reform the patent system. He also represents the Free Software Foundation on a pro-bono basis…

 

The most important finding is that Linux infringes on zero patents that have survived reviews in court. The 283 patents that the kernel could infringe have all gone unchallenged so far. There is a chance that a court could find the patents invalid -- so the conclusion that there are 283 ways in which patent holders could Bring Suit Against Kernel Developers, Users, And Distributors Is Flawed…

 

Ideally, non-profit groups such as the EFF and Ravicher's own Public Patent Foundation will succeed in their quest to reform software patents. Until that happens, though, knowing the risks involved can only help people make better choices.

 

http://216.109.125.130/search/cache?ei=UTF-8&fr=ush1-mail&p=OSRM+Public+Patent+linux&u=www.linuxdevcenter.com/pub/a/linux/2004/08/06/kernel_patent_risks.html&w=osrm+public+patent+linux&d=LPrB5zmtNDMw&icp=1&.intl=us

 

Linux Kernel Code Seems to be Copied was the headline of internetnews.com story dated August 7, 2003 with the following enclosed:

 

"Our review of source code and documents appears supportive of SCO claims, though we are not legal experts and IP matters are not always transparent," Deutsche Bank Securities analyst Brian Skiba said in a research note Thursday after visiting SCO's headquarters in Lindon, Utah, Wednesday.

 

"A direct and near-exact duplicate of source code appears between the Linux 2.4 kernel and Unix System V kernel in routines shown to us."

 

http://www.internetnews.com/dev-news/article.php/2245911

 

Cloning of Unix conventions is common:

 

By the end of the 1970s, there were already Unix clones like Idris and Coherent, and of course they also had to enumerate the set of signals. Not surprisingly, they followed the same numbering convention as Unix, as is shown by this file from Idris in 1978, where nearly all of the names and numbers are derived from 6th Edition UNIX.

 

This sort of code "cloning'' is exactly the thing that seems to make SCO see red. However, at the time AT&T asked Dennis Ritchie (one of the developers of Unix) to visit Coherent's makers [first link] and determine if the Mark Williams Company relied on Unix code when they wrote Coherent, Dennis determined that he "couldn't find anything that was copied'', and "what they generated was [...] reproducible from the [Unix] manual''. It must be remembered that the manual pages for Unix were published and publicly available; in fact, each new version of Unix was known by the edition of the printed manuals.

 

Dennis goes on to indicate that AT&T "backed off, possibly after other thinking and investigation [... and] so far as I know, after that MWC and Coherent were free to offer their system and allow it to succeed or fail in the market''. This decision and others like it, together with the publicly available enumeration of the signal values, allowed the Unix signal numbers to be used in many Unix clones and non-Unix systems such as:

 

Minix 1.5.10

 

Ultrix

 

Microsoft's Quick C Compiler

 

The list is probably endless; hyperlinks to other examples of the Unix numbering in non-Unix systems can be posted as replies to this article…

 

We've digressed from the topic of "What's in signal.h?'' to observing that the contents of the original Unix file was copied with AT&T's knowledge as early as 1978…

 

I think it's pretty obvious that Linus did not have access to nor use System V source code to generate his 0.01 signal.h file…

 

AT&T did not put copyright notices on the "ABI files'' from 3rd Edition UNIX in 1973 up to and including the first release of System V in 1983.

 

http://216.109.125.130/search/cache?ei=UTF-8&fr=ush1-mail&p=linux+copying+unix+kernel+abi&u=gl.scofacts.org/gl-2004022923000172.html&w=linux+copying+unix+kernel+abi&d=JO0kFzmtNFT1&icp=1&.intl=us

 

Anonymous (Could this be Bill Joy?) on groklaw.net writes:

 

Authored by: Anonymous on Wednesday, February 18 2004 @ 07:57 PM EST

 

If I were an IBM lawyer, I would steadfastly pressure SCOG to identify with specificity all occurrences of AT&T source files being copied into Linux distributions. Ignore IBM’s own source files.

 

Why? This would defeat SCOG’s plan with a truth any jury could comprehend.

 

All of SCOG's public behavior both inside and out of court has been a diversion. I would not label it a smokescreen; it is far more complex, like the shell game with a pea or Three Card Monte, and intended to divert you from taking the optimum action. I doubt that SCOG intentionally says anything useful in public or in court, but IBM can force the truth from SCOG.

 

Simply do what is best for the business of software and march forward ignoring Daryl’s antagonistic posing.

 

Prove for the legal record that:

1) SCOG knows there is NO AT&T source code in Linux.

2) the secret, private deal among USL, BSDi, and Novell has been obviated by subsequent events like the free licensing of V32 and all earlier versions by Cadera. It is no longer necessary.

3) SCOG has been deliberately misrepresenting API files, freely distributed and updated since the mid-1980s, as part of the hardware ABI.

4) SCOG has no trademark in UNIX, trade secrets in AT&T UNIX, or patents in AT&T UNIX. None.

5) SCOG has very limited copyrights in AT&T System III because AT&T previously gave up many copyrights, Novell retains all remaining System V copyrights, and Caldera permanently, freely licensed V32 and earlier versions.

So, little remains.

6) SCOG has no contractual rights, based on the UNIX licenses, to independently developed software like file systems or virtual memory management systems. UNIX licensees are free to go it alone.

7) No single organization could own all the intellectual property rights existent in any of UNIX’s many versions.

 

Daryl is going down, so look beyond his reign of terror. Look forward to Microsoft and the traditional UNIX cabal who are guarding their turf. They won their turf in hard fought battles but now must change in order to compete. Change is incompatible with protecting turf.

 

The open software community is thriving because more and more people notice their predictable, repeatable project successes. Also, more people trust that these projects truly respect intellectual property rights because of their open procedures. Educators, students, engineers, scientists, system admins, network admins, CIOs, CEOs, and more choose OSS because it is right for them.

 

The SCOG is part of history. Continue taking the right legal actions to pave the road ahead from cooperation to commerce in a global information society. No group would long prosper that deemed it prudent to hoard its IP in isolation. The relentless pressure of competition combined with dynamically changing technology favors sharing over hoarding, doesn’t it?

http://www.groklaw.net/article.php?story=20040215015800694

 

According wikipedia.org’s analysis of SCO_v._IBM_Linux_lawsuit:

 

• Code appears to be 1) historical UNIX code (ate_utils.c atealloc) and 2) of BSD origin (BPF: Berkeley Packet Filter by Jay Schulist)
• The code (atealloc) has been in the IA64 version of Linux for a short period of time. It is no longer in Linux after having been removed on July 4th, 2003, since much better alternatives existed. See This Rebuttal by Greg Lehey
• UNIX creator Dennis Ritchie confirms that either he or Ken Thompson wrote this (atealloc) code, which is released under the BSD licence: see Ancient UNIX Released Under What Terms? and SCO Slideshow
• This code therefore appears to be perfectly legally incorporated into Linux, as originally believed by Linux advocates

 

• It is claimed that SCO removed original license text from UNIX source, allegedly violating the BSD licence; see Embarrassing Dispatches From The SCO Front

http://en.wikipedia.org/wiki/SCO_v._IBM_Linux_lawsuit

 

Even conspiracy theories exist regarding SCO’s litigation:

 

Then there's the conspiracy theory: Microsoft is funding them to break up Linux. I have seen claims that Microsoft is the second-largest shareholder of SCO, so it's not completely impossible, but I'd like to see some good evidence before coming to that conclusion.

• Update 18 May 2003: The conspiracy theory has gained new momentum with an article in the Wall Street Journal in which the headline reads:

Microsoft agreed to buy rights to Unix technology from SCO, a boost to SCO's efforts to get royalties for a predecessor to Linux.

But is the lawsuit justified?

That's one question that's easy to answer: No, in no way whatsoever. If it were, they should at least have made specific accusations as to what IBM is supposed to have done. Having worked on Linux for IBM, I can state categorically that the separation between AIX and Linux is complete. Nearly all of the people working on the Linux kernel have no access to AIX source code. It's theoretically possible that some people do have such access, though I know of nobody, but IBM has guidelines for that case, just to be on the safe side: don't read AIX code and write Linux code in the same place. Read the code, go elsewhere and write. Even this, though, would hardly be useful: AIX is UNIX, Linux is Linux. The kernels have such completely different structures that any code import would be a waste of time: it's easier to write it from scratch. 

What about suing Apple Computer? MacOS X uses a lot of BSD code. That would have made more sense, and would have had a better effect on the stock price. I don't know why they didn't.

 

            On 18 November, Darl McBride stated in a news conference that he would be in planning litigation against the BSDs next year. Does anybody believe that? If they really did pursue litigation, it would be over before it started: the settlement of 1994 has been overtaken by a unilateral decision of SCO (then called Caldera) in January 2002 to release all the code under an open source license.   

 

http://www.lemis.com/grog/sco.html

 

The article by theinquirer.net called By Egan Orion dated:  May 2003 “The SCO lawsuit as dark comedy” claims:

SCO's ridiculous lawsuit against IBM would be seen as the stuff of high comedy, if there weren't some important issues at stake: things like the integrity of the GNU software toolchain and the Linux kernel itself, the strength of the GPL license in protecting most Free/Open Source (FOSS) software from proprietary attacks, and indeed the viability of all Free/Open Source software as alternatives to closed-source enslavement.

Based upon its public statements, one might wonder if SCO's executives are: (a) uninformed about their own software, (b) incompetent to assess their own legal claims, (c) absent-mindedly forgetting what they've already said, when it suits the occasion, or (d) some or all of the above, depending on who's talking that day.

On the one hand, we have SCO Group's CEO Darl McBride quoted in this May 1st article at C|Net saying: "We're finding... cases where there is line-by-line code in the Linux kernel that is matching up to our UnixWare code." Also, "We're finding code that looks likes it's been obfuscated to make it look like it wasn't UnixWare code -- but it was." He says there's infringing code in the Linux kernel!

This is curious, since just a few days earlier, SCO Group VP Chris Sontag said something entirely different in an interview with MozillaQuest: "We're not talking about the Linux kernel that Linus and others have helped develop. We're talking about what's on the periphery of the Linux kernel."

http://www.theinquirer.net/default.aspx?article=9367

 

The SCO Group is not doing well financially partly as a result of the litigation as stated in “SCO Litigation Takes Its Toll on Bottom Line” By Peter Galli on August 9, 2004 in eweek.com:

 

The decline in customer interest is evident in SCO's second-quarter financial results. The company's SCOsource division's revenues plummeted in the second quarter to $11,000—a drop from the division's revenues of $8.25 million for the same period last year.

 

http://www.eweek.com/article2/0,1759,1633439,00.asp?kc=EWRSS03119TX1K0000594

 

Note to Editor: It would be nice to include a chart similar to this, or this cart in the book:

http://lwn.net/Articles/75129/

http://finance.yahoo.com/q/bc?s=SCOX&t=3m&c=

 

The following comments may suggest primary motivations of Bill Joy’s from his NerdTV interview on government, energy, peril, and opensource:

 

I don't think--the government can lead but ultimately we need new ideas to solve these problems as well. A less backwards looking, less distractive strategy from the government would help. But if that's not forthcoming I think there's still an opportunity to make a lot of money by doing better. So we can hopefully achieve and make progress in that direction without waiting for political change…

 

We're doing an experiment without precedent. There's an article in the paper today about how the oceans are getting more acidic. Just kind of break down the shells of the reefs. It's a non-controlled experiment. It'd be better not to do it-The economic forces are driving us in that way so it's not necessarily practical to just wish it to change because people will do pretty much what they want to do. So the best thing to do is find some profitable way to alter the course. If you can find a way to not use so much energy or to make the energy more efficiently or find an alternative source of energy that doesn't produce so much CO2 that would be a very positive thing. And so we looking at an invest in areas like solar and fuel cells, other innovative new technologies that might address this issue...

 

I'm looking at the energy and materials area because those are clearly pressing problems…In this case every energy and resource efficiency we get brings an amenity so it makes things better… I'm looking at lot of IT opportunities but you have to remember that energy and materials are also related...  And so it's an opportunity to study energy efficiency looking at all the kinds of technology that are available…

 

I think we're more aware of the peril after 9/11 before which if there was danger we'd say well people won't do X because they haven't done X which is not a very good defense. For example in the area of bio-terrorism the standard defense was nobody's done it so no one will probably do it. That was not a good, that's not a good approach. But we have some challenges ahead but we also have opportunity; danger-opportunity two halves of the same thing…

 

If I couldn't be an investor I'd probably do a software company because I'm still a pretty good programmer I just haven't been doing it. So I'd write some software for either science or the web. I don't know which. And science probably the life sciences because that's where I think is an enormous opportunity for new software to make a difference… I saw on an energy presentation in the last few weeks where somebody was saying well here's the timeline for this technology, the first prototype was in 1896 and then there was some more work in 1950 and then in 1975 and in 1993. And the reason is that a lot of these things are ideas with roots in chemistry, physics or mathematics where the material science didn't exist. And that's really what has changed is our ability to engineer some of the materials that we needed to make these old ideas practical. So we expect to see longer historical stories like that…

 

We did Open Source back then a long time before even before we knew what it was called. But the idea was that people ought to be able to build on each other's work. And that's true in academia where you publish your papers and people can learn about what you've done so they can do better. That was the idea of the Open Source. It's become more than that to some people and has a lot of flavors now. It's a whole big movement but the basic idea is that people can stand on the shoulders of each other instead of on each other's toes.

 

Futhermore, notice wanna, gonna, gotta is often used by Bill Joy, (also used by the hacker in the context of “wanna start a war” in the Mydoom, worm) in the Nerd TV interview:

 

They wanna do good…   

 

And you don't wanna group that's a bunch of buffalo those are not farm animals, right…

 

If you're goofing off you lose the right but if you wanna go you should get to go…

 

So we gotta be careful...

 

You're formulating the next thing I'm gonna say…

 

Well I hope that there's gonna be some payback out of the boat project in understanding integration of energy technologies and that's part of the payback…

 

You try to steer them to something within their big circle because if you try to take them too far out of the circle it's just not gonna work...

 

http://www.pbs.org/cringely/nerdtv/transcripts/003.html

 

The motive for a distributed denial of service (DDOS) attack on both the Microsoft.com and SCO.com done by the MyDoom worm (worms stands for Write only read many), which blocks access to their websites was likely done as retaliation and intimidation over litigation about AT&T operating system code that is allegedly part of Linux code; both Microsoft.com and SCO.com support the litigation about the Linux Code which allegedly contains UNIX code, partly directly or through investments.  

It would be interesting, if Microsoft needs ownership of the AT&T code and/or if they could have some AT&T Unix code in Microsoft?  Therefore, could Microsoft also need to own the rights to AT&T Unix code?  If not, they likely wouldn’t do a distributed denial of service attack on their own website. 

Xenix was Microsoft’s first operating system was a renamed AT&T version of Unix:

The first operating system the company publicly released was a variant of Unix in 1980. Acquired from AT&T through a distribution license, Microsoft dubbed it Xenix and hired Santa Cruz Operation in order to port/adapt the operating system to several platforms.[

http://66.218.69.11/search/cache?ei=UTF-8&p=tim+paterson+unix+copyright+violations+&fr=ush1-mail&u=en.wikipedia.org/wiki/Microsoft&w=tim+paterson+unix+copyright+violations&d=ZyGCcGP9NOtB&icp=1&.intl=us

The Quick and Dirty Operating System was allegedly written from scratch according to patersontech.com:

Over the months from April through July, 1980, Paterson was able to spend about half his time working on QDOS, the Quick and Dirty Operating System. It began shipping with the 8086 computer system in August. SCP approached Microsoft about adapting their software to run under DOS, who said it was possible - for a price.

Shortly afterward, Microsoft came back to SCP with a different proposal. Microsoft offered to market DOS for SCP, and they already had the first customer lined up, although they couldn't reveal who it was. They made a deal: Microsoft would pay SCP $10,000 for the right to market DOS, and $15,000 for each OEM customer. The per-customer figure was half of what SCP figured was the going rate for a flat-fee license, which was a common arrangement at the time. So SCP came away with $25,000 in cash, and Microsoft had obtained an operating system for their secret customer, IBM.

Microsoft had been with working with IBM on their personal computer project since the outset. Microsoft originally sent IBM to Digital Research for the operating system, but IBM felt rebuffed when Digital Research would not sign a non-disclosure agreement. So Microsoft offered them an alternative by striking the deal with SCP for DOS.

In July of 1981, the month before the IBM Personal Computer was announced, Microsoft offered to buy DOS (now called 86-DOS) from SCP instead of continuing to pay a $15,000 per-customer royalty. This would give Microsoft flexibility in pricing, and return SCP back to its roots as a hardware company. Microsoft paid $50,000, plus a license for SCP to include DOS with their computer systems. Five years later, Microsoft and a struggling SCP fought a legal battle over the specifics of that DOS license; in the end, it was settled by Microsoft buying the license back for a reported $925,000. Thus Microsoft's payments to SCP for DOS ended up totaling an even $1,000,000.

http://www.patersontech.com/Dos/Encyclo.aspx

MS-DOS is modeled on UNIX:

Many people have remarked upon how much the directory structure of UNIX looks like that of MS-DOS, and wonder if UNIX copied it. In fact, the UNIX directory structure was invented in 1970 by Ken Thompson and another researcher at AT&T Bell Laboratories. Bill Gates wanted to dominate the world so, in the 1980s, Microsoft was working on its own version of UNIX. They licensed it from AT&T and renamed it Xenix (since AT&T then wouldn't let anybody use the name UNIX). Now the folk at the MS Campus in Redmond are pretty collegial, so it wasn't long before the folks in the Xenix project and the folks working on DOS were drinking together. The DOS folks needed a way to get beyond the 15 "user areas" that MS-DOS had inherited from CP/M-86 (see DOS history above). The Xenix folk were bragging about how great UNIX-style directories were. So they DOS folk looked, and became believers, and borrowed the ideas and the syntax, but not the implementation. UNIX's chdir/cd, mkdir (shortened to md), and directory tree notions were grafted onto DOS's drive letters, and the slash (/) converted to a backwards slash (\) in a move that has driven "bilingual" people crazy ever since (it wasn't for that purpose; MS had already used "/" as an option delimiter where UNIX used the "-", and felt they couldn't change that for fear of breaking backwards compatibity).

Once Microsoft got the idea that they could write Windows NT and stop paying royalties to AT&T, the Xenix project was cancelled. However, it was taken over by a smaller company that had begun as its largest dealer. The Santa Cruz Operation, later shorted to SCO, continued to sell UNIX software and systems until around 2001, when it was acquired by Caldera...

Here are just a few of the major "innovations" in Windows '95, and where M$ "borrowed" them from:

Innovation	Actual Origin
Icons directly on desktop	Xerox Alto (1981); Macintosh (1982?)
Recycle Bin	Macintosh Trash Can (1984?)
Start Menu	Macintosh Apple Menu (1982?)
Settings->Control Panels	Macintosh Control Panels
Long File Names	Macintosh 1982?; UNIX 1979.
Task Bar	HP Vue
Right Button Menus	Sun SunView, Sun/ATT OPEN LOOK, ...
DCOM	Xerox Alto; RPC (Sun&HP had RPC mechanisms by the early 1980's)
Internetworking	Xerox Alto; UNIX (4.2BSD, 1982, included TCP/IP)
Network file sharing	Many, many distributed filesystem schemes

http://216.109.125.130/search/cache?ei=UTF-8&p=tim+paterson+Xenix+&fr=ush1-mail&u=www.darwinsys.com/history/mslies.html&w=tim+paterson+xenix&d=YppC32P9NDwk&icp=1&.intl=us

QDOS looked like CP/M states AdamBa in a posting at March 2, 2005 11:14 AM on proudlyserving.com:

Microsoft legally acquired QDOS; the issue is whether Paterson had earlier "ripped off" CP/M when writing QDOS. It's not clear what exactly "rip-off" means; there's no doubt that QDOS looked like CP/M, because most command-line-based OSes back then looked the same (and still do; Monad on the surface looks a lot like CP/M, QDOS, PC-/MS-DOS, and any Unix shell). The exact story of how IBM came to use a Microsoft OS instead of CP/M on its original PC, and where that Microsoft OS came from, has been told many times in many ways. I know Kildall felt that Gates violated a gentleman's agreement that Microsoft would sell languages and Digital Research would sell operating systems; rumors about the origins of QDOS just add fuel to the fire. Kildall is dead, Don Estridge is dead, Sir Bill ain't really talking, and the "truth" may never be known.

http://66.218.69.11/search/cache?ei=UTF-8&p=paterson+microsoft+ripoff+&fr=ush1-mail&u=www.proudlyserving.com/archives/2005/03/origins_of_msdo.html&w=paterson+microsoft+ripoff&d=aZdD_GP9NPNG&icp=1&.intl=us

However, Paterson won his case against Harold Evans’ alleging that Paterson stole Gary Kildall's CP/M operating system: 

In a recent book, writer Harold Evans described the creation of QDOS as a "rip off" of Gary Kildall's CP/M. Depending on who you talk to, many people would probably agree. However, Tim Paterson, the creator of QDOS is apparently so upset over this slight in describing something that happened 25 years ago that he's suing Harold Evans and the book's publisher. While it does suck to have your work pooh-poohed as being a mere copy, isn't it about time to look at this in perspective. Paterson won.

http://216.109.125.130/search/cache?ei=UTF-8&p=paterson+microsoft+ripoff+&fr=ush1-mail&u=techdirt.com/articles/20050302/167204_F.shtml&w=paterson+microsoft+ripoff&d=cgPw-GP9NNn1&icp=1&.intl=us

Windows has too many lines of code according to jmusheneaux.com: 

§         2001 MS Windows XP - 40 million to 45 million to 50 million

§        

§         ---Note 1: Security - 50 million lines of codee mean it'll never be secure enough.

§         ---Note 1a: Security - Fixing security in Windows is an extremely tough problem. Microsoft has, what, 50+ million lines of code? It's a very difficult problem to test every piece of code when it's put together as a system.

§         ---Note 2: Microsoft Leaked Code (Feb, 2004) - "Initially, Microsoft told reporters the 13.5 million lines of leaked code equaled 15 percent of the entire source code. If true, this would mean the operating system is made of some 90 million lines of code. That would contradict Microsoft statements made at the release of Windows 2000 that said the OS was made up of between 35 and 38 million lines of code. If the number is 38 million, the amount of leaked source code is more like 33 percent".

§         ---Note 3: Wintel Comparison ** Solaris OS- 7 to 8 million ** Linux OS- 5 million lines.

§         ---Note 4: Macintosh Comparison ** "Windows 2000 Server has more than 30 million lines of code. By comparison, Apple's Mac OS X Server has approximately 2.5 million lines of code".

§         ---Note 5: Microsoft has claimed that it spent 500 people-years to make Windows 2000 reliable. Windows 2000 - 30 million lines of code and has about 65,000 known bugs.

§         ---Note 6: Fixing bugs at Microsoft - According to this article, "Buildiing clean code is getting more daunting, especially for Microsoft. The Windows operating system has 50 million lines of code (a line averages 60 characters) and grows 20% with every release. It's put together by 7,200 people, comes in 34 languages and has to support 190,000 devices--different models of digital cameras, printers, handheld's and so on.

§         ---Note 7: Today's code is built atop yesterday's code, because everybody wants compatibility with old apps.

§         ---Note 8: 1999 (Dvorak, PC Magazine) "With a base of 50 to 60 million lines of code that obviously nobody has a grip on, there has to be an immense feeling of panic within the company.... I've talked to many ex-Microsoft folk who all tell me that nobody has a handle on Windows' code. It's completely out of control -- a hodgepodge of objects and subsystems nobody fully understands." and "Think about that quote for a second. As we enter the year 2000, the last year of the 20th Century, we have as our prospect the entire computing industry of Western Civilization ready to stake its future on 60 million lines of hodgepodge code that Microsoft desperately hopes will cancel Unix for good"

http://www.jmusheneaux.com/index1b.htm#2