Can you use open source software for business
September 27, 2019
How to Use Open Source Code in Proprietary Software
You’re probably leveraging open source in some way or another. After all, much of the internet was built on open source technology. This includes the Linux operating system, the Apache web server application, and even GitHub repository hosting.
But teams aren’t just using open source software. Some teams are even using open source code in proprietary software.
What Is Open Source Code?
Open source code is source code that is made available for anyone to use — for free. Open source is typically supported by a community.
But there are some commercial options available for open source. These include:
Dual-licensing (open source and proprietary).
Professional services (such as OpenLogic ).
Software as a service (selling subscriptions).
Can Open Source Software Be Used For Commercial Purposes?
Open source software can be used for commercial purposes.
This means you can use open source software for commercial purposes — but you can’t always place restrictions on people who receive software from you. And commercial doesn’t mean the same thing as proprietary.
📕 Related Resource: Need Open Source Support? Click Here to Find Out More.
Using Open Source Code in Proprietary Software
You can use open source code in proprietary software. But you should be aware of what open source licensing applies. For instance, some licenses allow you to sell your software. But your code must be open sourced under the same license.
In fact, many development teams use open source projects as building blocks for proprietary software. In fact, a 2018 report found that 96% of applications have open source components. And the average percentage of codebases that are open source in applications grew from 36% in 2017 to 57% in 2018.
Git Is Open Source — And Lacks Security
Git lacks security. This invites bad behavior. Unless you do something about it. In our white paper, we share tips for locking down Git for good.
Lock Down Git
If you’re considering leveraging open source, you should carefully consider the pros and cons.
There are some significant pros to using open source code in proprietary software development.
The biggest pro by far is to speed up development while adding little to no cost.
For example, you need a source code editor inside your own project. You could build a basic one yourself. Or you could use one of the best editors available today — the Microsoft Visual Studio Code open source project. It’s supported by hundreds of contributors. Using it would make your own project that much better.
There are other pros, too. If you leverage open source as the building blocks for your project, it enables innovation for your developers. Instead of reinventing the wheel, they can think outside the box — and focus on the features that will set your product apart from competitors.
A great way to leverage open source in your project is to use the right version control. Helix Core, for instance, lets you bring open source Git code into your pipeline via Helix4Git. More on Helix4Git >>
There are also some cons to using open source code for commercial projects.
Open source has strings attached. Most open source software falls into two licensing categories:
Permissive (with few terms and conditions).
Copyleft (with strict terms and conditions).
Most open source projects fall into the copyleft category, which can be more difficult to navigate. If you don’t follow the licensing terms and conditions, you could be sued.
Is Open Source Software Free From Terms and Conditions?
Well, open source isn’t entirely free. That is, while it’s free to acquire open source, it’s not free to maintain and manage it. Your team will have to do that. They usually come with an attached license that requires users to adhere to certain terms and conditions.
There are other risks, too — including quality, security, and maintainability. Open source might not be held to the same standards that your development team is held to. It is largely reliable, because there are more eyes on it. But this transparency means that the bad guys can look at the code, too — and find vulnerabilities.
How to Use Open Source Software Wisely
Open source software is everywhere. And using open source repositories could help you accelerate development and reduce costs.
But how do you do it without risking the drawbacks?
It’s definitely possible. If you follow the right steps…
1. Find a Sound Project
Open source projects are not created equally. Some projects will be more reliable than others. And there are tons of options to consider for every type of open source component. For instance, GitHub alone has over 100 million repositories created by 31 million contributors.
As you evaluate potential code to leverage, ask the following questions:
Who created it?
Is it actively developed?
Is it maintained?
How often has it been downloaded?
Popularity indicates quality — and applicability of open source. If a project is popular (and has many contributors), it will likely have what you need for your own project.
Some projects are universal. Big name companies (Facebook, Google, Microsoft, Netflix) all have created popular open source projects. These become so popular that developers almost forget where they started.
2. Check the License Before You Use It
There are different types of licenses for open source projects. After you select a project, be sure to read the fine print. That way, you’ll know what exactly you’re signing up for — and avoid any potential violations/lawsuits.
3. Vet Security — Beyond the Community
Before you use open source components in your proprietary software, you need to know it won’t cause security risks. Selecting with an open source project with an active support community helps. That community can alert you to any security issues.
But the best way is to do security checks up front. Using a static analyzer can be useful here to identify potential errors (such as buffer overflow) that lead to security risks.
It’s also important to ensure security as you bring the code into the build. For example, if you use Jenkins, you can mirror or populate open source Git code into Helix4Git. That allows you to control the code more closely. Then you can execute security tests at appropriate stages of the pipeline.
4. Stay on Top of Updates
Any time the open source components you’re using get updated, you’ll need to ensure they still work properly with proprietary components. Staying on top of updates is key to avoiding issues.
Managing the code in a tool like Helix4Git gives you more control over when and how you adopt it into your product.
The Best Way to Incorporate Open Source Code
It’s important to use open source code & software wisely. It can give you many advantages as you develop your product. It can also introduce some risks. The steps we’ve outlined above are solid starting points for leveraging open source wisely.
But the best way to incorporate open source into your product is to use the right tools.
Using Helix4Git (with Helix Core) makes it easy to bring open source Git code into your build safely. You can pull together code from multiple sources — GitLab, GitHub, Bitbucket, Helix Core, etc. — into a single workspace. And you can even have your digital assets and binary files in that workspace.
As a result, you’ll get a single source of truth in Helix Core — and you’ll be able to pull in open source Git code.
Contact us to learn more about bringing open source Git code into your build pipeline.
For most practical purposes, it is — sort of. This is a complicated question, so please read on.
“Public domain” is a technical term in copyright law that refers to works not under copyright — either because they were never in copyright to begin with (for example, works authored by U.S. government employees, on government time and as part of their job, are automatically in the public domain), or because their copyright term has finally lapsed and they have “fallen into” the public domain.
Not all jurisdictions have a public domain, and it doesn’t always mean exactly the same thing in the jurisdictions that do have it. Furthermore, even where it is clear what it means, it’s still not a license. To be subject to a license, a work must still be in copyright. That means there is no way for the “public domain”, as a concept, to go through the OSI evaluation and approval process. We wouldn’t be evaluating a license text. Instead, we would have to somehow evaluate the laws themselves, in different jurisdictions, and say which jurisdictions have a public domain that meets the Open Source Definition and does not create problems for software authors and users. This would be very difficult, because it would mean evaluating not just the statutes but various bodies of case law (for example, open source licenses usually have a strong disclaimer of liability for the copyright holder — but we don’t know how or whether the author would be protected from liability for software released into the public domain in various jurisdictions). This approach would not be useful to the OSI’s mission, because open source is an international phenomenon and we only want to approve licenses that meet the Open Source Definition everywhere.
Thus we recommend that you always apply an approved Open Source license to software you are releasing, rather than try to waive copyright altogether. Using a clear, recognized Open Source license actually makes it easier for others to know that your software meets the Open Source Definition. It also enables the protection of attribution, and various other non-restrictive rights, that cannot be reliably enforced when there is no license.
There are certain circumstances, such as with U.S. government works as described above, where it is not easy to apply a license, and the software must be released into the public domain. In these cases, while it would be inaccurate to display the OSI logo or say that the license is OSI-approved (since there is no license), nevertheless we think it is accurate to say that such software is effectively open source, or open source for most practical purposes, even though it is not officially released under an open source license. (This is assuming, of course, that in the laws of releasing jurisdiction the meaning of “public domain” is compatible with the Open Source Definition.) After all, the freedoms guaranteed by open source licenses are still present, and it is possible for the familiar dynamics of open source collaboration to arise around the software.
For a detailed discussion of the complexities of the public domain and open source, search for the words “public domain” and “PD” in the subject headers of the January 2012, February 2012, and March 2012 archives of the OSI License Review mailing list. And if the thought of reading all those conversations is daunting, please take that as more evidence that it’s just better to use an approved Open Source License if you can!
See also the CC0 question. For a different viewpoint than the one presented above, see unlicense.org.