|
|
|
|
|
|
|
|
An examination of the issues involved with the use of open-source software components in closed-source applications.
by Brian R. Marshall
Use of open-source software is mushrooming with the use of Linux. The benefits of open source are becoming more widely known--software quality is improved from peer-review, and future risk is reduced if the source is available.
Open-source projects depend on contributions by motivated, talented developers. Big, important projects like Linux attract many contributors; a project for a software development tool may interest a variety of software developers; UNIX systems gurus contribute to projects for Internet tools. However, a project for software that identifies butterflies may not attract much interest, and the only people who are going to contribute to a project for a company's accounts receivable system are those who are paid to do so. Not all software benefits equally from being open source.
The development of closed-source software will continue. As Eric Raymond observes in ``The Magic Cauldron'', some applications (as opposed to operating systems and utilities) can be good candidates for being closed-source. The owner of an application may find more benefit in the software being secret and/or rentable than being open source, at least for a while.
It may be undesirable for the source of a homegrown business system to be open, because it reveals so much about the business's procedures and capabilities. A company may want to keep the source of its business systems confidential.
The owner of an application may want to keep the source closed so that the software can be rented (i.e., licensed for money). Many applications are developed only when someone believes they can make money renting them.
While the benefits of open source are becoming more widely appreciated, closed-source software will continue to be developed.
Closed-source applications can benefit from using open-source components.
Applications generally make use of pre-existing software components. Almost all programs use general-purpose function libraries that come with compilers. Many applications provide a front end using a GUI framework that comes with the compiler or a third party. Some software uses special-purpose libraries to do things like statistical analysis or mapping projections. Many applications include, or know where to find, a self-contained ``component'' that provides sophisticated functionality, such as a database engine or a map-drawing system.
There is less risk in using a third-party component if it is open source. This is particularly true of components developed by small companies and individual developers. It's very difficult to develop software components and make money renting them. People think, ``I don't know these guys. Who knows what they've done in there? My application depends on this functionality.'' They also think, ``What if these guys disappear? Or find something else to do? Or change the component so I can no longer use it? Or not fix what I need fixed?'' They may also think, ``This component does what I need to do now. What about next year? What if I want some enhancements? Are these guys going to care what I want?'' Being open source addresses these concerns. Developers can see what an open-source component does and how it does it. They always have the option of making improvements themselves (or paying someone to do it).
If a component is open source, its owner cannot rent it. However, money can be made in support services, and the people best poised to do so are developers. A tiny outfit without the credibility to rent a component may find that the best way to make money is to make it open source.
It might be easier to attract contributors to an open-source project for a component than to a project for a narrow application. The users of a component are programmers, and they make up a natural pool of potential contributors whereas the users of a narrow application might be, for example, dentists.
Developers may be motivated to improve the component if an improvement is all that is necessary for the component to be used. Companies using the component may be motivated to spend money to improve it.
Concerns arise over using open-source components in closed-source applications. The most commonly used open-source license is the General Public License (GPL). It grants users the freedom to modify the software and distribute this derived work only if, among other restrictions, the derived work is also licensed under the terms of the GPL. This license ensures that all users of a piece of software, even users of modified versions, have the freedom to see and modify the source code. The Free Software Foundation promotes the use of the GPL.
A component licensed under the terms of the GPL cannot be used in a closed-source application, but some developers of open-source components would like to see them used in any application, open-source or not. The Library General Public License (LGPL, also known as the Lesser General Public License) was developed for this situation. A component licensed under the LGPL may be included in a closed-source application as long as users can get the source for the component, modify it and rebuild the application.
In many cases, however, developers of closed-source applications cannot (or will not) make use of components licensed under the LGPL. Developers of commercial products and companies writing software for their own use frequently don't want any given component badly enough to submit to the restrictions of this license.
There are less restrictive open-source licenses. A component licensed under the terms of the MIT License can be used by anybody for anything. Such licensing makes a component practical to use in closed-source development. Many people in the Open Source community find this license to be subversive, precisely because it makes it practical to bring open-source software into closed-source applications.
The people who write open-source software are the hackers--the community that had its origins at the MIT AI Lab.
It began in 1959, when a group of people in the Signals and Power group of the Tech Model Railway Club got access to a small computer-- the TX-0. This was different from the big IBM mainframe, where one submitted a deck of punched cards, then waited around for their own job to run. With the TX-0, one could actually sit at a console and deal with the machine directly. The club loved it. They loved the challenge of trying to make it do what they wanted, and the feeling of power when it finally did. They started with practically nothing in the way of an operating system. They wrote their own system functions and simple tools and used them to build better tools.
These were the original hackers--a group of people who thought programming was the most important thing in the world. They were explorers. They were a community. They shared information and ideas, and they shared the belief that if information and ideas move freely, everyone benefits. They shared the product of their work--tools, utilities, experiments, games and jokes. A person's standing in the hacker community was based on almost nothing except that work.
People moved in and out of the community at MIT. Some hackers moved to other institutions and kept in touch via the ARPA-Net (a precursor to the modern Internet). The community became a network community and stopped having a specific geographic location. As Internet access became available to anyone in college, this community grew. The Internet became the focus for many hackers; its infrastructure was developed largely by hackers. Now the focus has shifted to Linux, and the software that runs under it.
As Eric Raymond describes in his paper ``Homesteading the Noosphere'', the hacker culture is a gift culture--status within the community is based on what a person creates and gives away. Open-source software is the product of people programming (testing and debugging) and giving away the results. Most of this work is done in the spare time by people who also hold paying jobs.
People contribute to open-source projects for a variety of reasons: fascination with the problem, desire for a meaningful programming project, wanting to participate in the community, an opportunity to prove themselves, or a desire to use the new software personally. They continue to contribute to the community and culture because it works. People who have never physically met, each doing whatever they feel like doing, can in their spare time create great software.
The General Public License is seen as strongly supporting the hacker culture. It can be difficult to attract contributors to a project for software that is not licensed under the GPL. It can be particularly difficult for projects involving components licensed under the MIT license.
In the past, people in the Open Source community were the primary users of open-source software, but this has changed. Many new Linux users are not programmers and many of them will never contribute to open-source projects. Open-source developers don't feel cheated by this; they feel vindicated. To a hacker, the ultimate measure of software's worth is whether people find it useful.
Linux has been very good for the Open Source movement. Huge numbers of people are trying it. Many more are hearing about it. People are pushing for its use where they work. More and more people are learning about the Open Source movement and its values, and becoming involved in open-source projects and a part of the Open Source community. The community benefits from increasing use of open-source software, whether that use directly supports open-source development or not. The community benefits when dentists, for instance, use Linux.
Suppose, however, that a dentist and I want to get together and write an application that implements his top-secret super-duper billing technique. The technique is a trade secret, so the application must be closed source. Now, suppose that as I'm writing it, I want to use an open-source library to do statistics. If this makes my billing application a ``derived work'' and I'm going to get a bunch of licensing hassles, I'll do something else. I'm not trying to derive a new statistics library--I just want to use it. If it's a good thing for a dentist to run his billing application on Linux, why wouldn't it be a good thing for the application to use open-source parts?
The more people who use open-source components, the more people will decide some component needs a wee change and they should do a little work for the open-source project. If open-source components are used in business applications, businesses will, from time to time, find it in their interest to pay someone to work on the components. This is good for the Open Source movement.
The Internet has gone from being tiny to small to huge to gigantic. The use of open-source software has gone from being tiny to small to huge. The parallels between open source and the Internet are particularly interesting, because the cultures overlap--the infrastructure of the Internet was developed by and is maintained by hackers.
The Internet and its culture can be viewed as having passed through four generations:
Linux began as an operating system used primarily by programmers. Now it is used by all kinds of people, and the proportion of Linux users who are programmers is steadily decreasing. Most of these non-programmers know very little about the traditions of the hacker culture. Many of them use Linux simply to make money, and it's just about the best thing that could have happened to the Open Source movement.
Open-source software isn't going to replace closed-source software any time soon. People write closed-source applications because they believe they can make money renting them, and they will continue to believe this. Companies write software for their own use, and want to guard their trade secrets.
Closed-source development is a wonderful market for open-source components. The more companies use open-source components, the more they will contribute to open-source development.
It's great that programmers can create something like Linux in their spare time, but they also spend a lot of time at their paying jobs. Component development may be where the Open Source movement invades company time.
Brian has been a software developer in Calgary's oil and gas industry since 1981. He is deeply into C++ and object-oriented design. His career began vowing never to learn Cobol; it progressed to never learning VB and now involves never learning MFC. Brian first got into UNIX in 1991 but he has only been using Linux for about six months. Brian Marshall can be reached via e-mail at bmarshal@agt.net.