Open Source vs. Intellectual Property Law

Q (Murakami):
I have a complaint about the current discussion on Open Source in Japan. The argument tends to center around the issue of "which is cheaper" and "which is safer", which in my view is not essential. The Japanese government should create more discussion on the developer side rather than the consumer side, because speaking from the consumer perspective does not contribute to strengthening the currently weak community that could potentially contribute to the Open Source debate. The Japanese education system is also contributing to the weakening of this community, as Japanese universities do not have an environment conducive to discussing Open Source. Programmers only start debating about Open Source after they join a software company.

I see two problems with the promotion of Open Source. One is a legal problem and the other is a human resource/training problem.

From a legal perspective, the first is the GPL problem. The lack of clarity in the interpretation of its provisions led to confusion. Although I see no problem with the concept of GPL and BSD licensing, we may need a GPL in Japanese text, and in a Japanese style.

Secondly, there is the patent issue. Patentability of software itself is not a problem, but less openness regarding the documentation of patents leads to difficulties in identifying prior art. The complexity of this issue also leads to the likelihood of different judges arriving at different conclusions and judgments. This, however, is not a problem that is limited to software but applies to the patent field in general. There is a need to rethink the entire patent framework.

On the human resource/training issue, I would like to point out that it is dangerous to depend on software developed by a single company. There is, however, a comparable risk in securing assets if you depend on Open Source software, as there is no guarantee of maintenance. We should therefore pursue both options and not rule out one or the other. Many users are concerned about usability and maintenance. Individual cases should be treated individually, and government agencies should obtain the appropriate knowledge to judge whether to opt for Open Source or for commercialized software.

A (Perens):
On the issue of developing an Open Source community in Japan, I have no idea about the numbers participating in Open Source development in Japan, but it does not make sense to count the programmers that are involved in Open Source. Major Open Source projects do have Japanese participation, including Linux and Apache. There is also a cultural issue. There needs to be a leader of opinion who can talk both to businesses and within the community. In Japan, at the moment, those people are considered nerds. In universities, Open Source codes are the only available source codes which you can use and modify without people complaining about it.

How to get people to work on Open Source? Well, people go to where the money is. Maintenance of Open Source software is paid for directly and not reflected in the cost of software.

On GPL, it is true that there was much debate about the vagueness of it, but the debate died down when IBM announced that it would place its destiny with Linux. People thought that if IBM lawyers say GPL will not eat their intellectual property, then it must be OK, contrary to what Bill Gates claims. I agree that Japanese Open Source licenses need official Japanese translation, and I admit that GPLs are hard to understand.

On the patent issue, there is much that can be done to improve the quality of patents. In the U.S., an average patent examiner spends two and a half hours on a single patent, which is not enough to conduct research on prior art, and the examiners are evaluated on the number of patents they approve. The patent applicability is determined by the courts, not by the patent examiner. It costs millions of dollars to prosecute or defend a patent, and the penalty is millions of dollars; so most people will just pay the patent holder for the licenses, regardless of the merits of the case. Victims are those who cannot afford to go to court. Those who can least afford to, are the Open Source developers.

It is a good thing to determine whether or not to use Open Source case by case. Governments should concentrate on making a framework that makes that determination fair, based on competition of all merits of the software, including the intellectual property aspect.

Q (Ikeda):
Could I have more insights on the SCO case?

A (Perens):
SCO does not intend to go to court because their case against IBM is too weak. Yet, they have been extremely successful as their stock rose from 60 cents to $10. The main investors of SCO can now sell the stock. SCO will go to court and they will lose, settle or fold, and people who are left holding stocks will lose. Then, those people will complaint to the SEC, but the SEC will conclude that it cannot prove that the SCO people knew that they would lose, thus the investors who sold their stocks will walk away with their money.

What are the merits of the SCO case? We recently got a better look at the evidence. SCO made public some of their complaints. One of them is with regard to a piece of Sequent software called "Remote Copy Update," a remote processor locking software which makes sure that two CPUs are not writing the same information at once. It attributes low software overhead to reading data, and a much higher overhead to writing data, and it turns out to be faster. Sequent wrote this software, patented it and contributed it to the Monterey Partnership. It is in a derived work of SCO Unix in one fork, but not in the other forks, and any subsequent work of IBM were not derivatives of this SCO software. SCO is attempting to broaden the definition by saying, "Once you share a trade secret with us, once you mix code with ours, it is our derivative work." The judge will probably not take them very seriously. There is another piece of code in the scheduler of Linux that they showed is the same code as in SCO Unix for 150 lines or so. It turns out that the person who wrote the code was an SCO employer. There is a larger body of codes for which comments are very similar between the Unix and Linux version, but the actual implementation is different. Sometimes the subroutine names and functions are similar but the implementation is different. We do not know enough about where this came from, but my suspicion is that the comments originate in something like Tannenbaum's work on TCP/IP or a version of BSD Unix which got copied to both ATT Unix and Linux, or copied from Linux into SCO Unix. The interesting thing is that it is mostly a trade secret case, and no one has ever won a trade secret case like this.

So why is David Boies working on this case? Those lawyers will take on cases that they know they cannot win, but will get as much as they can for you without actually going to court. Boies values publicity and is getting it. They are doing what is called a fiduciary responsibility, making money for their stockholders. They are doing it by lying about Linux.

The other thing is the Microsoft involvement. Who profits from this? IBM knows that SCO cannot get an injunction. So Microsoft profits from this, and that is why Microsoft was the first one to buy this software license from SCO. Microsoft said, "Strike fear and uncertainty about Linux and we will give you a million dollars, and we will help your stock go up." Furthermore, Microsoft could be raising that stock price by buying some too. Another corporate licensor, although this is not certain, could be HP (The Welcome Reception of the SCO Forum was sponsored by HP.)

This is indeed an interesting case. From a legal point of view, most lawyers who are not involved with the case claim that it is very weak. Will the Linux guys have to pay damages? In the case of Red Hat, Turbo and Susa, did they knowledgeably infringe? They didn't, so they probably will have to pay neither punitive nor simple damages. They will just need to remove the infringing codes.

What's left with SCO is the management of Caldera, minus the software developer. Caldera fired its own software developers and they are not supporting Linux. The value of that company is in the old Unix intellectual property, and even then, they licensed a lot of the old Unix under BSD and cannot withdraw that license. Their product is outstripped by Linux. There is no substantial value in that company.