I wrote code for an employer which, I feel, would benefit from being released under a copyleft (e.g. LGPL) or permissive (e.g. MIT) license. The code is of general utility and exists well outside the company's business line. In order to not waste management's time, I want to clearly articulate the benefits of using a libre license in this case while relieving any possible concerns.

I have compiled the following benefits, ranked by what I believe make reasonable "business sense":

  1. Offload maintenance costs (i.e. Linus's Law: "Many eyes make shallow bugs") - A libre license allows for more testing by both end-users and developers. Bugs are more likely to be exposed and, because the code can be used by other developers (with a vested interest), have fixes offered. This can offload maintenance costs. A concern may be that revealing bugs and working with others whose interests are not in line with the company's would divert engineer time. While there is truth to this, see the Mythical Man Month, every libre license clearly states that the software comes with no warranty and, therefore, no obligation to act on any issues raised. The company has discretion on which issues to address.
  2. Free marketing - The company's name can be attached to a tool which others find valuable. This creates a positive association with the company. A reasonable concern might be that a negative association is created because of bugs, etc. However, as the tool is actively used at the company and solves a real problem, this feels unlikely.
  3. Community goodwill - Much of the company's internal software is developed using FLOSS. Releasing source code perpetuates the "scratch my back, I scratch yours" nature of libre software. It constitutes a fair trade which, broadly, ensures more software is released that the company can utilize.

What are other benefits of using a libre license? Conversely, what concerns may need consideration/reconciliation?

  • 1
    Do you have any quantitative numbers for your points? If not, how are you going to justify the time spent in meetings and on lawyers? May 28, 2021 at 15:43
  • Thank you for proposing this concern. How would you suggest getting them? I can get them for you, but we'll have to release this code in order to compare ;) May 28, 2021 at 16:36
  • 1
    Depending on the software and the use: it may also be a channel to gain access to talent and open a new recruitment opportunities. (will say: if you happen to attrect talented developers to work on your software, they might even be a good hire). Good contributions are basically a free hiring interview. May 29, 2021 at 15:03

1 Answer 1


I have written a book on how I created a multi-million-dollar business with open source software. I was the original developer of the FOSS PDF library iText that was available under the MPL/LGPL for 8 years (2000-2008). This resulted in extreme popularity of the library and a great brand-awareness. The argument free marketing is certainly valid.

However, maintaining the library, answering technical and legal questions from users, was very hard to combine with my day job. Sure, I received plenty of help from a handful of developers, but when I did the math (help from the community minus requests from the community), the result was negative: I was spending more time on helping the community when compared to the time I gained thanks to the community. Based on that experience, I would be careful when using the arguments offload maintenance costs and community goodwill. In theory, they are valid, but in practice, they aren't always true.

Nevertheless, there are several other, more business-oriented reasons why it's a good idea to distribute (part of) the codebase as FOSS.

I decided to create a company to monetize the library in 2008. That company almost went bankrupt for different reasons. One reason was that my son was diagnosed with cancer; I spent more time in hospital than at my desk. The other reason was my lack of experience developing a business. Fortunately, I received help for the latter. I was advised to change the license from the MPL/LGPL to the AGPL (which I did in 2009) and I was able to grew the business for 0 to 10M euro revenue in less than 10 years (the company hit the 10M euro mark in 2017). In the meantime, I have realized an exit. I am no longer with the company.

During the lifetime of the company, different people within the organization questioned whether the product should remain open source. Allow me to quote from chapter 24 of my book:

Board members, salespeople, and part of management were always suggesting that we should make iText closed source, but I defended keeping iText open source with the following arguments:

  • Thanks to iText being FOSS, we succeeded in reaching markets we could never reach if iText were proprietary.
  • Wherever iText was used, even illegally, no other FOSS or non-free PDF products were used. This gave us the opportunity to convert non-paying users into paying customers.
  • FOSS had become mainstream. Several companies and governments adopted a policy that the software they paid for should be open source.
  • Closing the source code would hurt our existing iText community and scare away potential code contributors.

Especially reason 3 could be a good argument to convince your employer. Several customers have adopted a comply or explain policy, in the sense that they want vendors to make their code available as open source (comply), or provide sufficient arguments why they choose not to do so (explain). Your employer might want to prepare the company for a future in which this policy becomes more ubiquitous. This is not something you do overnight. It requires planning and a clear strategy.

Actually, if I hadn't left the company, I might have considered making the library available under a more permissive license, as I explain in chapter 21:

I wanted DITO [a low-code solution that was created as an alternative to using iText] to create as much value as possible for the company and chose to bring it to the market using a SaaS business model. If DITO succeeded in generating sufficient revenue, I considered releasing the core iText library under a permissive license hoping that it would become the de facto reference application for PDF, possibly eliminating the need for any other FOSS PDF library.

Many companies use open source as a business model. I have written an article describing eight ways to monetize FOSS that I have tried and tested over the years: Open Source Survival, a Story from the Trenches. This article was inspired by what I wrote in chapter 16, the chapter that concludes the second part of my book ("Building Free and Open Source Software").

This is a fragment from that chapter that is not in the article:

Andrew Aitken has an interesting view on the evolution of FOSS. He identifies four generations:

  • Generation I started with the thought leaders we discussed in Chapter 8 and 9—people such as Richard Stallman, Linus Torvalds, Eric Raymond, Bruce Perens, and others, who wanted to make software free and allow anyone to contribute to the improvement of the software.
  • Generation II consisted of people who began to commercialize open source and launched the first commercial open source companies. I didn’t make Andrew’s list, but people who preceded me were, for instance, Mårten Mickos, who commercialized MySql and sold the company to Sun Microsystems, and Marc Fleury, who sold jBoss to Red Hat.
  • With Generation III, the creation of FOSS shifted from individual developers to IT companies. Yahoo, Facebook, Google, and Netflix are examples of companies that open-sourced part of their code. Obviously, they didn’t do that out of idealism, otherwise Google wouldn’t have had any problem making the applications that used iText open source. The main reason was self-interest: by allowing other companies to use their source code, they benefited from all the improvements that were added to that code by developers they didn’t have to pay.
  • Generation IV is characterized by large global corporations such as Capital One, Lloyds Bank, and Walmart, whose core business traditionally wasn’t IT, but who saw the benefits of making the source code of their software open source.

You could argue: if companies such as Google, Netflix, Capital One, Walmart... find it interesting to open source part of their codebase, why wouldn't it be interesting for your employer?

This is another fragment, taken from the same chapter:

Creating a SaaS business is always a great idea. It’s also great if you’re willing to share part of the underlying technology as FOSS, just like the companies that mark the third generation in the evolution of open source.

Their main business isn’t selling software.

  • Facebook’s main business is selling ads; the users are Facebook’s product
  • Google offers SaaS (software as a service) as well as IaaS (infrastructure as a service)
  • Amazon sells books and other products, but also offers IaaS with Amazon Web Services (AWS)
  • Microsoft paid hundreds of millions for Xamarin and then made the technology available as FOSS, driving developers toward MS Visual Studio and Azure, which are paid services
  • Companies such as TCS and Infosys sell projects in which they use FOSS abundantly

Today, these companies are perceived as FOSS heroes because they distribute plenty of FOSS products using a permissive license. They can afford to do so because they have a business model in place that generates sufficient money—selling products that are very different from the FOSS product, but they’re not sharing out of charity. The more developers adopt their FOSS products and frameworks, the more these corporations strengthen their position in the market.

These fragments were taken from the book Entreprenerd: Building a Multi-Million-Dollar Business with Open Source Software (released in May 2021).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.