[Fsf-friends] MORE: Opening the open-source debate
Frederick Noronha
fred@bytesforall.org
Mon, 24 Jun 2002 08:42:59 +0530 (IST)
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=403D6492271606FE0F1988082819
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=403D2292271699FE0F19FE08287A
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=403D5492271656FE0F191B0828EC
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.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
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.shtml
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