[Fsf-friends] MORE: Opening the open-source debate

URL : http://www.linux.org/news/opinion/skoll.html

"Opening the Open-Source Debate"

David F. Skoll, Roaring Penguin Software

The [24]Alexis de Tocqueville Institution (AdTI) has finally published its [25]white paper entitled "Opening the Open Source Debate". My [26]earlier comments were based on media reports and e-mail correspondence with the paper's author. This document was written after I read the actual white paper. (The original link seems not to work; I managed to grab a copy of the paper before AdTI pulled it. [27]This link may work.)

The AdTI's very weak and poorly-researched paper opens no debate. It simply confirms that Microsoft paid AdTI to come up with something---anything---to stem the growing adoption of open-source (especially GPL'd) software by business and government.

Let's take a look at the paper in detail.

I. In the Beginning

Section I, "In the Beginning", gives an overview of proprietary vs. free software. It's reasonably accurate, although the author is given to rather ludicrous depictions of source code as a "secret formula" and a "map to a buried treasure."

II. GPL Open Source: The Gift That Keeps Taking

Section II is where Microsoft vents its anger. Take a look at this gem:

The GPL is one of the most uniquely restrictive product agreements in the technology industry.

Why does Microsoft... excuse me, the AdTI... say that? They say that because:

The GPL requires that if its source code is used in any type of software product (commercial or non-commercial) for any reason, then the entire new product (also known as the derivative) becomes subject to terms of the GPL open source agreement.

This is not quite true; if you do not distribute your derived product, then you do not need to distribute the source code. But for the most part, the statement is accurate.

But so what? Suppose you derive a product from Microsoft Windows or some other proprietary code. Then you are breaking all kinds of license agreements. Furthermore, proprietary vendors would demand and get the rights to your derived product, leaving you with nothing.

The GPL is no more restrictive than the most liberal of proprietary licenses, and a good deal less restrictive than most. So Microsoft's... excuse me, the AdTI's... complaints are groundless.

Another quote:

David Wheeler, publisher and expert in Washington on open source and proprietary source comments, without licensing the source code in a multi-license format, (referring to other more permissive licenses), it is impossible for GPL to work for a proprietary business model.

Perhaps the AdTI misses the point. GPL advocates do not care if GPL'd software can be made to work in a proprietary business model. It's not our problem. There's no God-given right for proprietary software vendors to make money; they have to compete. And if the rules of the marketplace suddenly change and make it difficult for them, well---tough. Adapt or die. Don't moan.

III. The Myth of a Public Software Community

Section III attempts to debunk the "myth" of a public software community.

The AdTI hints that open-source advocates abandon their principles when they smell money:

Widespread support for GPL open source lies in the IT community's frustration with competitive, closed proprietary software. But in fact, it is quite common that programmers experiment with open source until they see an opportunity to capitalize on an idea, then embrace proprietary standards. One could joke that open source has been a bridesmaid but never a bride. The story of the web browser is an example of this reality.

AdTI uses the story of Netscape "killing" the open-source Mosaic. Well, Mosaic was never GPL'd. If it had been, Netscape would have been unable to kill it. Furthermore, AdTI says of Mosaic:

Through a commercial partner, Spyglass, NCSA began widely licensing Mosaic to computer companies including IBM, DEC, AT&T, and NEC.

Conspicuously absent from AdTI's list is another licensee: Microsoft. Yes, Spyglass's browser formed the basis for Internet Explorer. And revealed here is Microsoft's reason to fear the GPL: It cannot make use of the work of thousands of dedicated programmers for free, locking the work up in a proprietary product. It did that with early versions of its TCP/IP stack, derived from the Berkeley stack. But as more free software is GPL'd, Microsoft's cherry-picking opportunities diminish. Isn't it sad?

The AdTI never quite gets around to saying why the open-source community is a "myth". Apparently, the hundreds of collaborators who gave the world the Linux kernel are mythical. Perhaps the outstanding KDE desktop environment was written by unicorns. And one supposes that GNOME, another outstanding desktop environment, was produced by, well, gnomes. Apache---it's a myth. PHP---doesn't exist. Mozilla---pshaw.

Even in my own modest software development, I've had contributions from dozens of people around the world to my software packages. I've had suggestions, fixes, enhancements and pieces of wisdom donated to me which would never have happened in a proprietary development environment.

IV. The Government and the GPL

This is where politicking gets into high gear.

However, the use of the GPL has the potential to radically alter a very successful model for partnership, particularly when most large commercial entities do not readily embrace the GPL.

Once again, the white paper is worried about "large commercial entities." Well, some large commercial entities like HP/Compaq, IBM, Dell and Sun are quite willing to use, produce and/or distribute GPL'd software. To those large commercial entities who wish to stop GPL'd software, I say:"Tough. Adapt or die."

Needless to say, the government could not depend on patches for software glitches to wander in from the public. Likewise, the government could only use open source code that it could independently service in case of an emergency. Agencies without extensive staff to maintain its internal operations cannot afford to use hapless and untested software without accountability, warranties or liability.

This is a complete red herring. Patches don't "wander in" from the public for open-source products. Rather, they come straight from the authors, or sometimes from distributors such as Red Hat. Furthermore, they tend to come in with a lot more alacrity than fixes from commercial vendors.

With open-source, the government at least has an option to be able to "independently service" the software in case of emergency. With proprietary software, the government does not even have this choice. Therefore, the AdTI's objections on this ground are spurious.

Another consideration for the U.S. government is that all source code developed under the GPL could have mirrored availability to the public. This poses unlimited security issues.

AdTI loves this refrain, but has yet to prove it. In my [28]other article, I debunked the myth that source code availability necessarily introduces security issues, and demonstrated that in fact, it can often enhance security. I was interviewed by AdTI for my opinions on the matter; they neglected to include my comments in the paper.

For example, if the Federal Aviation Agency were to develop an application (derived from open source) which controlled 747 flight patterns, a number of issues easily become national security questions such as: Would it be prudent for the FAA to use software that thousands of unknown programmers have intimate knowledge of for something this critical? Could the FAA take the chance that these unknown programmers have not shared the source code accidentally with the wrong parties? Would the FAA's decision to use software in the public domain invite computer hackers more readily than proprietary products?

Again, a ludicrous example. No-one simply sits down and "develops" such an application by starting with free software. Even if the FAA did develop an open-source flight-control application, AdTI has not demonstrated at all that it would have significantly-different security issues than a closed-source one. Sure, AdTI asks a bunch of rhetorical questions. But that's not how one conducts a logical argument. So let's answer the rhetorical questions with some of our own:

Would it be prudent for the FAA to use software that thousands of unknown programmers have intimate knowledge of for something this critical?

Is it prudent for any federal agency to use Microsoft software, given that it is a matter of [29]public record that Russian hackers illegally broke into Microsoft's network and had access to source code? Is it prudent for any federal agency to use software which is not freely-available for peer review? Is it prudent for any federal agency to take the word of a proprietary vendor that its software is secure, given that the vendor is attempting to make a sale?

Could the FAA take the chance that these unknown programmers have not shared the source code accidentally with the wrong parties?

Will the FAA ban the use of Microsoft software, given that it is a certainty that Microsoft source code has been shared "accidentally with the wrong parties"?

Would the FAA's decision to use software in the public domain invite computer hackers more readily than proprietary products?

Will the AdTI comment on why proprietary Web servers seem to be cracked [30]far more often than open-source ones, even though they have smaller market share?

Reverse Engineering

Experts differ on whether the primary focus for security should source code or binary code. Andrew Sibre, a programmer with over twenty years of experiences insists, "Having a license for binaries only gives you a black box : you don't know what it's doing, or how, unless you want to go insane trying to reverse-engineer it with a debugger (illegal under the term of most licenses)" Having the source lets you see what it's doing, how it does it, and permits you to modify it to meet your particular requirements (including security related ones). To this extent, government officials should be concerned that threat may not just be an adversary cracking their system, but inadvertently educating adversaries about their security systems. Sibre continues, "Depending on code without the source is quite similar to depending on a complex mechanical or electronic system without the benefit of shop and parts manuals."

Naturally, having access to source code eases reverse-engineering. However, the vast majority of security exploits are found without access to the source code. As I wrote to Ken Brown, the author of the report:

The entire premise of computer security and encryption is as follows:

A security system must be resistant to attack *even if* the attacker has all the details about how it works. I refer you to:

"Applied Cryptography", Bruce Schneier, John Wiley and Sons, Inc, page 3:

"All of the security in these algorithms is based on the key (or keys); none is based in the details of the algorithm. This means that the algorithm can be published and analyzed. Products using the algorithm can be mass-produced. It doesn't matter if an eavesdropper knows your algorithm; if she doesn't know your particular key, she can't read your messages."

I refer you also to:

"Practical UNIX and Internet Security", Simson Garfinkel and Gene Spafford, O'Reilly and Associates, pages 40-45:

"... This is especially true if you should find yourself basing your security on the fact that something technical is unknown to your attackers. This concept can even hurt your security."

I refer you to an Internet draft on security through obscurity: [31]http://www.ietf.org/internet-drafts/draft-ymbk-obscurity-00.txt

A few more links on why security through obscurity does not work:

[32]http://www.zdnet.com.au/developer/standards/story/0,2000011499,202 65619,00.htm

[33]http://www.treachery.net/~jdyson/toorcon2001/

[34]http://www.counterpane.com/crypto-gram-0205.html

[35]http://online.securityfocus.com/columnists/80

[36]http://www.vnunet.com/Analysis/1126488

Is Reverse-Engineering That Hard?

Before I started Roaring Penguin Software Inc., I worked at [37]Chipworks, a company which does reverse-engineering for a living. From first-hand experience, I know that hardware and software security can be broken more easily than most vendors believe, and much more cheaply, too.

Back-Doors

Ken Brown raises the old back-door bogeyman:

Another security concern is that the primary distribution channel for GPL open source is the Internet. As opposed to proprietary vendors, open source is freely downloaded. However, software in the public domain could contain a critical problem, a backdoor or worse, a dangerous virus.

The following material is taken straight from my other article, where I already covered the back-door issue: In fact, there have been some trojans placed in open-source software. They have usually been discovered and neutralized very quickly. By contrast, closed-source products have a sad history of [38]spyware, [39]"Easter eggs", and [40]questionable material, placed by people who have (presumably) been "screened." In fact, one of Microsoft's own security updates was [41]infected with a virus, something which (to my knowledge) has never happened in the open-source world.

An interesting back-door was one in Borland's closed-source [42]Interbase product. This back-door lay undetected for years, but was revealed within weeks of the product being open-sourced.

And another interesting little "easter egg" is on the AdTI's [43]very own Web site.

[44]Questionable material in Microsoft software may have helped spur a Peruvian bill to promote free software in government. The author of the bill [45]says that open-source software provides a better guarantee of "security of the State and citizens" than proprietary software, an analysis which is 180 degrees out of phase with the AdTI Study.

The real "victims" of the GPL

The government's productive alliance with private enterprise is also relevant particularly when its decision to use GPL source code would inherently turn away many of its traditional partners. Security, as well as other impracticalities make GPL open source very unattractive to companies concerned about intellectual property rights. In effect, the government's use of GPL source code could inevitably shut out the intellectual property based sector.

The Government must choose software to maximize national security and minimize government expenditure. It owes absolutely nothing to the "IP-based sector" or any other corporation. What was it I said before? Oh, yes: "Tough. Adapt or die."

This has a number of ramifications. Immediately, it would limit the number of qualified vendors to choose from to deliver products.

Tough. Adapt or die.

The GPL's wording also prevents the equal use of software by members of the IP community and the GPL open source community.

This is a lie. If the "IP community" (whatever that is) respects the terms and conditions of the GPL, it's as free as anyone else to use and distribute GPL'd software. If it doesn't like the terms of the GPL, that's the "IP community's" problem, not the GPL's problem.

A worse consideration is that use of GPL could inadvertently create legal problems. IP community members could argue that the government's choice of open source is restrictive and excludes taxpaying firms from taxpayer-funded projects. Adverse impact would include a discontinued flow of technology transfer from government-funded research to the technology sector. Without value, it becomes highly likely that government funding for research would slow as well.

Here, AdTI is delivering a veiled threat on behalf of Microsoft. First of all, if "IP community members" could argue that, they already would have. They have not made the argument because they know it is specious. In fact, there's a very good argument for requiring the fruits of government-funded research to be GPL'd so that all citizens can benefit.

Furthermore, the "IP community members" have benefited from government research as much as (or more than) government has benefited from private research. So to pull out of government partnerships out of pique over software licensing would only hurt proprietary vendors and no-one else.

V. Intellectual Property Left

This is a rewording of "Free Software is Communism" and merits about the same amount of serious attention.

U.S. intellectual property (IP) statutes have been a beacon for inventors around the world. The U.S. model for motivating, compensating and protecting innovators has been successful for almost 200 years. GPL source code directly competes with the intellectual property restrictions, thus it is vital to analyze its impact.

The GPL does not in any way "compete" with U.S. copyright law. It uses U.S. copyright law in a perfectly legitimate and reasonable way.

There are two groups of programmers that contribute to the open source community. The first group consists of professionally hired programmers by day, who freely contribute code. The second group consists of original equipment manufacturers (OEMs) that are hiring open source programmers for their products. However, open source principally perpetuates itself because there is an avid pool of experts and enthusiasts willing to spend their spare time to provide fixes and modifications to open-source software. This volunteer system works well as an academic model, but not as a business one.

Who cares about business models? We have Linux, Apache, Mozilla, Gnome, KDE, Perl, Python, PHP, FreeBSD, OpenBSD, NetBSD, and so on in spite of the supposed lack of a business model. What we see here is more whining from proprietary vendors about how free software is hurting their business model. Let's hear the refrain: "Tough. Adapt or die."

As mentioned earlier, open source code is not guaranteed nor does it come with a warranty.

Neither does most proprietary software, so this is a red herring. If you want a warranty, most open-source vendors will be happy to provide one if you pay for it.

Open source products are often distributed without manuals, instructions or technical information. While a commercial developer is obligated to produce manuals, diagrams and information detailing the functionality of their products, open source programmers are not. In addition, open source developers cannot be expected to create software manuals with the vigor of private firms that are obligated to produce them. Producing technical specifications (in soft or hard copy format) is time-intensive and expensive. But this is not just a customer service issue.

Some open-source software comes with poor documentation, just like some proprietary software. Other free software comes with excellent documentation. It's a matter of customer choice: Choose software that has what you need.

All of my free software products come with complete manual pages. Most serious developers do not consider software finished until the manuals are finished.

Innumerable questions surround the distribution of technical information in the copyleft environment, particularly because the Free Software Foundation has a copyleft license for its documentation as well. Issues include: Who should have the right to alter software manuals? Who is the final editor or is there one? How should changes be regulated? Are manuals copyright protected documents? What is the process for making changes? What body regulates these changes? How can organizations guarantee that information in manuals is always accurate?

More rhetorical questions. With proprietary software, if the manuals are inaccurate, you're out of luck. With free software, you at least have a chance to correct them.

Again, we see the unease of the proprietary vendors who want bodies to "regulate" changes. They are unable to wrap their minds around the new reality of free software. Rather than changing their ways, they dig in their heels. They may need another reminder: Tough. Adapt or die.

Today, software impacts a firm's financial health in an intimate fashion. It becomes unrealistic for a firm to depend too much on the trust of an anonymous community that does not have anything at stake financially to keep important technical documents current.

On the contrary, it is imperative that businesses rely solely on free software for access to critical information. Only in this way can they guarantee access to their data, and not be held hostage by proprietary file formats and proprietary vendors. To quote Dr. Edgar David Villanueva Nunez, a Peruvian legislator:

To guarantee the free access of citizens to public information, it is indispensable that the encoding of data is not tied to a single provider. The use of standard and open formats gives a guarantee of this free access, if necessary through the creation of compatible free software.

To guarantee the permanence of public data, it is necessary that the usability and maintenance of the software does not depend on the goodwill of the suppliers, or on the monopoly conditions imposed by them. For this reason the State needs systems the development of which can be guaranteed due to the availability of the source code.

To guarantee national security or the security of the State, it is indispensable to be able to rely on systems without elements which allow control from a distance or the undesired transmission of information to third parties. Systems with source code freely accessible to the public are required to allow their inspection by the State itself, by the citizens, and by a large number of independent experts throughout the world. Our proposal brings further security, since the knowledge of the source code will eliminate the growing number of programs with *spy code*.

In the same way, our proposal strengthens the security of the citizens, both in their role as legitimate owners of information managed by the state, and in their role as consumers. In this second case, by allowing the growth of a widespread availability of free software not containing *spy code* able to put at risk privacy and individual freedoms.

In fact, Villanueva's [46]eloquent and well-written letter handily demolishes most of AdTI's premises and conclusions; it's well worth a read.

More on Reverse Engineering

The reliance on reverse engineering is probably one of the biggest conflicts between the IP and the GPL open source community. To keep GPL products relevant and up to date, GPL enthusiasts must perpetually reverse engineer intellectual property.

Reverse-engineering is required only if hardware manufacturers keep the details of their software/hardware interfaces secret. The vast majority of hardware manufacturers do not keep them secret. Some which do keep them secret provide (binary-only) drivers for free software systems. Reverse-engineering is necessary only for the small minority of hardware devices which are secret.

Reverse engineering has a number of implications. It harbors very close to IP infringement because and has staggering economic implications.

Reverse-engineering is perfectly legal. In fact, the European Union has a law guaranteeing the legality of reverse-engineering for the purpose of creating compatible software or devices. AdTI implies that reverse-engineering is "close to IP infringement", but they never say why (and their sentence doesn't even parse.)

If software is freely re-engineered, it will inevitably impact the value of software on the market. If the price of software is adversely impacted, salaries and inevitably employment of software programmers would be negatively affected as well.

This is correct. If software is freely re-engineered, it destroys monopolies and brings back a sense of free market to the industry. Yes, software prices go down. And yes, consumers benefit.

The whole paragraph is simply a thinly-hidden Microsoft lament about the success of products like Samba which enable companies to run Microsoft-compatible file sharing without exorbitant Microsoft licensing fees.

VI. Is the GPL Cost-Beneficial?

This is a restatement of the tired old "TCO" straw-man.

Discussing the economic implications of open source, Andre Carter, President of Irimi Corporation, a technology consulting firm in Washington comments, "The question of open source code is about whether the software developer wants to make available to the world the blueprint of what they built or simply the benefits of what they built. The notion of open source software has nothing to do with free software. The purchase price of computer software is only a fraction of the total cost of ownership. So even if the price tag reads free , it can end up being more expensive than software you buy. This is especially true for the typical consumer. If it requires technical know-how to operate, doesn't offer built-in support, and demands constant attention, it won't feel free for very long."

Lot's of "if's" and weasel-words in there. If it requires technical know-how to operate, etc, etc. Nowhere does Carter say that free software does in fact require any more technical know-how than proprietary software. Furthermore, proprietary software often has [47]hidden costs which can come back later to haunt you.

The success of an A-Z open source environment would expectedly impact the software sector as a viable entity. If software is freely available, but PC s, servers and hardware maintain their value, we can only predict that the value of software companies will plummet. Hardware will come with more and more free software. Second, we can only expect that the revenues and value of the software sector will transfer to the hardware sector. Although the software sector has seen growth almost every year, it is questionable whether the GPL model will enable the software industry to continue its exceptional growth particularly when the growth in the software sector is tied to proprietary products, something the GPL is anxious to eliminate.

In the 1800's, black-smithing was a pretty good profession. In the 1960's and 1970's, 8-track tapes did a pretty good business. The fact is that the black-smith industry and the 8-track tape industry failed to heed the iron rule of the market: Adapt or die. If free software means the death of proprietary software vendors, it will be on those vendors heads who fail to adapt.

Businesses must be concerned about the perception of the GPL. For example, experts assess the value of intellectual property when completing valuations of firms. Because GPL open source literally erases the proprietary and trade secret value of software, it can be expected that firms concerned about valuations will be very concerned about using GPL open source.

This is only of concern to firms producing software. The vast majority of firms consume software, and for them, in-house software production is a cost, not a revenue source. For the vast majority of firms, free software will save them lots of money. For those few firms planning on building a business model around proprietary software, I offer my old refrain: Adapt or die. What's good for proprietary software vendors is not necessarily good for the citizen.

There are all types of consumers with ranges of needs and abilities. The guys in the lab at MIT don't need install wizards, plug and play drivers, voice based technical support and big picture manuals as part of their software. However, the elderly couple e-mailing their grandkids or the mother of two managing accounts on a PC in the kitchen does.

Carter clearly has a stereotyped view of consumers. My elderly parents, who enjoy e-mailing their grandkids, use only free software. They are quite happy to use Linux and Netscape. Furthermore, the choice of free software eases my support burden: If my parents need help, I can SSH into their machine and fix it remotely. With all of Microsoft's "wizards" and other gimmicks, they still do not provide a convenient means for remote administration on their consumer-level systems.

People believe free software is hard to use because they've never used it. Just as the AdTI showed that people who've actually worked with MCSE's have a higher opinion of them than people who haven't, people who've actually bothered to use free software have a higher opinion of it than people who haven't.

VII. GPL Open Source and the Courts

Once GPL code is combined with another type of source code, the entire product is GPL. Subsequently, this change could occur deliberately, but it could also occur accidentally. There are unlimited scenarios for accidents to occur, the license could be lost in the source code's distribution, or maybe unreadable due to a glitch in its electronic distribution. Another potentially litigious issue is whether the use of GPL tools used to manipulate code subject software to the GPL. Theoretically, a GPL tool could subject new software to GPL restrictions. This too will have to be interpreted by a judge. Regardless, unknowing users of GPL might have one intention for use of the license and find out later that it inadvertently infringed upon copyright protected work. Legal questions relevant to such an event intersect the legal arenas of intellectual property rights, contract law and liability.

AdTI is very good at offering up red herrings. Let's suppose you "accidentally" included part of Microsoft Windows in a product. Do you suppose Microsoft would be easier on you than copyright holders of a GPL'd product?

The fact is that any software license has terms and conditions which must be obeyed. The GPL is no different; if you do not like its terms, don't use GPL'd software. Microsoft's agenda is transparent here.

The proprietary software industry entreats you to diligently track licenses, and offers [48]harsh retribution against those who violate their licenses. Most GPL violations are settled amicably, and those which result from an accident are usually settled merely by removing the offending code from distribution.

The rest of Section VII is simply speculation and not even worth commenting on.

VIII Conclusion

Open source as a development model is helpful to the software industry. For example, software distributed under the BSD license is very popular. The BSD license (see Appendix 9) enables companies, independent developers and the academic community to fluidly exchange software source code.

English translation: The BSD license is good because it allows corporations to benefit from other people's work without offering them any compensation, and without having to allow third parties to benefit from derived work.

The GPL's resistance to commonplace exchange of open source and proprietary has the potential to negatively impact the research and development budgets of companies.

English translation: The GPL doesn't let corporations benefit for free from others' work.

The GPL has many risks, but the greatest is its threat to the cooperation between different parties who collaborate and create new technologies. Today, government, commercial enterprise, academicians, etc. have a system to converge. Conversely, the GPL represents divergence; proposing to remove the current infrastructure of intellectual property rights, enforceable protection and economic incentive.

English translation: The GPL threatens Microsoft's business model. You know my response by now: Tough. Adapt or die.

While GPL advocates are quite active in their promotion of copyleft, few would disagree that its widespread adoption would present a radical change to an industry sector responsible for almost 350 billion dollars in sales annually worldwide (see Appendix 10).

Few would disagree that the automobile all but wiped out blacksmithing as a profession. Few could argue that cassettes didn't decimate the 8-track market. Few would be surprised at my response: Tough. Adapt or die.

AdTI's Numbered Points and my Counterpoints

1- Engineering software has become considerably complicated and rigorous. It is not unusual for software to include millions of lines of source code. If the incentive to develop software is changed, we can subsequently expect the quality and efficiency of software to change.

Yes, with luck, we'd expect the quality to improve. The security records of systems like OpenBSD, Linux, and FreeBSD are vastly superior to that of Windows. While there is no real cause-and-effect relationship, empirical evidence suggests that open-source software is more reliable and of higher quality than most commercial-grade proprietary software.

2- There remains considerable differences within the GPL open source community. It is questionable whether these groups will continue to be proponents of the GPL in its current form or opt for changes in the immediate future.

Even if true, this point is irrelevant. Once software has been licensed under the GPL, the license cannot be retracted. Your rights cannot be withdrawn retroactively (unless you violate the license), unlike some proprietary software licenses.

3- Open source has successfully been used in proprietary software. In addition, academic and government projects have been successful particularly because of commercial interest. Private enterprise offers unique efficiencies for the success of government funded research.

Simply another attack on the GPL. Nothing worth reading; let's move on.

4- Open source GPL use by government agencies could easily become a national security concern. Government use of software in the public domain is exceptionally risky.

A bold assertion, and totally unproven. This assertion is contradicted by empirical evidence. Also, the NSA seems quite [49]comfortable with the security of GPL'd software.

5- Reverse engineering, perpetuated by GPL proponents, threatens not only the owners of intellectual property, but also the software industry itself.

This is an out-and-out lie. Reverse-engineering is critical for the continuation of a healthy software industry. Without legitimate reverse-engineering, there would be no market forces to oppose the development and maintenance of monopolies, and the software market would become even more unfair than it is today.

Attempts to ban reverse-engineering are simply money-grabs by greedy monopolies who wish to hang on to their power.

6- Use of GPL open source creates a number of economic concerns for firms. For example, the valuation of a software company could be significantly effected if it uses source code licensed under the GPL for the development of its products.

If that is of concern (and it is not for the vast majority of corporations), then the corporation is perfectly free not to use GPL'd software.

Using proprietary software for development of products can also significantly lower a company's valuation, especially if the owner of the original proprietary software demands royalties or part-ownership of the resulting IP.

7- The courts have yet to weigh in on the General Public License. Without legal interpretation, the use of the GPL could be perilous to users in a number of scenarios.

If corporations have concerns about legal interpretations of the GPL, they should consult qualified lawyers. IBM, for example, has a massive and top-notch legal team, and they seem to have no qualms about using, creating and distributing GPL'd software. If the AdTI would give us concrete examples of legal concerns, we could discuss them, but as it is, all we are given is conjecture, hand-waving and supposition.

Roaring Penguin's Conclusions

The AdTI claimed that the GPL is "acquisitive", yet fails to note that even the most liberal of proprietary licenses is far more restrictive and places far more encumbrances on derived products than the GPL (if, in fact, it even permits derived products in the first place.)

The AdTI says that the free software community is a "myth", but fails to explain the tens of millions of lines of high-quality code produced by this mythical community.

The AdTI promised to show how using GPL'd software could threaten security, but failed to deliver. Rather, Microsoft's own Jim Allchin admitted under oath that flaws in Microsoft software, if disclosed, could [50]endanger national security.

The AdTI claims that free software damages members of the "IP community" (by which it means proprietary software vendors), but then fails to show how such damage occurs. Even if free software does damage proprietary software vendors, AdTI fails to show why that is a bad thing for citizens in general.

AdTI raises the hoary old "Total Cost of Ownership" issue, but does not demonstrate that proprietary software is more cost effective. AdTI ignores studies like the one from [51]CyberSource or even Roaring Penguin's own case studies in [52]Free Software in the Real World.

The entire AdTI study is a commercial funded by Microsoft, whose sole aim is to counter the growing adoption of GPL'd software. The report contains nothing constructive or useful. It is a sham. _________________________________________________________________

Other press, commentary and related links: * [53]MS-funded think tank propagates open-source lies, The Register. * [54]Dispelling Myths About the GPL and Free Software by John Viega and Bob Fleck. A somewhat more dispassionate rebuttal of the AdTI paper. * [55]A Business Case Study of Open Source Software by Carolyn Kenwood, The Mitre Corporation. * [56]Analysis: Microsoft vs. open source battle gets political, InfoWorld. * [57]Windows NT Cripples US Navy Cruiser, INFOsec.com _________________________________________________________________

Article Copyright � 2002 David F. Skoll The original article can be found at Roaring Penguin's website: [58]"http://www.roaringpenguin.com/adti2.php3

---------------

Maintained by: [59]Webmaster, Linux Online Inc. Last modified: 13-Jun-2002 08:10AM. Views since 16-Aug-2000: 2646.

Material copyright [60]Linux Online Inc. Design and compilation copyright �1994-2002 [61]Linux Online Inc. All rights reserved.

References

Visible links 1. http://www.linux.org/index.html 2. http://www.linux.org/perl-bin/invoke?obj=BOVINE32&stamp=403D6492271606FE... 3. http://www.linux.org/services/directory.html 4. http://www.linux.org/user/signup.html 5. http://www.linux.org/apps/index.html 6. http://www.linux.org/docs/index.html 7. http://www.linux.org/dist/index.html 8. http://www.linux.org/dist/download_info.html 9. http://www.linux.org/hardware/index.html 10. http://www.linux.org/info/index.html 11. http://www.linux.org/lessons/ 12. http://www.linux.org/projects/index.html 13. http://www.linux.org/news/index.html 14. http://www.linux.org/perl-bin/invoke?obj=AMAZON26&stamp=403D2292271699FE... 15. http://www.linux.org/books/index.html 16. http://www.linux.org/people/index.html 17. http://www.linux.org/groups/index.html 18. http://www.linux.org/vendors/index.html 19. http://www.linux.org/perl-bin/invoke?obj=PENGAFF03A&stamp=403D5492271656... 20. http://www.linux.org/events/index.html 21. http://www.linux.org/about/index.html 22. http://www.linux.org/index.html 23. http://www.linux.org/books/FEATURE_0201719347.html 24. http://www.linux.org/redir.php3?http://www.adti.net/ 25. http://www.adti.net/html_files/defense/opensource_whitepaper.pdf 26. http://www.linux.org/news/opinion/adti.php3 27. http://www.adti.net/html_files/defense/old_opensource_whitepaper.pdf 28. http://www.linux.org/news/opinion/adti.php3 29. http://news.bbc.co.uk/hi/english/business/newsid_993000/993933.stm 30. http://defaced.alldas.org/?archives=os 31. http://www.ietf.org/internet-drafts/draft-ymbk-obscurity-00.txt 32. http://www.zdnet.com.au/developer/standards/story/0,2000011499,20265619,00.h... 33. http://www.treachery.net/~jdyson/toorcon2001/ 34. http://www.counterpane.com/crypto-gram-0205.html 35. http://online.securityfocus.com/columnists/80 36. http://www.vnunet.com/Analysis/1126488 37. http://www.chipworks.com/ 38. http://www.accs-net.com/smallfish/advw.htm 39. http://www.eeggs.com/tree/153.html 40. http://www.usatoday.com/life/cyber/tech/review/crh062.htm 41. http://www.theregister.co.uk/content/8/18516.html 42. http://www.cert.org/advisories/CA-2001-01.html 43. http://www.adti.net/html_files/defense/samir_dec_23_2001/pages/ 44. http://www.infoworld.com/cgi-bin/displayStory.pl?99093.enbackdoor2.htm 45. http://linuxtoday.com/news_story.php3?ltsn=2002-05-06-012-26-OS-SM-LL 46. http://linuxtoday.com/news_story.php3?ltsn=2002-05-06-012-26-OS-SM-LL 47. http://stay-legal.org/ 48. http://stay-legal.org/ 49. http://www.nsa.gov/selinux/ 50. http://www.eweek.com/article/0,3658,s%253D701%2526a%253D26875,00.asp 51. http://www.cyber.com.au/cyber/about/linux_vs_windows_tco_comparison.pdf 52. http://www.linux.org/news/opinion/slides/innovatech.pdf 53. http://www.theregister.co.uk/content/4/25656.html 54. http://www.zork.org/rebuttal.pdf 55. http://www.mitre.org/support/papers/tech_papers_01/kenwood_software/index.sh... 56. http://www.infoworld.com/articles/hn/xml/02/06/10/020610hnopensource.xml 57. http://www.info-sec.com/OSsec/OSsec_080498g_j.shtml 58. http://www.roaringpenguin.com/adti2.php3 59. mailto:webmaster@linux.org 60. http://www.linux.org/about/copyright.html 61. http://www.linux.org/about/copyright.html

Hidden links: 62. mailto:trapper@linux.org?subject=DONOTSENDEMAILHERE