SCO Case: Misguided but Over
15/04/10
The SCO litigation with Novell is finally over: a jury recently decided that SCO does not own the copyright in Unix. The decision was not a surprise, given the district court’s earlier decision granting a summary judgement reaching the same conclusion. However, a decision in favor of SCO would have reopened the issue of whether Linux includes code from UNIX. This decision does not deal with the suits against IBM and other UNIX licensees (which are based on contract), but it prevents SCO from suing third parties who use Linux but are not UNIX licensees.
This decision provides the opportunity to review the SCO litigation and its mistakes: the SCO litigation is likely to become an example of how not to enforce intellectual property rights. Ironically, the principals at SCO had purchased rights in another software program and had successfully obtained a significant settlement in litigation. SCO made the following errors:
1. SCO did not have ownership of the necessary intellectual property rights: the agreement between SCO and Novell was limited to contractual rights. These contractual rights were very limited and Novell prohibited SCO from “amend[ing], waiv[ing] or modify[ing]” any rights under the Asset Purchase Agreement (”APA”). Novell also retained the right to instruct SCO to amend, supplement, modify or waive the rights in the APA and if SCO does not comply, Novell can exercise such rights directly.
2. SCO had not done sufficient due diligence on its rights and was requesting Novell to transfer the rights even as SCO was suing IBM. In fact, the agreement providing SCO with the potential right to own the copyrights in UNIX software (the famous Amendment 2) was not discovered until months after the litigation by SCO had commenced.
3. SCO sued the wrong party: IBM. IBM has one of the highest investments in Linux and has millions of dollars to spend on defending Linux and thousands of patents to supplement this defense. This strategy was very odd.
As I have mentioned in the past, the SCO debacle will be remembered for many years for poor planning and poor execution.
When Microsoft contributed drivers to Linux to GPLv2, my reaction (and the general reaction in the community) was that “hell had frozen over” and to bring out the skates http://www.microsoft.com/presspass/features/2009/Jul09/07-20LinuxQA.mspx. Several recent reports suggest that these contributions were not voluntary and Microsoft had included GPLv2 licensed code in these drivers http://linux-network-plumber.blogspot.com/2009/07/congratulations-microsoft.html (Steve Hemminger of Vyatta) and http://www.kroah.com/log/linux/microsoft-linux-hyper-v-drivers.html (Greg Kroah-Hartman of Novell).
I view this contribution as valuable even if legal concerns drove it. I think that Microsoft acted as a responsible member of the community which is the behavior that we want to encourage. They could have simply rewritten the code to remove the open source components. I am under no illusion that Microsoft has suddenly turned into a complete supporter of open source (and for clarity, neither I nor my law firm represents them). However, Microsoft’s engagement with the open source community is going to be a gradual one and will have fits and starts. Microsoft is still fundamentally based on a proprietary model and has that mind set. They can change and should be encouraged to change. I hope that these revelations will not result in an attack on Microsoft for not being “truly” committed to the open source community. We should, instead, encourage them to continue to be involved.
This situation is a warning to companies that they need to have an open source policy and a process for managing their work with the open source software. See my earlier post, http://lawandlifesiliconvalley.com/blog/?p=107.
In fact, I think that the Microsoft press announcement bears further scrutiny, In addition to the announcement of the contribution, Sam Ramji mentions several ways in which Microsoft is implementing open source in their business strategy. This increased use of open source by Microsoft should be encouraged.