It's unusual. It could draw some focus to the fact that the USPTO is going to invest itself in the validity of claims. It's hard since we don't know why they decided to do it. It could certainly draw some hope
With regard to those networks that are using FAT without authorization, it's not clear what the license fee would be. It's not clear Microsoft could identify them and come after them, and that they have the right to collect royalties. My guess is that they'll pick some smaller companies to collect from that don't have the resources to pursue them in court to set a precedent. Then the question is if the open source community rallies, which is possible. Has the entire SCO situation shed any light on problems with the open source development process with regard to patents, IP and copyrights?
The world is not privy to what the parties are exchanging. Confidential agreements have been signed and they're not disclosing what they are receiving from the other side. In terms of actual facts, there are not a lot of people walking around with them. It helps to have the facts to evaluate the propriety of a software patent.
SCO certainly has laid a foundation for raising questions. This is not the first time we have heard about the strengths and weaknesses of granting business process patents. It's so amorphous. As time goes by, it's difficult to disprove the validity of a patent.
We don't have a lot of facts from SCO to come to a further assessment. The Free Software Foundation's stance is that software should be a free science and not patented. Is that a realistic stance?
The question, I think, is: Are the inventors' or creators' submissions truly unique and not based on prior art?
It's a different analysis. In the context of software copyrights, how much of a project or engineering is used to create or compile what is being submitted in a copyright application. Is it comprised of common routines and is what done truly different? You can question the policy. The question is whether the law and policy are being properly applied. Should enterprises be forming in-house advisory committees on their open source use? These committees evaluate where code contributions come from internally, what open source software is being used in-house and establishes a policy on open source use.
As a general risk management tool, this is a good idea depending on the nature, size and complexity of the organization. Certainly, establishing open source use policies and appropriate internal monitoring processes are a good idea and should be utilized to the extent possible -- if for no other reason than some insurers may see it is a loss mitigation process that might lower premiums.
Such committees can be seen as discouraging to those who want to use more open source tools because these committees would add a layer of complication and resource utilization that might be available for other things in the proprietary software world. In my view, the analysis is part practical and part legal.
Will it be easier and more efficient for the organization to control the enhancements to the software on which it relies than to experience the upgrade system in the proprietary world? If the answer is yes, the incentives from using open source will outweigh the resource and other concerns that may arise in connection with the policies and processes that you mention.
SearchEnterpriseLinux.com will be exhibiting at LinuxWorld in San Francisco in Booth #589