[iwar] [fc:A.Linux.User.Responds.to.ADTI."White.Paper"]

From: Fred Cohen (fc@all.net)
Date: 2002-06-10 22:36:25
Next message: Charles Preston: "[iwar] Insiders plus hackers"
Previous message: Fred Cohen: "[iwar] [fc:Analysis:.Microsoft.vs..open.source.battle.gets.political]"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Message-Id: <200206110536.g5B5aPs20268@red.all.net>
To: iwar@onelist.com (Information Warfare Mailing List)
Organization: I'm not allowed to say
From: Fred Cohen <fc@all.net>
Mailing-List: list iwar@yahoogroups.com; contact iwar-owner@yahoogroups.com
Precedence: bulk
Date: Mon, 10 Jun 2002 22:36:25 -0700 (PDT)
Subject: [iwar] [fc:A.Linux.User.Responds.to.ADTI."White.Paper"]
Reply-To: iwar@yahoogroups.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

"Opening the Open-Source Debate"

<a href="http://www.roaringpenguin.com/adti2.php3">http://www.roaringpenguin.com/adti2.php3>

The Alexis de Tocqueville Institution (AdTI) has finally published its white
paper entitled "Opening the Open Source Debate". My 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. 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&amp;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 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 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 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:
<a href="http://www.ietf.org/internet-drafts/draft-ymbk-obscurity-00.txt">http://www.ietf.org/internet-drafts/draft-ymbk-obscurity-00.txt>

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

<a href="http://www.zdnet.com.au/developer/standards/story/0,2000011499,20265619,00.h">http://www.zdnet.com.au/developer/standards/story/0,2000011499,20265619,00.h>
tm

<a href="http://www.treachery.net/~jdyson/toorcon2001/">http://www.treachery.net/~jdyson/toorcon2001/>

<a href="http://www.counterpane.com/crypto-gram-0205.html">http://www.counterpane.com/crypto-gram-0205.html>

<a href="http://online.securityfocus.com/columnists/80">http://online.securityfocus.com/columnists/80>

<a href="http://www.vnunet.com/Analysis/1126488">http://www.vnunet.com/Analysis/1126488>
Is Reverse-Engineering That Hard?

Before I started Roaring Penguin Software Inc., I worked at 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 spyware, "Easter eggs", and questionable material, placed by
people who have (presumably) been "screened." In fact, one of Microsoft's
own security updates was 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 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 very own Web
site.

Questionable material in Microsoft software may have helped spur a Peruvian
bill to promote free software in government. The author of the bill 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 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 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 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 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 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 CyberSource or even Roaring Penguin's own case
studies in 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. 

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Will You Find True Love?
Will You Meet the One?
Free Love Reading by phone!
http://us.click.yahoo.com/Deo18C/zDLEAA/Ey.GAA/kgFolB/TM
---------------------------------------------------------------------~->

------------------
http://all.net/ 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Next message: Charles Preston: "[iwar] Insiders plus hackers"
Previous message: Fred Cohen: "[iwar] [fc:Analysis:.Microsoft.vs..open.source.battle.gets.political]"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
This archive was generated by hypermail 2.1.2 : 2003-08-24 02:46:32 PDT