There are many myths about open source software. From the high-profile misrepresentations of the – energetic – Microsoft ex-CEO Steve Ballmer calling open source a cancer on intellectual property, to the common misconceptions among developers and business-people; this post aims to set the record straight about some of the most common myths surrounding open source. Steve Ballmer eventually had a change of heart, so keep an open mind.
#1: Open Source Is Not for Businesses
Yes, open source is indeed for businesses. In fact, you would be hard-pressed to find a business that does not use any open source software at all. Among tech companies, four in five run their operations on open source software according to The Future of Open Source Survey 2015.
The term open source itself was launched by a splinter-group of the free software movement in 1998 in order to not discourage corporate actors who equated the “free” in free software with “poor quality” (there are no free lunches, right?).
The group especially objected to the free software movement pushing its moral and ethical convictions of software freedom on to others. The breakaway of the open source movement from the free software movement explains the important differences between academic and reciprocal licenses. I recommend anyone interested in open source to look further into this divide (posts will follow, in the meantime you can have a look here).
If you are curious about the use of open source software in businesses today you can check out the webinar where the results of The Future of Open Source Survey 2015 were presented.
#2: Open Source Is Anti-Copyright
No, open source is dependent on copyright.
This may seem obvious, but there is a surprisingly wide-spread misconception that open source would somehow be contrary to copyright. Authors of open source software license the exclusive rights ensured to them under copyright law in order to further their goals (e.g. disclaiming responsibility, ensuring reciprocity, requiring notices, etc.). Without copyright, there would not be any open source licensing.
This misconception can to a large degree be explained by misunderstandings of the term “copyleft” and the free software movement’s general skepticism towards copyright.
#3: You Must Go Open Source Yourself
No, merely using open source does not require you to open-source your own software.
There are however some specific circumstances under which you may be under an obligation to distribute source code. It is important to understand when those obligations are triggered.
Obligations to open-source your software are – as a general rule – triggered when you distribute the software. Therefore, merely using open source software in-house will not trigger any obligations. An important exception from this general rule is the Affero GPL, in which the reciprocal obligation is triggered by allowing users to interact with the software over a network.
Note that this only applies to reciprocal licenses (a.k.a. restrictive, copyleft or hereditary licenses) like the GPL, EPL, MPL etc. The so-called academic licenses (the MIT, BSD and Apache licenses, etc.) do not set any such conditions.
#4: You Must Always Contribute Changes Back to the Author
No, reciprocal licenses do not require you to license changes back to the original author.
In essence, reciprocal licenses require you to reciprocate the terms you received the work on, upon further distribution downstream. This means that if you make customizations to a program but keep those in-house, there is no distribution triggering any obligations and you will therefore not be required to offer source code to anyone. Revealing such customizations – when it is not done as part of a deliberate plan – may otherwise violate your current security-strategy, fiduciary duties, other obligations, and so on.
Even if you distribute the software in a way that triggers the reciprocal obligation, that obligation is to offer source code to subsequent recipients; the original author may – but does not have to – be part of those subsequent recipients.
#5: The GPL Is Contagious
What does it mean to say that something is contagious? Contagiousness is a term borrowed from the field of medicine that is used to describe the transmission of disease by contact.
If the GPL was “contagious”, would that mean that storing software next to GPL-licensed software could be “infected” with GPL? Would it mean that the Affero GPL mentioned above could “infect” over the Internet? That would indeed be a frightening proposition.
No, of course it doesn’t. But if the GPL actually did “contaminate” other software, those would be valid concerns. Fortunately, that is just not how licensing works. It is a good example of how metaphors not only help to convey complex matters, but also impair us from fully understanding them. Since both software and intellectual property are intangible subjects, physical world concepts have limited application and must be used with caution (in this case, not at all).
The terms of the GPL – just like those of other licenses – are not written to operate like contagious diseases do. Settling for a flawed thought framework is particularly unfortunate in the case of the scope of the GPL since it can have major implications on your legal obligations.
Request for Feedback
Have you noticed any other myth going around? Let me know.