Historical tale of license management challenges while building an ISP

FOSSBazaar is no longer being updated. The information on this site is preserved for your convenience but may be out of date. Please visit Linux Foundation's Open Compliance Program for current information and activities.

dmaxwell's picture

This tale is here to give an example you can compare your own governance situation to. It dates back to a fairly early time for the world wide web, when these issues were new to a lot of people.

In August of 1996 I took a job with a company called Fundy Cable. My role was to provide the technical expertise to design and implement a cable Internet Service Provider, and to participate in the planning to market, sell, and support the service. Much of the staff in the company was accustomed to either a traditional cable or telephony environment.

In those environments, software is something that comes in a box, or is supplied and probably installed by a hardware vendor's service team.

Most ISPs know, or quickly discover that an Internet service consists of many different server applications, such as at least a web server, name server, radius server, mail server, and news server. Coming at the problem equipped with my UNIX background, I was already familiar with a variety of open source implementations for all of those needs.

In addition to the server end of the equation, in 1996 many of our potential customers were still running Windows 3.11, or Windows 95 release one. Neither of those included a web browser, e-mail client, or newsreader as shipped, so we also had to provide client software to our users. Last, but not least, the cable modem we settled on was the Scientific Atlanta DataXcellerator, which used the cable for download only, and a telephone line for upload. This meant there was also a client application to control dialing the modem to connect to the Internet, and backend software to authenticate users and route their data to them across the cable network.

So into this company with no prior experience in deploying software to customers, we now had a new service that included open source server software, proprietary server software, proprietary client applications, and redistribution licensed client applications. Each of these comes with its own planning challenges. The costs to purchase and maintain, and the time to understand license requirements, and debate subtle points of language and license text, are multiplied by the number of licenses you need to deal with.

Additionally, as a publicly traded company, and government regulated communications provider, careful attention to detail was critical, to maintain good standing under various regulatory environments.

Initially, one might expect that the commercial software, having been bought and paid for, would not lead to any discussion of license issues. However, we required changes to the client application, and after discussion with the vendor, we came to an agreement that we could implement those changes ourselves, after receiving source code and agreeing to a new license to cover it.

The open source software we used for the servers included NetBSD, Postfix, Apache, Squid, Bind, Perl, PHP, and more. In addition to the corporate unfamiliarity with the concept of open source, there was also skepticism about its reliability and absence of support contracts for it. Furthermore, we did not use all of these applications in their original form, but made source code modifications for a variety of purposes.

For client software, bundles were available from both Microsoft and Netscape. Both included fairly complex redistribution license agreements, which were regularly revised in this early phase of the browser wars. We prepared installation software kits from both vendors while making a final determination on the most acceptable license terms.

Throughout this effort, either at milestones in our project plan, or when triggered by external regulatory events, a review of licenses would occur. Understanding software licenses was quite challenging even for our professional legal team, due to the interaction of legal and technical detail. Fortunately, they were determined to make the necessary effort to ensure we met all of our obligations.

If the request for a review of licenses was triggered by an external event, it was disruptive, since compiling the information was manually and mentally intensive. Making sure that the list of software in use was complete, and collecting all of licenses, took time. It did become easier as time went on, since new and discontinued software was a smaller portion of the whole, later reviews could be resubmitted using a large portion of the prior work.

In the end, our on-demand license reviews, and ad hoc tracking systems fulfilled the need. The service launched, and was well received by customers. The open source software proved its reliability, and made converts of some of the staunchest objectors.

I have no doubt that in the more than a decade since that service launch, hundreds of ISPs, or thousands of organizations have faced similar challenges in software governance. Resources such as tracking tools, and a public discussion about license interpretations and best practices would have been very useful during this process.