Xtreme testing for Delphi programs

A standard testing framework for Delphi has been long overdue. Now there is one and it's even open source.

In my article on Xtreme testing, I talked about how it could improve the quality of programs as well as the speed and confidence with which they were developed. For the examples, I used Kent Beck and Erich Gamma's JUnit open-source testing framework and I wrote the program fragments using Java -- a language I'm comfortable with. But those who know me from previous writing gigs or my once-frequent postings in online forums know that I've long been a Borland Pascal programmer. My online buddies are probably wondering why I didn't write the examples in Object Pascal. The reason is that I discovered Xtreme testing only recently, and, as far as I know, there are no testing frameworks available for Delphi.

But we're about to change that.

I've been choosing the latest version of Borland's Pascal as the best solution to most of my programming needs for 15 years now. The reasons are varied. The tool's suitability to the kind of applications I've been developing is one reason. Its overall quality is another. Not to mention its blazing instant-feedback speed. A large reason has been the community of developers that has gathered around the tool.

I met that community when I joined CompuServe and the BPASCAL forum back in 1993. BPASCAL quickly became an invaluable asset. The forum was filled with excellent questions, prompt answers, expert advice, and loads of useful source code. Examples, workarounds, patches, libraries, frameworks, and even complete applications were available for download and free use. The forum's motto was "Don't pay back -- pay forward," and these guys took it seriously. I started contributing advice and source code as soon as I was confident enough to do so, and eventually became expert enough to start writing about Delphi for trade publications -- but that's another story.

Even after all these years I have never felt that I had managed to fully pay back -- er, forward -- all the help. That's the reason for this contribution: DUnit, a port of the JUnit Xtreme testing framework to Delphi.

Porting from JUnit

The original JUnit framework is extremely easy to use and very effective. I wanted the Delphi port to be as good.

To speed up the port, I decided to translate the classes and interfaces in JUnit almost literally. It was a compromise that required heavy use of method overloading, which means that DUnit won't be usable with versions of Delphi prior to version 4.

I made another compromise. I could translate the methods in JUnit almost literally if I used the Delphi port of the Java collections library that I had begun implementing, so that's exactly what I did.

These two decisions let me do the port in a single afternoon and resulted in a framework that I find very easy to use. But the implementation relies heavily on interfaces and iterators -- idioms seldom used by Delphi programmers. Although the first idiom is fully supported by Delphi, most programmers reserve it for dealing with COM and ActiveX objects. Interfaces provide the advantage of memory management by reference counting, so a little work up-front with interfaces translates into much less code to write. You do have to be careful with some interface implementation issues. For example, a loop with references to interfaces will make it impossible for Delphi to reclaim the memory used.

The second idiom is common in Java and C++ programs, but may be unfamiliar to Delphi programmers. Iterators enable you to write implementation-independent loops that process the objects contained in a collection. JUnit uses iterators, so DUnit does too.

Classes that test classes

To apply DUnit to your Delphi programs, you write a descendant of the class TTestCase for each test case you want to apply to a unit. I decided to apply DUnit to the collections library used in its own implementation. To avoid circular unit references, I had to declare the test case classes in the main program (DPR) file, but I recommend that in general you place the test classes inside the units they test. Doing so will let you test protected and private methods in addition to the public and published ones.

This is the class declaration for a simple test case:

type
   TListTests = class(TTestCase, ITest)
   published
   // published, so we get RTTI;
   // virtual, so the compiler
   //              doesn't eliminate them;
     procedure testEmptyArrayList; virtual;
     procedure testEmptyLinkedList; virtual;
     procedure doEmptyTests(list :IList);
     procedure testFailure;              virtual;
     procedure testError;              virtual;
  end;

The first two methods test several conditions on arrays and linked lists. The third procedure is a utility used by the preceding routines. The last two methods generate a test failure and an exception respectively, to make sure DUnit responds properly when errors are detected. The test methods must be declared within a published section so that Delphi generates runtime type information for them and DUnit has access to method names at runtime. Here's part of the implementation of doEmptyTests:

procedure TListTests.doEmptyTests(list: IList);
var
 i :IIterator;
begin
   assert('isEmpty', list.isEmpty);
   assertEquals('size', 0, list.size);
   assert('iterator at end', not list.iterator.hasNext);
   list.add('anItem');
   assertEquals('size', 1, list.size);
   //...

Yes, writing the test cases is that easy. Each line in the test method checks (asserts) a condition that should be true if the tested code is working properly. DUnit provides several different assertXXX methods to make writing tests easier.

Pulling it all together

To assemble all the test methods into a single test suite, you write a function like this:

function suite :ITestSuite;
begin
   result := TTestSuite.Create;
   result.addTest(TListTests.Create('testEmptyArrayList'));
   result.addTest(TListTests.Create('testEmptyLinkedList'));
   result.addTest(TListTests.Create('testFailure'));
   result.addTest(TListTests.Create('testError'));
end;

Finally, you run the tests in console mode with a single statement in the main program block:

begin
   DUnit.runTest(suite, true);
            end.

Oops! Two bugs in the collections library surfaced while I was executing the tests. So the framework has already paid for the effort I invested in it. After fixing the bugs and running the tests again, the output looks exactly as expected:

DUnit: Testing.       
...F.E
Time: 0.0         
FAILURES!!!
Test Results:
Run: 4 Failures: 1 Errors: 1
There was 1 error:
 1) TListTests.testError: EAbort: Raised exception on purpose
There was 1 failure:
 1) TListTests.testFailure: AssertionFailedError: Failed on purpose
       
Press [return] to continue.

A license to test

What are the licensing terms for DUnit? In open source development, when you enhance, fix or port someone else's code, it is customary to:

• Give as many rights to the original software as the original authors did.
• Give the same rights to your contributions (some licenses, such as the GNU GPL, require that you to do this).
• Give credit to the original authors for their work.
• Preserve all disclaimers made by the original authors, in particular those about lack of warranty and protection from their names being used for promotion without authorization.

The license to the original JUnit is very flexible, so I made the license to DUnit almost an exact copy of it. The part about your rights reads like this:

Permission to reproduce and create derivative works from the Software ("Software Derivative Works") is hereby granted to you under the copyrights of [...] (THE AUTHORS). The authors also grant you the right to distribute the Software and Software Derivative Works.

Next steps

As it stands, DUnit lacks any documentation. If you can read Java code, then the documentation that comes with JUnit is probably sufficient.

At this time the following still needs to be done:

• Create a GUI interface to the framework like the one JUnit has. Given Delphi's GUI capabilities, this shouldn't take more than an hour or so.
• Use Delphi's RTTI to build a test suite automatically by gathering all the methods with names that start with "test." JUnit does this, and the feature is very useful. I'll leave this task to someone else.
• Translate JUnit's excellent documentation and examples to Delphi.

If you'd like to contribute to the DUnit project, please do so. But try to refrain from sending me suggestions. What I think should be done in DUnit I will likely do, time permitting. As Linus Torvald says, I'd rather you "show me the source code!"

Oh -- the source code! You can download the source code to the latest version of DUnit from my always-under-construction Web site: http://www.suigeneris.org/dunit. I hope you find this small testing framework useful. If you do, please forget about expressing thanks. Pay forward.

Originally written for In Publishing LLC
Copyright © 1999 Inprise Corp.

The monopoly monster

So Microsoft is a monopolistic monster. What are you going to do, gather the whole village to assault the castle with hoes and pitchforks? Burn it down with torches? Get real.

James Whales' 1931 movie of Mary Shelley's Frankenstein has become an icon of horror cinematography. Fulfilling his personal vision, Dr. Frankenstein creates a living man (or almost a man). Infusing life into the inanimate, the doctor feels a God-like power. "It's alive! Aliiive!" he screams, overwhelmed by the ecstasy that accompanies creation. But Frankenstein's not-quite-human being is intelligent enough to claim a larger space in the world than its maker imagined. The monster's power makes everyone uncomfortable -- even its creator. Power frightens us because the smallest actions of the powerful can have large consequences, and their mistakes can be devastating. The mistakes of Frankenstein's creature, though born of childlike naiveté, quickly become too much to bear. As the film comes to an end, torch-wielding villagers hunt down the monster. The mob sets fire to an old mill where the creature is trapped, and there it presumably dies.

Conflicting viewpoints

Frankenstein and his creation come to mind when I contemplate developers' reactions to Judge Jackson's findings of fact in the Microsoft-DOJ antitrust case. Having found Microsoft to be a monopoly (a kind of monster), the mob has been quick to loudly indict: Tear it to pieces! Restrain it permanently! Confine it! Destroy it!

Voices of reason have also spoken. In his 11 Nov. Developer News article, correspondent Jeff Russell maintains that the case brought against Microsoft holds little water, and that the allegations brought against the company would have been better dealt with in civil court, if at all. Long-term Byte columnist Jerry Pournelle explains why Microsoft's success should be credited mostly to its acting smarter and doing things better than its competitors, rather than to excess of power. PC Week columnist Peter Coffee says, "The judge just didn't get it."

Judging from the results of polls like the one at vote.com, and from most of the "talkback" messages posted in reply to the past two weeks' news, it would seem that Microsoft never did anything wrong -- or that whatever it did, government intervention isn't merited.

On the other hand, you might base your opinion on the anti-Microsoft sentiment that has sparked and grown in the past 10 years. How did the company start getting nicknames like "Microslop" and "M$" in developer circles?

So Microsoft is a monster. What does one do with a monster? What is the reasonable response? How should the company itself view its actions? What is the role of the development community? What does the whole issue seem to predict for the future? Obviously, such questions can't even be considered from the perspective of an angry, frightened mob.

The monster's blunders

It takes no more than a quick scan of the Web to gather a list of allegations against Microsoft. Consumer advocates Ralph Nader and James Love have compiled a series of documents related to Microsoft's anticompetitive conduct. The Web also provides many links to the proceedings of trials brought against Microsoft for anticompetitive behavior; those brought by Sun and by Caldera are two. Microsoft is cited in examples of anticompetitive practices in a couple of university courses on ethics and computing. According to these and other articles, documents, Web pages, and online discussions, Microsoft has indulged in such nefarious practices as: hiding and using to its advantage the undocumented, simpler, and more efficient native system API in Windows NT; preannouncing nonexistent products to discourage consumer purchases of rival goods (vaporware); avoiding or sabotaging open and semi-open standards; creating DLL Hell; delivering badly designed software; and much more.

Dr. Frankenstein's dues

In his article "Making Microsoft safe for capitalism," journalist James Gleick interviews several industry leaders about their opinions on Microsoft. Among those queried is Mitchell Kapor, who was founder and CEO of Lotus Development Corp., the company that produced the best-selling Lotus 1-2-3 spreadsheet application. According to the article, Kapor thinks Microsoft has "thin ethics." Kapor says:

Anything not a direct lie or clearly illegal is OK to do and should be done if it advances Microsoft's tribal cause. This licenses the worst sorts of manipulations, lies, tortured self-justifications, and so on.

Yet in the same article, Gleick suggests that it is not the company's practices that have sparked the anti-Microsoft sentiment, but the perpetrator itself:

Microsoft is hardly alone, of course; plenty of its competitors would play as rough, if they only could. Others in the industry suggest that Microsoft's small-company scrappiness has kept it from facing the issue of corporate ethics. Behavior that people will forgive, or at least understand, in a start-up looks considerably less attractive when David grows into Goliath.

It's not only what the monster does that incites us; it's what the monster is. But can we really expect integrity from a monster? Monster authority Joe Sena, Deaditor-In-Grief of Universal's Online Horror Channel, writes in his June 1998 deaditorial:

Just what kind of vows do [monsters] take, anyway -- "Until dissection or torch-wielding mob do we [sic] part"? Or do sequels render such finality moot?

Should monsters be accountable for what monsters do? Sure. But shouldn't their creators accept part of the blame? "Let's go after Bill Gates!" Many would rally to the cry. But what about all the managers who've said, "You can't go wrong choosing Microsoft"? Or the programmers who've rationalized, "Clients want VB (VC++, MFC, COM), so that's what I give them"? What about the unimaginative computing companies and their "do-what-Microsoft-does" ways? What about the millions of users protesting, "But my friend can't read my documents if they're not from Microsoft Word"? It's a monster all right, but we have all helped create it.

The face in the mirror

According to the script, this is the point where I declare the verdict. What penalty do I think the court should impose against Microsoft's recurrent abuses? No penalty. Nothing at all. Leave Microsoft alone. Ignore it. Microsoft succeeded in an industry that has been continuously inventing itself for the past 20 years. It succeeded where better-established companies that had started on a better footing fared worse, or even failed. What good is a computer on every desk if people can't exchange letters and spreadsheets? In a world begging for data and usability standards, Microsoft provided them: its own. After all, as far as standards are concerned, there can be only one.

For the U.S. government to act against Microsoft in court would be like taking the guillotine to our own creation. It would be too much, too late. The computing world in which Microsoft was nourished (on which it fed?) no longer exists. Along with the ubiquitous and global Internet have come new ways of setting standards. These days, more than market power is needed to influence the Internet's evolution. The fastest-growing area of computing is that of interconnected, wireless appliances and wearable devices. Microsoft has a long, long way to go before its presence is felt there. Then there's the open source movement. Microsoft has yet to demonstrate that it can negotiate the rapid transition from software royalties into services. And we've yet to see how Microsoft and the users of its products will fare once the new year arrives.

One thing is certain: We shouldn't be scared of monsters anymore. If you're still concerned about Microsoft's power, there are things you can do. For your next project, why not base your choice of development environment on merits, rather than on market share? Why not get hold of a Linux distribution and learn to use it? How about learning to program on it? How about supporting more portable and open programming languages like Python, Perl, and Java? How about choosing something different from Windows to run the gadget you're giving yourself for Christmas? As we often tell kids, just ignore the monster and it will go away.

Originally written for In Publishing LLC
Copyright © 1999 Inprise Corp.

Java biking

Launching a full-blown IDE for a brief Java programming excursion can be like driving the car to a nearby shopping mall. If you have ever imagined the equivalent of a Java bicycle, your fantasy may have come true with BeanShell v. 1.0.

I'd just moved to Davis, California, and it was the first time I'd gone shopping. I parked my bicycle in an empty rack, dashed in, grabbed the few things I needed, and found a checkout register.

"Pehperohplahstig."

"Sorry?" The salute was unexpected, and the tinny accent of the northern-California girl didn't help.

"Paper-or-plastic?" she repeated, more slowly this time. But it wasn't until the third time that I understood.

"Oh! Paper bags will be OK. Thanks."

The reply "You bet!" was another surprise, but I didn't ask for translation. I paid, gathered my stuff, and hurried out, glad I could cycle home quickly with my groceries.

As a young programmer, I was always in a hurry, and if there's a heaven for bikers, it is the little town of Davis. My apartment was well within walking distance of the shopping mall, but I preferred to ride. It took only a few minutes to reach the mall by bike, most of them spent waiting at the Russell Avenue crossing. Driving would have been overkill for such a short trip -- especially considering the effects on the ozone layer -- and probably the most time-consuming of the options.

I've often felt that launching a full-blown development environment for a brief Java programming excursion is like taking the car out to go to the nearby mall. Yet going about with just a text editor and the command line compiler seems too cumbersome, too much like going on foot -- especially if the task at hand is not trivial, or if it's one of those days when one out of ten key-presses is a typing error. The solution I've imagined would be something equivalent to a Java programming bicycle.

I went Web-spelunking and found a beta version of what promised to be the ideal solution to my short programming excursion needs -- someday. Then, just a couple of weeks ago, I was notified by e-mail that BeanShell 1.0 was available. I decided to take the tool for a ride.

BeanShell 1.0

BeanShell is a small interpreter written in Java by Pat Niemeyer. It executes standard Java statements and expressions in addition to several scripting commands. The tool supports scripted objects as simple method closures like those in Perl and JavaScript. BeanShell is open source and free to use under the terms of the GNU General Public License.

BeanShell comes with both GUI (Swing) and console mode interpreters. The GUI interpreter provides command history recall, command line editing, cut and paste, support for multiple sessions, and a simple editor for scripts.

The language interpreted by BeanShell is very similar to JavaScript. There's no need to declare variables or parameter types; the tool does type checking at runtime. Any class, object, or method available to the Java interpreter can be accessed from within BeanShell using standard Java syntax. The interpreter understands Java import statements, and it provides a convenient syntax for accessing Java Bean properties. External commands can be invoked from within the interpreter using the exec command, so you can also access other tools, like your favorite editor or the Java compiler, from within the shell. Several other useful commands and variables -- such as dir, print, and cwd -- are provided by default, and the built-in command set can be readily extended using either BeanShell scripts or Java.

BeanShell can also be embedded into your applications to provide them with scripting functionality. The core interpreter, with all console functionality removed, fits in a 135K Jar file. The tool also provides a "server mode," which allows for remote access to the interpreter using HTTP. Upon gaining access to the specified TCP port, BeanShell will send back a remote console applet that can be used to query or change the state of the running application in which BeanShell is embedded. It's also possible to talk to the interpreter in terminal mode by using the Telnet protocol.

The documentation, which is available from the BeanShell Web site, includes the script language's syntax, the built-in commands, and instructions for installing, running, and embedding the tool. A set of JavaDoc pages covers the product's internal API. There is a mailing list for BeanShell users and developers on the site as well.

With BeanShell at hand I can easily experiment with libraries and classes I develop or download from the Internet without recompiling, and without bothering to set up a new project in the IDE. As it turns out, my Java bike was not just a fantasy after all.

Originally written for In Publishing LLC
Copyright © 1999 Inprise Corp.

Y2K: the beginning of the end?

Will open source software development be smothered by the patents avalanche or help to end it?

As Developer News correspondent Constance Petersen discussed in her article last week, 5 Nov. was Burn All GIFs Day. The protest was organized by a group of open-source developers and Webmasters opposed to the way Unisys has exercised the patent it holds on the LZW compression algorithm used in GIF files. The group proposes getting rid of all GIF files and substituting files in open graphic file formats such as PNG.

Creating Burn All GIFs Day is just one of the actions taken by just one of the groups who think that the patent system, as it applies to software, is being abused.

Another event brought attention to patents last week. As CNET reported, McDonnell Douglas received a patent for "windowing," one of the most widely used (and intuitively obvious) Y2K problem-fixing techniques. The company has handed the patent over to Bruce Dickens, the technique's inventor. Dickens's attorney will reportedly contact Fortune 500 companies whose programmers have employed the patented technique to request payment and negotiate licensing terms.

Aren't patent registration and enforcement just business as usual? Doesn't the owner of a patent have the right to exercise it at will? Yes, of course. But the issues related to this news are not about the patent system per se. They revolve around the questionable validity of specific patents and their effect on software development in general -- and especially, perhaps, the development of open source software.

The patent purpose

According to the text of most patent legislation, the main purpose of the patent system is not to protect inherent, abstract rights, but to enhance the common good by promoting the advancement of the arts and sciences. The system works like this: The government grants inventors legal monopolies over specific inventions and helps enforce the monopolies. In return, inventors agree to publish the details of their inventions and relinquish control over the inventions after a specified period of time.

Inventors benefit because the government-enforced monopoly gives them a better chance of recouping the expenses they incurred while developing their inventions. Society benefits because the common pool of useful knowledge is constantly augmented, and because everyone has free access to inventions after patents expire. Patents are a good idea, especially if you consider the consequences of the alternative -- inventors trying to keep their inventions as secret as possible.

Not all patents are good deals for society, and the law foresees that. To be awarded a patent, an invention must be novel; the inventor must have been the first to invent that particular thing or method. It must also be non-obvious, meaning the invention can't be a clear extension of something that is already known. Granting patents for non-novel inventions (prior art) would allow the imposition of royalties on methods and practices that have been in wide use, even for a long time. Patents for obvious stuff -- things that anyone with the right background could have invented -- are a bad idea and are therefore not granted.

So what's all the fuss? The problem according to analysts, is that patents are being granted in increasingly large numbers for obvious and non-novel inventions, which defeats the whole purpose of the patent system. The problem is exacerbated because, as intellectual property attorney Steven Young explained in a recent Slashdot feature, there is no reasonable way to protect against patent liability. Becoming informed about the millions of patents, even just the subset that is relevant to your business, is not at all easy. Patents related to very specific areas of knowledge number in the tens of thousands. Some conservative estimates predict that 100,000 new software patents will be granted this year in the United States alone.

Not a target, but a cure

The League for Programming Freedom site at MIT offers a wealth of information about the patents problem and how it affects software development. The LPF predictably opposes software patents altogether, but the information on its site about the use and abuse of patents is interesting even if you don't share their views.

To protect themselves against the patent avalanche, large companies seem to be filing for patents on everything imaginable. The strategy is to use patents as legal weapons against the dubious patents of others, but this practice is only serving to make the problem worse. Patent portfolios are being created mainly as a means of defense, but some developers have begun to worry about what could happen to the open source movement if companies decide to try to enforce their patents -- which exist for Save As commands, multicolored option lists, and other code elements -- against software projects like Linux.

Is that likely? I don't think so. Some of the companies that hold large patent portfolios (most notably IBM) have already positioned themselves strongly in support of open source software, and they're likely to defend open-source projects. Because of the open, collaborative nature of open-source efforts and the peer-recognition culture behind them, many open-source projects maintain detailed logs of who did what and when, and where further information about the techniques and algorithms used can be found. Those logs may be some of the best documented proof of previous art that can be used in court to challenge questionable patent claims. Open-source software would not become the target of the patent craze, but a good part of the cure.

Curbing the craze

The windowing technique patented by McDonnell Douglas interprets years expressed in two digits as belonging to century 2000 if the value is less than a specific, context-dependent threshold. For example, "15" is interpreted as "2015" instead of "1915," while "90" is interpreted as "1990." Windowing is a popular fix for Y2K problems because it is simple to understand and often easier to implement than other kinds of fixes.

Is the patent on windowing valid? That will be for the courts to decide. The U.S. lacks administrative procedures to challenge a patent after it has been granted, so the issue must be resolved in court.

Meanwhile, companies that have used the windowing technique are legally bound to comply with the conditions set forth by the patent holder. Abandoning the software or implementing a different fix so close to the dreaded Y2K date is out of the question. Neither the lack of knowledge about a filed patent nor the intention to challenge it is a legal basis for infringement. Analysts contacted by CNET predict that larger companies will just pay the fees and write them off as part of their Y2K compliance expenses, but smaller companies may want to fight the patent in court.

Even if the patent on windowing is valid, pursuing its enforcement so close to a global death-march deadline seems like placing the sword at the throat of someone who's already against the wall. It has the sour taste of extortion about it. It's far from clear if and how society can benefit from patents like this.

There's a chance that the Fortune 500 giants will join with the smaller companies to try to set legal precedent against dubious patents. Maybe Y2K will mark in more than one way the beginning of the end of the patent craze.

Originally written for In Publishing LLC
Copyright © 1999 Inprise Corp.

Programmers or entrepreneurs?

When royalties are out of the question, programmers find innovative ways of earning profits, such as providing value-added services. New ways of making business out of open source are being invented every day.

"Amateurs!" That's what critics call open-source programmers. And sometimes they really mean "hackers": those who lack the knowledge and attitude required to do the job well. Well, open-source software is open after all, and anyone, knowledgeable or not, can take a "hack" at it. But the quality of open-source software like BIND or Sendmail (on which the Internet lives and breathes), or of the many components of Linux distributions, leaves no room for doubt: these guys know what they're doing.

More frequently, though, the term "amateur" is used in contrast to "professional"; it distinguishes those who work at something for fun from those who do the job seriously -- for a living. Last week I suggested that those who perceive open-source programmers to be mere hobbyists were in for a big surprise. Well, surprise!

Case studies

Many open-source advocates are entrepreneurs. As many of you know, open source has already produced its first round of millionaire techies with Red Hat's initial public offering. RedHat assembles and tests the thousands of parts that compose a Linux distribution, selling the CDs and installation support through retail channels. The company also sells support and consulting services to corporate Linux users and distributors. The RedHat IPO is special in that recognized open-source developers had the opportunity to get their share of the deal through eTrade's online brokering service. Other companies, such as Turbo Linux, are working eagerly to get on the same train as RedHat.

VA Research has made it to the end of the rainbow by selling pre-configured hardware, as well as support and consulting services to help make the most of open-source software, especially Linux. VA Research is reportedly one of the fastest-growing companies in the US. There are several other large companies and many smaller ones that provide services like those of RedHat and VA Research.

Companies like O'Reilly make money selling printed versions of open-source documentation, and publications like Linux Journal, Linux Magazine, and other printed and web-based publications feature articles about Linux and other open-source software, profiting from the sale of ad space. Some of these publications become desirable acquisitions because of their large reading audiences. Such is the case with Linux Today, an online publication featuring a collection of Linux news headlines drawn from the printed and online press. The business was acquired last month by the larger internet.com. At five million page views and 400,000 users per month, Linux Today meant business.

There are many other examples of businesses profiting in various ways from open source. News of startups, acquisitions, and IPOs arrives at an almost daily rate. You can check out Linux Today to keep informed.

In their own words

"But those are entrepreneurs," you might object. "What about the programmers? Are they profiting from open source?"

Well, I sought a couple of them out for comment. I caught Greg Wilkins of Mortbay Consulting Ltd. just before he left for a vacation trip. Greg is author of the feature-rich and very successful Jetty, an open-source Web, Servlet, and JSP server written in Java. (Note: I've contributed both code and advice to the development of Jetty.)

I asked Greg if Jetty was contributing to his company's revenues and, if so, how.

"Jetty contributes very little directly to our revenues -- a few support contracts only. However, there is a big payback in terms of our consulting work," he replied. "It is a great reference and an excellent introduction to our work, and that keeps our down time to a minimum. But the big payoff comes from our work on projects using Jetty, for which we receive full consulting rates -- in London and Sydney, that's 25 to 75 percent higher than normal contracting rates."

I also asked Greg why he had decided to make Jetty open-source, and what had been the net business effects of that decision.

He told me that he had written Jetty as an entry to the original Java programming contest sponsored by Sun, and that it had won the Australian prize. For a few years his company reserved the rights to commercial use. As a consulting company, though, it had neither the resources nor the motivation to become strongly product-oriented.

"We decided that the best way to profit from Jetty was to make it as widely used as possible," Greg confided. He said this allowed them to get assistance with its maintenance and they believed its quality would improve through community involvement. Greg added, "And we were right. Jetty has easily paid for itself many times over."

I also approached Chad Hower of Phoenix Business Enterprises, with whom I had recently had an e-mail conversation. Chad is the author of the Winshoes open-source set of Internet components for Delphi. I asked Chad the same questions I'd asked Greg.

"Marketing developer tools is very hard," Chad told me, "especially those targeted at single-vendor development environments like Delphi. There is easier money to be made elsewhere. Winshoes, like other projects of mine, was more a product of need and love of programming than anything else. There were no good Internet components for Delphi when I wrote Winshoes."

Chad felt that trying to market Winshoes would have been risky. His time, he explained, was better spent at what he did best: software development. Having nothing to lose, he made Winshoes opensource as an experiment. What has happened since has far exceeded his initial expectations. Winshoes has brought the company many contract offers, as well as frequent requests for Internet consulting work.

"Many developers just sit on code like this," Chad observed. "I encourage them to make the sources open and see what happens. There's nothing to lose, and a lot to gain."

Greg and Chad are using open source as what some call a "loss-leader": something that you give away to enable further business opportunities. Along similar lines is Digital Creations, a "web solutions" company which built its success on the full-featured applications server currently known asZope. Feeling some growing pains, Digital Creations decided to go after a little venture capital. Finding an investor was surprisingly easy. Even more surprisingly, the investor recommended making the flagship product open source. Digital Creations' value, he suggested, was its know-how. The company concluded that making Zope open source could only open new doors for them -- and it did.

Show me the money!

But those are all entrepreneurs. They're not programmers, are they?

Yes and no. Most of the entrepreneurs behind the companies I've mentioned are open-source programmers, though I'd bet that they currently don't get the chance to hack as much as they did in the past. What you really want to know about is the guys actually pounding out the code, right?

Companies such as RedHat routinely recruit open-source programmers to enhance different aspects of Linux. Because these enhancements go back into the pool of shared open-source code, the direct advantages RedHat gets from them are short-lived. The indirect advantages derive from participation in the larger market that the enhancements help to create. RedHat and others seem to believe that these advantages outweigh the costs.

O'Reilly funds open-source software and software documentation efforts, and hires or contracts open-source software developers to serve as writers and technical editors. Writing and publishing books of their own is another source of income for open-source developers.

All of the companies mentioned above have technical positions staffed with open-source programmers.

Not that open-source developers have much trouble landing programming jobs. Having your name and e-mail address listed in the credits of the Linux kernel, a hardware driver, or a file system implementation seems to be a much better reference than a well prepared résumé -- you may even skip the cover letter. The jobs that these programmers seek and get are frequently compatible with their open-source work.

And don't rule out private funding as a source of income. Who would give money to a bunch of hackers to pound out software that will ultimately be available for free? The answer is companies that get more value out of open source than what they invest in its sponsorship. One such case is the Apache project, started and still funded by a group of Internet Service Providers (ISPs). The group wanted an efficient, reliable, and cost-effective HTTP server whose development they could at least partially control. Universities are also among the institutions funding open source; it helps them reduce costs, and they benefit academically as well.

Last but not least are the cooperative open-source initiatives like sourceXchange and CoSource. These start-ups call themselves "open-source marketplaces." They provide an online infrastructure to connect open-source programmers with those interested in sponsoring open-source projects. Any party -- company or programmer -- can either propose an open-source project or sponsor one by committing a certain amount of money. Programmers respond with proposals for the projects they want to take. Ideally, the process will result in cooperative funding for interesting projects and payment for programmers, all under the constant supervision of the marketplace. All software produced goes back to the shared pool as open source. It's a whole new way of software contracting; we've yet to see were it will lead.

Software: a service industry?

It takes little research to discover that the question is not who's making money from open source, but who isn't. With royalties out of the question, those involved in open-source software have found innovative ways of profiting, either by providing some sort of value-added services or by making important savings based on open source. And new ways of making business out of open source are being invented every day.

Open-source evangelist Eric Raymond -- who became well known for his disclosure of Microsoft's Halloween documents, and is now famous for his analysis of open-source culture in The Cathedral and The Bazaar -- has written a new paper analyzing the economics of open-source software. In this paper Raymond proposes that software is "largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry," and that the "use value" of software far exceeds its "sale value," as evidenced by the large percentage of software created for in-house use versus the very small percentage written to be sold as merchandise.

Some of you may mistrust Raymond's views because he's patently within the open-source inner-circle. Perhaps you'll find Steve Ballmer, president of Microsoft, more convincing. "Literally, if you go out seven to 10 years from now, not only our business but every software business will have to remake itself into what I call a software service company," Ballmer predicts in a recent interview with CNN Financial.

In the same interview Ballmer also mentions that Microsoft was considering "a modified form of open sourcing" that would allow their customers access to some code. This would let the customers "try to solve their own problems." (Not that Microsoft "customers solving their own problems" is anything new.)

Is the move away from royalties and into value-added software services something fueled by the open-source movement? Or does the so-called friction-free economy of the Internet have anything to do with it? Will the changes only affect programmers involved in commercial software, or do corporate programmers also need to re-evaluate their situation?

Drop me a line with your thoughts at juanco@inpublishing.com.

Originally written for In Publishing LLC
Copyright © 1999 Inprise Corp.

The lesson of Agincourt

Open source programming underdogs may have more advantages than their critics imagine. But whether they win or lose in the end, it's their story that inspires.

Giving away software is a "strategy of the weak." At least most business analysts consider it so when comparing the strategy against the "embrace and extend" strategies used by powerful software houses like Microsoft.

But let me tell you a story that took place 584 years ago today. A story about the weak and their strategies.

Act I

On October 25, 1415, on Saint Crispin's day, a troop of tired, sick, and hungry men -- the unquestionably weak -- defeated an enemy who not only outnumbered them four-to-one but who fought on their own turf. It was at the Battle of Agincourt, when King Henry V led his troops into one of the greatest victories of military history.

Six thousand English soldiers were marching in retreat. Their destination was the safe port of Calais, from whence they hoped to escape to England. They were intercepted at Agincourt by French Constable Charles d'Albret and a French army 25,000 strong, including armored cavalry and infantry. Annihilation of the English troops was imminent; they had no advantages -- except for the rain. It rained, and rained, and rained, and the battlefield became a quagmire. Mired in mud, the French cavalry were easy prey for the English archers. The heavily armored infantry men slipped and fell. Struggling to rise they were cut down by the hatchets, hooks, and knives of the highly mobile English raiders.

For every Englishman killed, 25 French were slain. Some 500 French noblemen died on the field. The victory paved the way for English domination of most of France until the middle of the century.

Act II

Like the Constable d'Albret at Agincourt, most open source detractors misjudge the present situation.

They misjudge open source programmers, accusing them of amateurism and claiming that their only motivation is peer recognition. Critics also jump to conclusions about where and how these programmers earn their income, and about their knowledge and skills. The critics are in for a surprise.

And like d'Albret, analysts misjudge the battlefield as well. Today's internetworked world is fundamentally different from that on which the current software giants built their empires. And things are changing rapidly. Today, news of friends or foes, features or bugs, span the world in a matter of hours. Things are fundamentally different when anyone can post a question, and receive more than one authoritative answer from people across the globe. Things are fundamentally different when even your teenage son is among the ones posting the answers. Things are fundamentally different when the computer I carry in my waist pack is several times more powerful than the computer I learned to program on. It's raining folks. It's pouring!

Epilogue

Business analysts comment with a sneer that it's easy to double your market share every year when you start from zero. They speculate about what will happen when the software giants feel their territory threatened and decide to charge. They predict victory for the corporations; the apparently strong. But in the fast-changing world of the Internet, the advantage may well go to those who are flexible, agile, free from corporate inertia, and brave enough to take the risks.

The Hundred Years War, of which Agincourt was part, was eventually won by the French, and the English were expelled from French territory. But the legend of the victory at Agincourt lives on.

Likewise, the final outcome of the battles between the open source advocates and traditional business may not be the most important thing. It's the tale of open source and of the souls that fight for it that inspires, and will therefore last.

This story shall the good man teach his son;
And Crispin Crispian shall ne'er go by,
From this day to the ending of the world,
But we in it shall be remembered;

We few, we happy few, we band of hackers;
For he today that shares his code with me
Shall be my brother; be he ne'er so vile,
This day shall gentle his condition:

And programmers of closed source now a-bed
Shall think themselves accurs'd they didn't code,
And hold their skill sets cheap whiles any speaks
That coded with us upon Saint Crispin's day.

By Juancarlo Añez with apologies to William Shakespeare

Originally written for In Publishing LLC
Copyright © 1999 Inprise Corp.

Xtreme testing

Extreme programmers brave the open source slopes.

You can't do it. You can't add the feature. It's too risky. You'd have to change a core part of the program, and who knows what kind of subtle bugs might creep in doing that? You got hold of the source code and made sure that the license allows you to modify it, but it's too dangerous. Isn't it?

Well, the proponents of Extreme Programming say not only that you can, but that you should!

Extreme programmers aim for code that's small, lean, mean, and functional. To achieve the lean and mean, x-programmers always do the simplest thing that could possibly work. They resist the temptation to implement stuff that may be useful later, because they assume they're not going to need it. X-programmers are fearless about modifying the code, so their software is always functional. They will edit, refactor, or reimplement even large sections when they need to add a new feature.

But what about the risks? What about the bugs? The extreme programmers' answer: extreme testing. They write a test case for every feature they implement, even before they start coding the feature. Need to add new functionality? Write a test case. Found a bug? Write a test case. Have doubts about how something really works? Write a test case. The set of test cases thus produced serves to guarantee that the system keeps doing what it should even after important modifications. X-programmers run the whole battery of tests after each change, and they never release the code until all the test cases run flawlessly.

Extreme testing produces a large number of test cases, and the process of running all the tests and evaluating the results could get unwieldy. X-programmers use automation to keep extreme testing under their control. They have written testing frameworks for Java, C++, and several different flavors of Smalltalk. The frameworks are all freely available from the XProgramming software page. The Java testing framework provides one example of how extreme testing can be used.

JUnit

JUnit is a small testing framework written in Java by Kent Beck and Erich Gamma. Beck and Gamma are well-known as two of the founders of the Software Patterns movement, and this shows in the design simplicity of JUnit. Using JUnit to test Java programs is very easy. You start by writing a descendant of junit.framework.TestCase. This is an example from my Java Diff package:

import junit.framework.*;
public class DiffTest extends TestCase {
public DiffTest(String testName) {
super(testName);
}

public void testDeleteAll() {
Revision revision = Diff.diff(original, empty);
assertEquals(revision.size(), 1);
assertEquals(revision.getDelta(0).getClass(), DeleteDelta.class);
assert(Diff.compare(revision.patch(original), empty));
}
//...


Each method in a test case exercises a different aspect of the tested software. The aim, as is customary in software testing, is not to show that your program works fine, but to show that it doesn't. Interaction with the JUnit framework is achieved through assertions, which are method calls that check (assert) that given conditions hold at specified points in the test execution.

JUnit allows for several ways to run the different tests, either individually or in batches, but the simplest one by far is to let the TestSuite collect the tests using Java introspection:

    public TestSuite suite() {
         return new TestSuite(DiffTest.class);
     }
     //...
     TestResult result = DiffTest.suite().run();

When a class is passed to the constructor of a new instance of TestSuite, the instance uses Java introspection to find all the methods in the class with names that start with "test." A subsequent call to TestSuite's run method executes all the tests and returns the results as an instance of TestResult. TestSuite also allows the creation of, well, suites, which include any combination of test cases.

For maximum convenience, JUnit provides both text-based and GUI (Swing) user interfaces that facilitate the execution of test suites. Both user interfaces can be run as standalone programs by passing the class name of the test suite to run as the first command-line argument.

JUnit's GUI interface reports progress and results
as the tests are executed.

You can also run the tests from within your favorite integrated development environment (IDE), and have the debugger stop as soon as a problem is found. Your static main method would look something like this:

 public static void main(String args[]) {
     junit.textui.TestRunner.run(DiffTest.suite());
 }

Open tests

Proponents of extreme programming qualify their approach as a "lightweight methodology," to contrast it with the heavyweight methodologies that became popular during the 80s, and that few software projects continue to follow. XP establishes only a small set of common sense rules and practices, and the documentation generated is no more than the minimum required to keep things flowing smoothly. Almost all software development projects, including open source ones, could benefit from some amount of XP.

Why talk about testing and methodologies in an open source column? Much open source discourse is devoted to the "freedom" programmers enjoy to modify open source code at will. The truth is that this supposed freedom is only partial. Most of the open source software one can get hold of lacks the testing infrastructure required to make sure that adding features to the code doesn't also break it. As things stand, open source programmers must devise their own ways to verify the software they change, resulting in an incalculable amount of duplicated -- and mostly wasted -- effort.

Open source projects greatly benefit when they adopt testing policies and a testing framework from the start. Most open source projects do perform formal testing. All such projects would be improved if the numerous test cases produced could be collected and officially distributed. Adopting the test frameworks provided by the XP people is one approach, but almost any other test framework would do.

Extreme testing needs to become an integral part of open source practice. Only then will we truly experience the freedom of working to improve a piece of code without the fear of breaking it.

Originally written for In Publishing LLC
Copyright © 1999 Inprise Corp.

Start the revolution without me

Confused by the ruckus over open-source software? Bobby McFerrin had it right: Don't worry, keep hacking.

Everybody's talking about the "open software revolution." From geek forums like SlashDot to academic journals like Communications of the ACM, from the New York Times to The Wall Street Journal, everyone is saying that there's something important going on.

The leaders of the open-source movement argue that their way of doing things will change the world of software development forever. Detractors question their leadership and attack their ideas on business, logical, economic, political, sociological, and other grounds. The hubbub is rising so fast I've seen good friends worry that open-source software may destroy their way of life by making it impossible to sell software or write it for hire.

I'm not at home with the rhetoric of any of the factions. I'm not a radical, I'm a programmer. You say you want a revolution? You can count me out.

War of the words

Like many programmers, I have used and written open-source software for a long time. I'm glad that we now have a phrase -- open source -- to describe what we've been doing. But I object to narrow definitions that exclude workable, time-honored, and popular practices. Now that we have a buzzword, people are trying to cram political and economic agendas into the term.

There are those, for instance, who argue that open-source development is the solution to all software development problems. But they do so based on information drawn from just a few successful projects. Most of the open-source projects I have tracked over the past 18 months have been cancelled, only to become data points that feed the well-known statistics about the high failure rate of software projects. Methodologies are a dozen for a penny; these projects failed because they never had a feasible business plan.

In the opposite corner are those who see the open-source movement as a threat to the software industry. Never mind that open-source initiatives are law-abiding and -- because of their open nature -- much less likely to fall into the anticompetitive practices that characterize a part of our industry. Never mind that thousands of developers are gainfully employed on open-source projects. Never mind that hundreds of thousands of users entrust their businesses to their work. They are convinced that the sky is falling.

Then there's the debate over "free" software.

On one side are the developers and activists who believe software should not be treated as intellectual property. Or that it should be treated like intellectual property, but developers should waive their property rights.

On the other side are people who oppose free software. Some because they think it's impractical, and some because the initiative seems politically suspect -- too leftish. The extreme left has become extremely unpopular in most circles, and all of this talk of free software smacks of outmoded socialist ideas. As long as those impressions persist, I don't see how the free software cause can make it to a critical mass of supporters.

Intellectual property has been a hairy issue since the invention of speech at least, and intense debates about it precede the Internet era by centuries. The debates are so intense, you have to wonder how any country's founding fathers were able to quiet the ruckus long enough to slip intellectual-property language into their constitutions.

The shouting's so loud, it's tempting to ignore the arguments. But you can't simply ignore the "free" versus "proprietary" software debate -- no more than you would ignore debates between Republicans and Democrats in the U.S. or Greens and Social Democrats in Germany. This debate is truly about ideas. It's worthy of your attention.

It is difficult to write about these issues without making a contribution to the arguments. But I'm determined: I'm not about to take a side on these issues. I do think that open-source development will impact software development in general, and in an important way. But I think that the effect won't be immediate, and it won't be obvious. To know what this "revolution" will actually lead to...well, you have to wait. My take is that the factions will ultimately reconcile.

Strip away the rhetoric and it's clear: There is no revolution. The ideas being argued and shouted are interesting, and important, yes, but their effect will be evolutionary. Like always.

So don't worry. It will be all right.

Originally written for In Publishing LLC
Copyright © 1999 Inprise Corp.

The true meaning behind open source licenses

What does all this licensing stuff really mean?

I develop software for a living, so my position regarding third-party software has always been pragmatic: consider the cost and evaluate how well each solution meets your requirements. Most open source software is licensed free of charge. But does software that is licensed for free really have zero cost?

Property rights -- who has the right to own what -- are at the ideological core of political systems and are one of the fundamental individual liberties in a capitalist society. Software is considered a form of property by law, so talking about software licenses -- including open source licenses -- in that context makes sense.

I'm not a lawyer, so none of my views or interpretations of this matter would necessarily stand up in a court of law. Also, I'm talking primarily about United States copyright law because the copyright licenses I'll discuss were written in the US; the laws of other countries and of the international community might be different.

Property law establishes three basic rights: the right to use, the right to enjoy (profit from), and the right to dispose of the property. When dealing with intellectual property, and more specifically with copyrighted work such as software, such rights are exclusive to the copyright owner. Most software licenses explicitly reference the right to:

1. perform the work -- that is, to execute the software
2. prepare derivative works -- that is, to debug, patch, enhance, or otherwise modify the software
3. make copies of the work
4. distribute copies of the work
5. authorize others to exercise the above rights
6. sublicense the software (charge for it)
7. prevent others from exercising the above rights
8. transfer or license the above rights

I want to analyze several well-known (and some lesser-known) open source licenses in terms of the three basic rights property law establishes and the more specific rights held by copyright owners. Politics and philosophy aside, I want to evaluate what the different licenses mean to someone who develops software for a living, like me.

The licenses I'll be considering are those mentioned at the Open Source Initiative's Web site: the BSD license; the MIT License; the Artistic License; the Mozilla Public License; the GNU General Public License and its lesser form, the LGPL; as well as lesser-known licenses like the Java Community Source License and the IBM XML4J (XML for Java) evaluation and commercial licenses.

In the Public Domain

We should first look at one of the most widely used terms in open source distribution that has not yet been certified by the Open Source Institute: placing the work "in the public domain." A work placed in the public domain has the same legal status as one for which the legal copyright term (usually 50 years after the death of all the authors) has elapsed. This condition is particularly interesting because the rights to use and profit from the work (execute, copy, and distribute the software) can be exercised by anyone, yet the ultimate right of disposing of the work (the right to authorize or restrict other's rights to it) belongs to no one and, therefore, cannot be exercised.

Software placed in the public domain essentially follows the same copyright law as the works of long-dead literary and musical authors. You can perform (execute) the works of Shakespeare, copy them, and distribute them, but remember that derivative works, compilations, and specific performances can have their own lawful copyright owners. You can include public domain software in your own work, modify it, copy it, and talk about it in publications and at conferences. You can't do the same with someone else's work, however, just because it happens to use or contain public domain work. You're otherwise free to derive any profits from public domain software.

Public domain software is unique in that it is the only form of work whose disposal rights are not retained by anyone. Every form of software licensing reserves rights 5, 6, and 7 for some entity, including the right to license work under a different scheme whenever desired. From a business perspective, it's guaranteed that legal claims of copyright violation can not be brought against users of software that is in the public domain.

The least restrictive licensing

Software licensing schemes always reserve the right to dispose of the work (grant, restrict, transfer, and license the rights). This is redundant because licensing can only exist if someone holds those basic rights, unlike work placed in the public domain. All open source licenses have that element in common, but differ in the other rights they grant or restrict.

The least restrictive form of software licensing is that which reserves only the right to disposition. The BSD and MIT licenses, for example, grant ample rights of use, creation of derivative works, and redistribution (as long as the right to dispose of the work is explicitly reserved to the original authors). Included is the right to make different licensing arrangements with whomever the licensee sees fit. The Artistic (Perl) license is somewhat less clear in its section 3, which addresses copying and modification of the original "package," but does not talk about distribution.

Tightening the reins

Most frequently, open source licenses grant ample rights for use of the software and creation of derivative works, but restrict distribution in some important way. The four most common restrictions on distribution are:

• You may only distribute the software and the modifications within your company or institution (an aspect the Artistic License).
• You may only distribute the software and the modifications in object (compiled) form as long as some value-added is provided (the XML4J commercial license).
• You may only distribute the software and the modifications for free (Artistic License).
• You must provide the source to all your modifications, or otherwise guarantee that users of your software can get hold of the source free of charge (the GPL).

These restrictions mainly affect how you profit from the intellectual property. The only restrictions made by the controversial GPL are restrictions on distribution.

Normally, these kinds of licenses don't place restrictions on the work created with the software, which gives such licenses a broad range of uses. This applies to end-user applications -- such as word processors and spreadsheets -- and to most of the tools used in software development, even commercial ones like compilers, libraries, editors, and text manipulation and make tools.

Some other licenses place absolute restrictions on distribution in order to avoid so-called "forking." As a result, most of the enhancements end up in the primary source base. But other licenses restrict distribution just to maintain control over the software. I've known only a few licenses that do this.

The most restrictive licenses

Paradoxically, one of the most restrictive licenses -- the GPL -- is very liberal about redistribution rights. Under the GPL, you can distribute the original work or its derivatives to whomever you like, as long as you make readily available the source to the original work, the modifications you obtained, and any modifications you made. Any licenses you give must also follow the GPL restrictions.

Many source code licenses restrict the use that can be made of the software. Such is the case with the Java Community Source License, which appears to restrict free use to research. Other uses require that compatibility tests be made and royalties be paid. Other licenses, like the XML4J Evaluation License, restrict the use to that which is "lawful and non-commercial." More restrictive licenses grant these rights only for a limited period of time.

Some would argue that source licenses that restrict the use or the creation of derivative works are not really open source. This, however, is the most common form of licensing use in academia, which is driving the so-called open source movement and is a main provider of useful source code.

Surprisingly, licenses that completely prohibit executing the software can still be useful. The trend is a new one, but I've seen it applied to the source code in books about algorithms and coding techniques. These books provide source code, but they restrict its use to study purposes only. You cannot copy the software, be it directly, by optical recognition, or even by typing it in, which eliminates any possibility of passing it through a compiler, much less executing it.

If the license fits

If all you want to do with a given open source package is use it as a tool to produce work separate from the package, then most open source licenses will do. Tools like compilers and text editors fall into this category. Libraries and interpreters might not, so pay attention.

For other purposes, choose public domain software. Or, if you want to distribute your software commercially but do not want to distribute the source to the modifications you made, go with a license like the MIT or the BSD. The GPL and LPGL are good choices if you don't mind distributing your source code.

Licenses like the Java Community Source License are so complicated that I'd keep away from the code unless I could count on the services of a good lawyer.

In all other cases, read carefully and look for the following keywords and phrases: use, copy, distribute, modify, derivative works, sublicense, and charge. Those words and phrases describe the rights that can be claimed on copyrighted work, and they will be specifically mentioned in documents that grant or restrict them. When in doubt, (gulp!) consult a lawyer.

If you're planning on distributing your own work as open source, then I suggest you adopt one of the licenses mentioned at the Open Source Institute's web site. I hope that my analysis will make the choice easier. These licenses have already been reviewed by lawyers and, just as important, they are free to use. Licenses can also be copyrighted, you know, and not all licenses are open source.

Originally written for In Publishing LLC
Copyright © 1999 Inprise Corp.