I wrote a few weeks ago about How I Value Open Source, the first part in this two-part blog series. The post covered my own thoughts on Open Source (OS), and its values to me. This post aims to cover more real-life fundamentals of OS, a deeper dive into OS and of course, the business value that lies in OS.

I’ve also included a video from my original presentation about Open Source for WXG 2014 at the bottom of this post!

Defining Open Source…

If you look up the term Open Source (OS), you’ll probably find a bunch of articles telling you that it means:

"Software that can be freely downloaded, modified and re-distributed by any member of the public."

I’d agree with that as a term definition, but I think it means so much more. As I said in my last blog, it means a lot more to me personally than can fit into a sentence. Since this blog is about the “True” value of Open Source, and not what it means to me, let’s focus on that.


When it comes to releasing, using, modifying, or re-distributing OS Software, one of the most important things to consider are the licenses invalided with this. There is some confusion regarding different license types, and which of the many licenses available is the correct one to choose.

While I don’t have time to go into every license available (believe me, there are hundreds), I do want to define and clear-up the main 3 available, and most widely used. It is actually possible to define your own custom licenses, and many people do – but that being said, to become a publicly usable license, it must go through the License Approval process from the Open Source Initiative.

Licenses in OS, from a high level, mean one thing: they allow software to be freely used, modified, and distributed. I’ll start with probably the most popular license:

MIT License

The MIT license is objectively the most widely used license in the OS community, and probably the license you’re most likely to interact with, if you use online code sharing websites like GitHub or BitBucket. Essentially, the MIT license: “Lets people do anything they want with your code as long as they provide attribution back to you and don’t hold you liable.”

The MIT license is the best to use when you want things to be simple and permissive. It allows Commercial Use, Distribution, Modification, Private Use, and Sub-licensing. It also forbids the author/license holder being held responsible (liable) for any damages caused.

It is used by projects such as jQuery, Rails, many companies’ API Libraries (including SendGrid’s), and on a more personal note – all of my own software. When I upload projects to GitHub, I generally always select the MIT license. I want anybody to be able to do whatever they see fit with my software, so long as they provide an attribution back to me. When using the MIT license, we do so by inserting a LICENSE.txt file into the root of the code repository outlining this.

Apache 2.0 License

Apache 2.0 is another license that you’re very likely to come across. It covers much the same as the aforementioned MIT license, but keeps its focus on two major factors: Patent Granting and Trademark Use.

By using this license, an express grant of patent rights is given from the author to the user. The license also states that the user may not use names, logos, or trademarks of the authors. So at a high level, this license would be best to use if you want all the freedom of the MIT license, but are concerned about patents on your software.

This license is used by projects such as Apache, Subversion, and NuGet. Again, a LICENSE.txt file in the root of your code repo will suffice, but additionally, you must include a changelog for any major changes made, and Apache recommends that you include some boilerplate license text in the header of each file in the repo.

GPL & v3 License

The GPL v3 license is the best license to use when again, you want most of the freedom of the MIT license, but you do not want users to be able to sub-license your software.

This license stands for keeping software free, and sharing all improvements made to the software. A good example of this is WordPress. WordPress is free of charge, and whilst it allows users to download and modify WordPress, they may not resell the codebase as a product (sub-license) of their own.

If you supply software as free of charge, and do not wish for users to be able to resell the software for their own profit, this is the license to choose. It is used by projects such as Linux, Git, and again, WordPress. To utilise this license, the same LICENSE.txt file must be present, and again a changelog marking all significant changes to the code repo must be included.

Open Source in Enterprise:

It’s a common misconception that OS software can’t make money, and can’t be utilised to a high volume in an enterprise situation. Well, I think it’s quite the opposite, actually! Whilst the source code to a project may be totally public domain, that project need not be written off as a non-revenue-generator.

Many companies, such as 10Gen (MongoDB) and Couchbase use Dual Licensing Models. Dual licensing allows for companies to open-source the codebase to their projects, but keep them as profit bringers. Both MongoDB and Couchbase offer a similar licensing model for their software. Whilst the codebase is OS, and available to the public through channels such as GitHub and BitBucket, the companies add value by offering extended professional services, instead of charging for the software itself.

By offering one-off and ongoing professional services such as architecture formation and maintenance, and support and consulting, the codebase is freely available, but the customers are paying for necessary services alongside the product.

Many companies are offering their product as Software as a Service (SaaS), whilst allowing the codebase to have all the benefits of being OS, such as contribution from the knowledgable public, quicker bug fixes, security patches, and overall product improvement from a wider developer pool.

The Big Theft Question:

“We’ve spent $$$ developing our product. If we open-source our codebase, can’t someone simply copy it and make money from it??”

Well, no, they can’t. This is where licensing becomes such an important factor. By using the GPL v3 license, you can ensure that your codebase cannot be copied and sold-on by third parties. Open Source licensing is extensive, and protects your company and codebase from this exact thing.

Putting it all together…

I hope from a combination of my previous post, and this one, I’ve been able to piece together the values of Open Source, both from a personal point of view, and a real-life business point of view. Open Source is undoubtably one of the most valuable aspects of the software industry.

Below, you can watch my entire presentation that I gave about Open Source at WXG 2014:

Robin Johnson: THE VALUE OF OPEN SOURCE from Kyan on Vimeo.

I hope you all embrace it as much as I, and everyone here at SendGrid does!

* – @rbin *

SendGrid Team
Expert advice and insight about all things email including best practices tips, examples, and advice for marketers, developers, and everyone in between.