Email:
Password: [?] 
  Register with the DACS
Site Search: Advanced Search Search: Bibliographic Database(SEBD)     Lifecycle Database(SLED)    DoD Acronyms 
DACS Home Advertising Submitting Articles Archives About Us Suggest A Link
Rate this page's content:
  poor
excellent

Software and Intellectual Property Rights

by Robert B.K. Dewar, AdaCore

In this article, we will examine the issue of commercial distribution and use of software. The first thing to be said is that the title of this article is confusing and inappropriate. We use the term “Intellectual Property Rights” because it is so familiar, but we don’t like this term, especially not if we are talking about software. Why not? Because the traditional tools for protecting these so-called rights— copyrights, patents, licenses, and trademarks—are means to an end, not an end in themselves.

Society’s interest is in promoting innovation and progress. In the U.S. this is enshrined in the constitution very explicitly: “Congress shall have the power to promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries”. For producers and consumers of software, the issue is how to ensure that this innovation can be assured. For a company producing innovative software, a business model is needed which ensures that software production can generate sufficient revenue to pay top quality engineers and fund continuing development. Development of commercial software is an expensive proposition so finding ways to fund this is a critical task for society.

In some environments, the model of cooperative volunteer work can and has provided useful software, using an open source development model. But in practice, most software is produced in commercial environments by engineers who expect to make their living from their work. Even in the case of well known large scale open source projects, such as the Linux kernel, Eclipse, and the GNU project, most major work is done by companies, such as IBM, Red Hat, and my own company, AdaCore, that pay people to work on these projects.

Recently, most commercial software companies, including Microsoft, have come to rely on energetic enforcement of their Intellectual Property Rights (IPRs), with extremely restrictive licenses, and rigorous enforcement of copyrights and patents. Unfortunately this model is severely flawed when it comes to software. To see why, let’s consider some examples from other fields. If Prada designs an elegant pair of shoes, you can buy them in a shop, and once you have bought them, you can fully enjoy them without any restrictions. You can lend them, wear them, sell them, and even carve holes in them if that is your wish. The fact that Prada energetically protects its rights in an attempt to prevent unauthorized copying by other manufacturers does not in any way restrict your rights as a consumer. In fact you benefit from these efforts, since you know that something with the Prada name will have the provenance and quality that you expect when you plonk down your credit card to buy them.

Similarly, if you buy a fancy coffee-making machine, you can do anything you like with it. If you open it up and start fiddling around, you probably void the guarantee, but you don’t end up as a target in a lawsuit. You can even resell modified equipment; an example of this is the many distributors of region-free DVD players, who buy standard DVD players, and modify them to region zero and resell them. In these cases the equipment you buy is likely to be protected by patents, but the fact that the company from which you bought the equipment carefully protects these patents does not directly affect you as a consumer.

With software, the situation is entirely different. If you buy software, you often have to agree to a license whose whole purpose is to restrict your rights as a consumer to make full use of the software, for instance by restricting its use to a single machine, forbidding you to transfer it to another person, preventing you from modifying it, and even making simple use of the software inconvenient by the use of license keys or similar devices, or in the worst case when protection technologies fail, preventing you from using the software entirely. This happened to people with Microsoft’s Vista system, where systems designed to prevent unauthorized use malfunctioned and prevented legitimate use. Another example from the music industry, where similar considerations apply, is the infamous root kit from Sony, where buying and listening to a CD on your computer severely compromised the entire operation of the computer.

Now back to the software manufacturer: unlike the shoemaker, who is determined to provide the most beautiful shoes and provide them to a consumer, ensuring that the consumer can fully enjoy the product, the manufacturer of proprietary software is caught between two concerns. On the one hand, they want to provide the software in the most usable form. On the other hand they are concerned with protecting their investment, which leads in the direction of highly restrictive licenses. In most industries, the general maxim is to give the consumer what they want, and providing software with licenses that are inconvenient and intrusive hardly seems to meet this goal.

Is there another way? We believe that in many situations the answer is yes. Now remember we are looking at this issue from the point of view of a commercial company that needs to make money to fund continued development and innovation. We are not on some ideological campaign here to eliminate all notion of copyright. In fact we are pretty sure that, for example, distribution of modern computer games that cost tens of millions of dollars to produce requires some form of copyright control. We are not so sure that software patents ever contribute to innovation, but that’s a discussion for another day.

At AdaCore, we produce advanced development tools and environments centered around the Ada language that are used by major companies such as Boeing, Lockheed, and Airbus to build the next generation of civilian and military aircraft, critical space systems, air traffic control systems, and other large scale applications requiring absolute reliability. Developing such systems is a complex task, and we have spent somewhere between fifty and a hundred million dollars so far building this technology. Most likely if we had outside investors, they would be very concerned about protection of our intellectual property rights in our systems, and expect us to use restrictive licenses to vigorously protect these “rights”.

In fact we distribute all our software using open source/ free software licenses that are the polar opposite from being restrictive. Are we crazy? Or perhaps ideological zealots intent on undermining the basis of commercial software? Not at all! We are running a business, where, like anyone else running a business, we are concerned with maximizing revenue so that we can continue to develop and innovate (not to mention paying ourselves good salaries to support our families.) So how can we afford to give our technology away? That’s the question that is often asked, but it is quite off target and confused. We don’t give our technology away; we sell it at competitive prices in a market where many of our competitors do use restrictive licenses. But we believe in giving the customer what they want and need. Restrictive licenses are a big pain in the neck. For us it is a significant competitive advantage that our software avoids these licenses, and many of our customers regard this as a big plus when it comes to deciding what technology to choose in a highly competitive market.

Despite this, people are still puzzled by our approach. We use the GPL license for our main tools, and a modified version of the GPL for run-time libraries and other components that our customers must be able to redistribute without restrictions. Our customers are certainly not operating in the open source environment. Many of them are developing highly proprietary systems, and in some cases highly classified systems. We suspect that some of them would in fact benefit from the use of more liberal licenses, but it is not our job to tell customers what to do—it is our job to give customers what they want! So, if we are using licenses like this, people wonder, how can we possibly make money? The answer is simple, and it’s the same answer any software company would give in describing their key to success—we provide well-tested quality software, with excellent support and upgrades, along with clear licenses that make the legal situation apparent. It is true that versions of our software can be obtained cheaply or free (nearly every version of distributed GNU/Linux comes with some version of our technology), but our customers are willing to pay for the service we can offer. In particular, the support services we provide are of key importance. If you have a large team working on a critical project that gets held up because of some misunderstanding of the technology they are using, the cost just in lost productivity can be huge, never mind the costs of late delivery. In addition, it is very important for large companies to have a very clear legal idea of the licensing of the software they use, and a company to stand behind the license. Downloading miscellaneous software from the Internet can be risky to your legal well-being!

It’s worth saying a bit more about support. Why do we provide excellent support? Well part of the answer is that we are committed to our technology and proud of our achievements, and want to make sure that people who use it are successful. But more importantly, and much more convincingly from our customer point of view, is that we charge for our software on an annual subscription basis. We make money if people renew their support contracts. They don’t have to—they could continue to use the technology without support. So we have a strong incentive to provide good support so that our customers will indeed renew their contracts. It’s always good when the financial interests of a company are aligned with customer needs in this way. But, you say, if you know about the GPL, what’s to stop people from freely redistributing your technology, as permitted by the license? Yes, this is theoretically possible, but no one can provide the support we do, and our customers benefit from our high pace of continued innovation. Furthermore, our customers are simply not in the business of redistributing our tools. Interestingly, there is nothing to stop another company competing directly with us to provide support and improvements. This hasn’t happened so far, but the possibility is always there. Our business model has a certain “innovate or die” aspect, which keeps us hard at work, and most certainly benefits our customers.

What about users of our software? Due partly to deliberate spreading of misinformation by companies committed to a highly proprietary model, there are still those who mistrust commercially distributed Free Software. They worry about “losing their IPR’s”, or being forced to distribute sources of their proprietary applications. These concerns are misplaced. Of course it is important to carefully read license agreements and make sure you adhere to them. Our licenses allow you to do anything you could do with a Microsoft End User License Agreement (EULA), and a lot more as well, but they don’t allow arbitrary use. If you copy a chunk of our compiler technology into your proprietary code, that’s a copyright violation, just as it would be if you similarly copied Microsoft code. Both situations should be avoided! What about the “requirement” in the GPL that in this situation you are forced to distribute your own sources? There is no such requirement in the GPL. In the situation where you have illicitly copied GPL’ed code in violation of the copyright, the GPL does permit but not require you to cure the copyright violation by publishing the source code, but you are not going to take this option if you have proprietary code you don’t want to disclose. Instead you will adopt other strategies for cure, such as getting a different license for the offending code or removing it.

It’s never a bad thing to have more freedom in what you can do with the software you buy, but education is needed. If you have programmers who simply assume they can do absolutely anything they like with open source/free software, you need to disabuse them of this confusion, or you could run into trouble. Remember also that just because you have the right to do something it is not necessarily a good idea to exercise that right. In a recent conversation with U.S. Navy officials in charge of establishing navy policy on open source usage, one of them said to me “Our lawyers are warning us that we may acquire some undesirable legal liabilities if we redistribute GPL’ed software.” My reply was that their lawyers were quite right and that they should probably issue a policy forbidding this. After all, I told them, the U.S. Navy s not in the business of redistributing software tools, why should they change this policy? Still there is confusion. In one case a large company insisted that we write them a special more restrictive license, since their lawyers were suspicious of the very free licenses we provided. However, as time goes by, more and more large companies depend on widespread use of open source tools, and their lawyers get more comfortable with the idea of copyright being applied to protect user rights and not simply those of the vendor.

In conclusion, the notions of free/open source software licenses, and commercial for-profit software manufacture are not necessarily in conflict. Our technology at AdaCore is not always the least expensive, but in the view of our growing family of Ada customers, it is the best, and they are willing to write us the checks that have allowed us to build and maintain a growing business for fourteen years that now employs over fifty full time people world-wide.

About the Author

Dr. Robert B. K. Dewar is co-founder, President and CEO of AdaCore; he also has had a distinguished career as Professor of Computer Science at the Courant Institute of New York University. He has been involved with the Ada programming language since its inception in the early 1980s and, as co-director of both the Ada-Ed and the GNAT projects, he led the NYU team that developed the first validated Ada compiler. Dr. Dewar was one of the authors of the requirements document for the Ada 95 revision, and he served as a distinguished reviewer for both Ada 83 and Ada 95. He has co-authored compilers for SPITBOL (SNOBOL), Realia COBOL for the PC (now marketed by Computer Associates), and Alsys Ada, and he is a principal architect of AdaCore’s GNAT Ada technology. He has also written several real-time operating systems, for Honeywell Inc. A talented public speaker, he is frequently invited to conferences to share his thoughts on computers and on open-source software, and he has delivered papers and presentations on a variety of topics dealing with programming language issues and safety certification.

Author Contact Information

dewar@adacore.com

August 2008
Vol. 11, Number 2

Intellectual Property and Software
 

Articles in this issue:
Intellectual Property And Software
Introduction to U.S. Intellectual Property Law
Software and Intellectual Property Rights
Preparing for Open Source
Software Freedom and Web Applications

Download this issue (PDF)

Get Acrobat

Receive the Software Tech News
 
Click here to submit
an article or to check out future themes of the Software Tech News

STN Issues

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993


About the Software Tech News
 
  Advertising Opportunities
 
  Article Reprints
   DACS Gold Practice Initiative  ROI Dashboard
 
Acquisition Process Improvement
Architecture-First Approach
Assess Reuse Risks and Costs
Binary Quality Gates at the Inch-Pebble Level
Capture artifacts in rigorous, model-based notation
Commercial Specifications and Standards/Open Systems
Defect Tracking Against Quality Targets
Develop and Maintain a Life-cycle Business Case
Ensure Interoperability
Formal Inspections
Formal Risk Management
Goal-Question-Metric Approach
Integrated Product and Process Development
Manage Requirements
Metrics-based Scheduling
Model Based Testing
Plan for Technology Insertion
Requirements Trade-Off/Negotiation
Statistical Process Control
Track Earned Value
  Access benefit data from software technical and management improvements including SEI CMMI, PSP/TSP, Cleanroom, Inspections, and Agile Development.

View the ROI Dashboard
Copyright © 2010, ITT Corporation    Privacy Policy
webmaster@thedacs.com
775 Daedalian Drive Rome, NY 13441
(800) 214-7921 Fax: 315-838-7130
This site is best viewed in Firefox 1.0+ or IE 6.0+
XHTML