"Open-source software is a type of computer software in which source code is released under a license in which the copyright holder grants users the rights to study, change, and distribute the software to anyone and for any purpose."
Open source doesn't just mean public access to a codebase; it indicates how the code can be used and distributed afterward. It's about opening up a living project for participation from anyone who wants to get involved. One of the key reasons companies open-source projects is that they want the community to get involved.
There are 3 dimensions to engaging with open-source software:
- Consumers who study or use the repositories of others.
- Contributors who are actively involved in the improvement of the repositories of others.
- Producers/Maintainers who build and maintain their own repositories that are open to others.
The truth is that many projects aren't destined for open-source greatness.
While your criteria may vary based on your company's goals and process level, here are some things to consider before open-sourcing a project:
Does your project contain intellectual property that you want to protect? If so, then opening its source would give away its value. Don't open-source those kinds of projects unless you feel the benefits outweigh the risks.
Is the project in a stable state with good code quality? The project doesn't have to be perfect, but potential contributors may walk away if the project is in terrible shape to begin with.
Is your project useful to people outside of your company? If not, then you probably aren't getting any participation.
Are people outside your company able to contribute? They need access to all project dependencies, build processes, and whatever else is needed to run the project. If they can't run it, then they can't contribute.
Does your team have the bandwidth to support an open-source program? If you open-source a project and then don't support it, you might lose your opportunity to build a trusting community.
Can you change the code? Can you share it or sell it? Can you use it commercially?
A license agreement comes with the source code and specifies what can and cannot be done. The license spectrum impose different obligations from permissive to restrictive.
If you're contributing to an existing project, it's almost always easiest to continue using that project's license. To find its license, look for a file called LICENSE or COPYING, and skim the project's README.
Permissive licenses:
"Do whatever you want, just give credit"…carry minimal restrictions, and allow practically every type of use, modification, and redistribution, the only restriction is that the original attribution to the authors remains included in the source code or as part of the downstream use of the new software.
Open Source Initiative defines it as "a non-copyleft license that guarantees the freedom to use, modify, and redistribute", basically as a free software license e.g. BSD-like, MIT, Apache.
GitHub's choosealicense website describes the permissive MIT license as "[letting] people do anything they want with your code as long as they provide attribution back to you and don't hold you liable."
Restrictive licenses:
"If you modify and distribute, you must share your changes under the same license"… considered protective, as it grants use rights, and forbid proprietization, requiring that all modified/extended versions also be free and released under the same terms and conditions.
The Copyleft licenses are rather "viral" as it spreads to the entire project, Richard Stallman (GPL creator) prefers terms like "protective".
One GPL dependency could force to open-source the entire product
You find a MIT-licensed library, use it in your proprietary app, sell the app as closed-source, perfectly legal MIT doesn't care.
You find a GPL-licensed library, use it in your proprietary app, want to sell the app as closed-source 🚫not allowed, your entire app must be GPL and open-source.
GPL has a loophole, running modified GPL software on your servers, results in no obligation to share, but AGPL(GNU Affero General Public License) close this loophole. If users access your software over a network, you must share the source code,
That's why many companies avoid AGPL like the plague and often prefer MIT/Apache licenses.
- GPL: "Distribute it, and you must share the source".
- AGPL: "Distribute it, or use it over a network, and you must share the source
List of OSI Approved Licenses:
S̶u̶c̶c̶e̶s̶s̶f̶u̶l̶ stories: It's all about distribution
Keep in mind that about 80% of a software solution relies on existing components maintained outside of the project, and not all open-source licenses play nicely together.
⚠️ Combining Permissive + Copyleft → Copyleft wins, everything becomes copyleft.
📌 Derivative works, or future versions, of permissively licensed software can be released as proprietary software.
💸 For most licenses, obligations trigger when you distribute the software (i.e. selling the SW to customers, giving away binaries, providing downloadable apps).
Top comments (0)