QODS ec

Thursday, July 01, 2004

LINUX: Commentary: Debating de Tocqueville on Open Source and its impact

NewsForge | Commentary: Debating de Tocqueville on Open Source and its impact

Title Commentary: Debating de Tocqueville on Open Source and its impact
Date 2002.06.15 7:22
Author Guest
Topic Open Source
http://software.newsforge.com/article.pl?sid=02/06/14/1948201

- By Karl O . Pinc -
A few days ago I read a press released linked on NewsForge about a study to be released. This study purported to recommend the U.S. government not use Open Source software for reasons of national security. To me, this seemed wrong headed. By the time I'd figured out why it seemed so, after all that thought, I felt I should write my conclusions to the president of the Alexis de Tocqueville Institution, the folks who produced the study. I was surprised to receive a letter in return (which quotes my original letter), outlining the as-of-then unpublished report's argument.

The return email didn't address the concerns I had raised. So, without thought for where this was leading, I wrote another, longer, letter. And then, because like everybody else, after sending the email I wished I'd written something else, I wrote yet another letter.

In the exchange, de Tocqueville Institution President Ken Brown requested I answer some questions and possibly have my thoughts included in the study. My answers to his gaggle of questions make up the bulk of this article. I've resisted the temptation to make changes. What you'll read is fact, opinion, and conjecture. I'll take the blame for errors, but would like to share the credit because I obtained the bulk of my thoughts from other folks.

As I mentioned in my response below, it never occurred to me anyone would think Open Source would reduce programmers' incomes. After all, people will continue to need programs. This means programmers will continue to be paid to write programs. Changing from a proprietary license to an Open Source license will only change which hands the money passes through before it gets to the programmer. Programmers who put their name in the copyright of the works they produce may become more visible to the market. Corporate programmers may be less valued, independents more valued. We may see increased economic efficiency as money may pass through fewer hands on its way from the software purchaser to the software author.

A company may find that hiring a well known programmer enhances its prestige, as has happened with Transmeta and Linus Torvalds. More likely, as today, most programming will be done by corporate employees, and their work will be copyrighted in their company's name, however licensed. But none of this will be bad for programmers, and some of this will be good.

But wait, there's more. In my first letter, I allude to contributions Open Source Software has made toward the development of the Internet and the synergy between the two. Here's a link to the AT&T Web site that credits BSD Unix as the development platform for the first implementations of the Internet Protocol (IP) and its jockey TCP, which rides over it. (TCP over IP. TCP/IP. Get it?) The AT&T page fails to mention that a major reason BSD Unix became the first operating system to have an "official" working Internet Protocol was that BSD Unix was always distributed with its source code, under a license which granted permissions to everyone at the receiving institution. This made collaborating easy for any researcher who would join the effort. The first Open Source license, the original BSD license, was a response to the value found in the collaboration surrounding the creation of the Internet Protocol.

And now, without further ado, here's my exchange with Brown:

Subject: Re: Secrecy is not security
Date: 2002.06.06 20:16
From: Karl O . Pinc
To: Ken Brown

On 2002.06.06 10:38 Ken Brown wrote:
> Hello,
> Thanks for your e-mail. We really appreciate your comments (good and
> bad!) about our study.
>
> We would very much like to include your thoughts on the following
> subjects in the paper. It would great if you would be willing to give
> us your thoughts on the following points.

> With respect,
> Kenneth Brown
> Alexis de Tocqueville Institution
>
>
> 1) Technical
> With regards to reverse engineering or re-creating software, please
> define what you think are the key differences between owning the binary
> code of a product and/ or its source code.

I'm afraid I don't understand the question. When reverse engineering a program it is not permissible to have read the source code of the original.

The far and away most compelling reason to have access to a program's source code is to assure yourself continued access to the data you have put into the program, should the binary version of the program become unavailable. Purchase of an important software component is often accompanied by an agreement that the source code be kept in escrow for release to the purchaser should the vendor go out of business. In this event, the customer would then be able to use the source code to access his data and convert it to a form suitable for continued use with some other software.

> What are the pros and cons of using fixes, patches, etc. from community
> open source boards, volunteers and non-hired contractors as opposed to
> OEM vendors of software products?

There is no difference as regards accountability as software vendors do not warrant their products nor indemnify against any loss resulting from product failure.

Consistency of response most distinguishes fixes for which you pay, as compared to fixes which you obtain for free. With paid support, you get a consistent response time and consistent quality. When looking for a "free" fix to a problem, the result obtained depends upon which of three categories the problem can be placed. Problems concerning a program's use are the first category. Questions of functionality, configuration, appropriateness for a particular purpose and the like. The majority, but not all, of the popular programs have public forums which are generally responsive to these questions. However, one must first find the forum on the Internet. The more specific and advanced the problem, the more likely the forum will take an interest and respond, to a point. Another difficulty is simply in the medium of communication, which is usually text via e-mail or bulletin board. The delay, time, and effort involved in reading and writing reduces the effectiveness of the communication and can lead to misunderstanding. FAQs may be poorly written or mis-read. These problems are eliminated or reduced when obtaining paid support.

The down side of open source is the plethora of choice. This remains true when it comes to obtaining support, even paid support. A careful evaluation should be done before choosing a vendor.

Enhancement requests are a special category of problem requiring a special kind of fix and I'll ignore them as they don't fall within the scope of the question.

The remainder of this response concerns the third type of problem/fix, program bugs, and design problems. It is worth noting that the paid support available for commercial products sometimes does not supply bug fixes or fixes to design flaws. The more "desktop oriented" a program, the less likely you are to be able to obtain bug fixes, although you may be able to obtain work-arounds which avoid the bug.

It is important to distinguish between fixes made by an open source program's maintainer(s) and a fix made by some random individual. (A open source program's maintainer is not necessarily the person who wrote the original program.) The maintainer(s) of an open source program are no different from a software vendor. In both cases the program has a history, a market share, and a demonstrated development history. In both cases the producer of the software has a background and demonstrated commitment to continued maintenance and development. The "volunteer" nature of open source programs is irrelevant. (As an aside, many maintainers of open source programs are financially dependent upon their program's success, as they work for companies which rely on the program and are paid to work on, or at least with, the program.) All programs with a market share, meeting a demand, are in turn supported by that demand. It matters not whether the program receives this support via hard cash paid to a corporate entity, or via direct contribution of labor. If it did matter, the program in question would not have received the resources it needed to reach the market share it has obtained.

The advantage in obtaining a fix from a random source is the rapidity with which one frequently obtains the fix. The disadvantages are many. You are left to yourself to determine the efficacy and impact of the fix. Worse, you will forever after have to re-apply that fix whenever you upgrade the software.

The best approach is to obtain the fix from the source that supplied your original software. You are then in the same position from which you started.

Open source software opens a third possibility. You may obtain the fix directly from the program's maintainer. The quality of the fix will be commensurate with the quality of the original program, but you are again left to yourself to determine how well the new program integrates into the rest of your system. You will be responsible for system integration until the fix is distributed by your chosen software supplier. Obtaining the fix from the program's maintainer can be an attractive option. It requires some expertise and commitment, but far less than when obtaining a fix from a random source.

Open source software has a reputation for providing rapid fixes. This is true, but probably exaggerated. One should only count the fixes released by the open source distributors, the companies from which most people obtain open source software. The popular open source distributors usually do provide rapid fixes, often within hours or days. There are few proprietary software companies (Cisco comes to mind as one of them) that are this responsive, at least as far as the average customer is concerned.

As the source code is available to users of open source software, those who distribute fixes cannot conceal the nature of either the problem or the fix. This leads to a refreshing honesty. Distributors keep public databases of known bugs, and accurately describe both the problem and the fix. As a user of open source software, this transparency makes it much easier to determine whether you have a problem and, if so, the scope of it's impact. This clarity reduces the work, and risk, involved in managing (or adopting) open source based systems.

> 2) Economic
> What impact will OSS have on the income(s) of programmers?

None. The factor most likely to affect the income of first world programmers is corporate outsourcing of programming tasks to the third world. OSS is unlikely to affect this one way or the other.

> What impact will OSS have on the proprietary software industry?

Their income will be greatly reduced. Some of the money will flow to software and systems service and consulting firms. Probably the amount that the proprietary software industry spends on software development, customer training and support, and marketing, as the industry's replacement will continue to spend on these items. It's possible that the total spent on marketing will be reduced as the new industry may be composed of many smaller players which rely more on personal contact than mass marketing.

> What are your projections for the growth of Red Hat?

They will grow large, but large in the sense of a large grocery chain. They will never dominate the market in the same way that IBM did or MicroSoft does.

> 3) Property Ownership
> Describe the intellectual property pros and cons of open source
> development

As a user of intellectual property open source software has the strong advantage in that a open source program cannot disappear from the market because it's vendor goes out of business or is acquired by another company. Naturally, even an unpopular open source program can stagnate and see no further development. But the "dead" open source program may continue be used and installed on new computers, and anyone who sees fit may take the task on themselves to resume development. Should it become apparent that development has ceased, users of open source software have as long as they want to migrate to a replacement. The availability of source code makes it orders of magnitude easier to determine how the old program stored your data. (Assuming there is no documentation. Manufacturers of proprietary software usually consider the method used to store your data a trade secret.) Knowing the method used to store your data makes converting the data from the form used by the old program to the form used by the replacement program far simpler, especially if the source code for the replacement is available. So, using open source programs helps you retain control of your intellectual property, your data.

It is worth noting that open source licenses, by definition, do nothing but declare what you must distribute, when you do distribute. If you don't distribute a open source program, it's license places no restrictions on you. (Other than a prohibition against suing the program's author.)

As a developer, there isn't much to say. At least as far as licensing goes. Open source developers retain all their intellectual property rights just like anybody else. One needs to be sure one understands the license one uses, open source or not, as once you grant rights to your intellectual property to someone else you can't take them back. The more your intellectual property adds economic value to what you produce, the closer attention you need to pay.

The other aspect of open source development is it's collaborative nature. Each author owns the code he contributes. If you decide to collaborate it may be difficult to change the license of the body of work as a whole, or to distribute it under more than one license.

> 4) Licensing
> What are the pros and cons of the BSD and GPL licensing agreements?

In a nutshell, what the GPL says is that anyone who has GPL software can do three things: Give (or sell) the software to someone else. Obtain the software's source code as written by the software's author. Give (or sell) changed versions of software, but only if the changed version is also licensed with the GPL. There are three consequences: GPL software tends to be cost free, as many people are willing to give it away. The software can be modified by anyone who has it. The versions of software available under the GPL license can, for all practical purposes, only increase, never decrease.

The BSD license simply keeps the software's author from being sued. (As does the GPL.) One advantage of this is that if you wish to distribute a BSD licensed program under another license, you are free to do so. There are no issues surrounding collaboration, as all contributors have placed their code under the BSD license. But, as so often happens, this advantage is also the weak point in the BSD license.

As either a programmer releasing code under the BSD license or as a user of a BSD licensed program you have a greater risk that the investment you have made in the program will be lost. A BSD licensed program is much more likely to be marginalized in the market than a GPL licensed program. Regardless of the quality of the program. This is best illustrated by the example of the open source BSD operating system (OS), after which the license takes it's name. Many OSs are derivative of the original BSD OS, among them many fine open source OSs like FreeBSD, OpenBSD and NetBSD. OpenBSD is arguably the most secure operating system in use outside the lab, having gone 5 years without a remote vulnerability in the default install. Yet Solaris, a proprietary OS produced by Sun, which also has as it's root the original BSD OS, is today and, along with it's predecessor Sun OS, has been for many years the most popular BSD OS with far and away the largest market share. This happened because Sun was able to take the original BSD code, extend it, bundle it's version of the OS with other products (like hardware), and use it's marketing power to bring attention to the combined package. The enhancements Sun made to the BSD code remain proprietary, and Sun remains free to incorporate any of the enhancements made to any of the BSD OS derivatives into Solaris. Solaris is a fine program, but it's users have none of the advantages of an open source operating system available to them. To get open source, they must abandon Solaris. Had the original BSD OS been licensed under the GPL, Sun would have been required to share it's enhancements. The various derivative BSD OSs would have incorporated Sun's enhancements, would have a better product, and would have a larger market share. At this point in time, it appears unlikely that any of the open source BSD OSs will ever achieve a larger market share than Solaris, again, regardless of technical merit. (The only possible hope of the open source BSD OSs is that the GPL licensed Linux OS puts such pressure on Sun that they cease to development on their proprietary OS. The prospects of this are very dim.)

It is in a program maintainer's best interest to that the program be as widely used as possible. If your looking to employ someone to install, use, or enhance a program the person you want is the person who maintains the program. Because the GPL works against marginalization and takeover it is the more popular license, whether by developer's choice or by simple survival in the marketplace no one knows.

> Obviously, the government is not a company. Should the government
> distribute its GPL software with other agencies, countries or NGO's, are
> all concerns and terms of the GPL relevant?

This should be evaluated on a case-by-case basis, the value of the intellectual property the government has added to the GPLed software to be balanced against the perceived gain the U.S. obtains by sharing. The government should have the same concerns as any business when it comes to sharing. Although the impact of governmental sharing, and governmental decision making in general, is larger than that of any one business, the fundamental trade-offs remain the same, with one caveat, America is dedicated to an open society. Reveal too much and your weaknesses will be taken advantage of. Hide too much and you stagnate and smother, in bureaucracy, inefficiency, and corruption. In our evaluation we should remember that as an open society our strategy is to reveal our weaknesses so they can be corrected. Not only has it worked so far, it's the society we've fought to keep.

The Government is as bound by the terms of the GPL as it is by the terms of any other software license.

> General
> What areas regarding this debate do you think need further study.
> Please explain why.

Government grants are given to universities and corporations for research which results in intellectual property owned by the university or corporation. There is good reason for this, research results were not making their way into the market because they were in the public domain and hence no profit could be derived. Given that open source licenses are in some sense a middle ground between the public domain and private ownership, and that it's clear that open source licensed intellectual property does succeed in at least some marketplaces, a study should be done to determine whether or in what areas the public would be better served by funding research and requiring the results be placed under an open source license.

What does not need study is "open source software". Each software program or system should stand or fall on it's own merit, including the appropriateness of it's license in the analysis of the appropriateness of the software. It should not matter whether the license is open source or proprietary. It should be kept foremost in mind that studies like the one I propose above are messing about with the governments promotion of social goals, something I believe should be kept to a minimum.

-----Original Message-----
From: Karl O . Pinc [mailto:kop@meme.com]
Sent: Sunday, June 02, 2002 11:00 PM
To: Ken Brown
Subject: Secrecy is not security

> National security systems must be secret. Anything or anyone that
> poses
> any type of indiscreet sharing is an inherent threat.

Again, secrecy is not security. (It _can_ be, but isn't always.)

The USSR had lots of secrets. So much so that they had guards on every xerox machine. Did this secrecy strengthen or weaken their national security?

Karl

Karl O. Pinc started programming in 1975, and his professional programming career began in 1980. He founded The Meme Factory Inc. a software design and consulting company in 1992 and has worked with Linux since 1994.

"Commentary" articles are contributed by Linux.com and NewsForge.com readers. The opinions they contain are strictly those held by their authors, and may not be the same as those held by OSDN management. We welcome "Commentary" contributions from anyone who deals with Linux and Open Source at any level, whether as a corporate officer; as a programmer or sysadmin; or as a home/office desktop user. If you would like to write one, please email editors@newsforge.com with "Commentary" in the subject line.
Links

1. "Karl O . Pinc" - mailto:kop@meme.com
2. "press released linked on NewsForge" - http://newsvac.newsforge.com/article.pl?sid=02/05/31/1017224&tid=52
3. "a letter in return" - http://software.newsforge.com/comments.pl?cid=14956&sid=24112&tid=2
4. "another, longer, letter" - http://software.newsforge.com/comments.pl?cid=14957&sid=24112&tid=2
5. "yet another letter" - http://software.newsforge.com/comments.pl?cid=14959&sid=24112&tid=2
6. "Here's a link to the AT&T Web site" - http://www.bell-labs.com/history/unix/sharing.html
7. "BSD Unix" - http://www.oreilly.com/catalog/opensources/book/kirkmck.html
8. "The Meme Factory Inc." - http://www.meme.com/
9. "OSDN" - http://osdn.com/
10. "editors@newsforge.com" - mailto:editors@newsforge.com

0 Comments:

Post a Comment

<< Home


Get Firefox!