Why Do We Need Software Licenses?
Clear Terms Are Important to Software Producers and Consumers
In 1996, web application development was just beginning. Web users were realizing that websites didn’t need to be static HTML — they could write code to output any HTML. Soon they were writing database-driven web applications.
I was working as a support engineer for an SQL database product called InterBase, sold by my employer, Borland. I saw that Perl was becoming popular as a language for web application development. So I developed a Perl extension to allow Perl scripts to interface with the InterBase API. It was just 3600 lines of C with 900 lines of Perl.
I released my little Perl extension as open source. Like other Perl packages I had seen, I added a comment line to each code file, describing the software license I granted users of my code:
# You may distribute under the terms of either the GNU General
# Public License or the Artistic License, as specified in the
# Perl README file.
I was soon glad I did that.
A few weeks later, I got an email from an irate software business owner in the Netherlands.
He complained that my software was defective, and it was costing his business a great amount of time and money. He said he had a room full of programmers who were unable to finish their project, and it was because my software was terrible.
I replied as quickly as I could and asked what the problem was. If I could advise on using my Perl extension, or InterBase, I would be happy to do that. If there was a real bug in my code, I’d try to fix it and make a new release.
The business owner described that his programmers could not even begin to use my software because it failed even to open the Paradox database. He also said he wanted a full refund or else he would consider taking legal action against me.
Paradox was a different type of database product. Whereas InterBase was a client/server RDBMS, competing with Oracle and Microsoft SQL Server, Paradox was a Windows desktop database, similar to Microsoft Access or FoxPro. Paradox had previously been sold by Borland, but by 1996 Paradox had practically been abandoned because of such strong competing products from Microsoft.
Paradox had no interface in common with InterBase. An InterBase client or connector (like my Perl extension) would never be able to use a Paradox database, and it wasn’t intended to.
I replied to the business owner as politely as I could, but firmly.
I understand you’re unable to use my Perl extension for InterBase with a Paradox database. This is by design. My software works with InterBase and no other database. The code comments and the documentation are clear on this point.
Furthermore, the software is free of charge. Your business paid me nothing to use it, so there is no refund to give. You may use it at no cost or decide not to use it.
Then I was glad I had included the reference to the software license in my code, because I could make the following statement:
The code is open source, offered under the GNU General Public License or the Artistic License. Both of these licenses have an “AS-IS” clause. The software is free, but there is no warranty or implication of fitness for any particular purpose.
This is the same license used by Perl itself.
I never heard from that business owner after that. I was able to avoid a dispute about whether I was responsible for his project because I had included a software license that described the limits of my responsibility. By using my software, he had implicitly agreed to those terms.
Ever since then, I have known that the software license is an important part of any software release. Whether you publish open-source software or proprietary software, you should be clear about the terms of usage. This practice is good for both the software producer and the consumer. Both parties need a common understanding of the license terms, such as:
- License fees (if any), including whether fees are one-time or recurring.
- The user’s right to convey or redistribute the software.
- The user’s responsibility to give attribution to owner of the code.
- Which party is responsible for support or defects, and to what extent such service is offered.
- The duration and transferability of the license.
- Compatibility with other licenses.
Learning about software licenses and other contracts is overlooked in the technology career education, so many of us have to learn on the job. To develop your licensing knowledge and skills, use resources like:
- https://opensource.org/licenses.
- The Tech Contracts Handbook: Software Licenses, Cloud Computing Agreements, and Other IT Contracts for Lawyers and Businesspeople Third Edition by David W. Tollen. (Note: this link to the book is not a review.)
If you enjoyed this article, you might also like the first volume of Bill Karwin’s new SQL Antipatterns book, now in beta with The Pragmatic Bookshelf. You can save 35 percent with promo code bksap1_medium_2022 now through September 30, 2022. Promo codes are not valid on prior purchases.
