In 2019, the Black Duck® Audit Services team audited 1,253 codebases to identify open source components, their associated licenses, security vulnerabilities, and overall community activity. Our Audit Services team has extensive experience in not only identifying open source licenses, but also researching the more than 2,700 license permutations that exist in the open source world. But what happens when an open source component has no license at all?

Your open source usage is out of control. Sure, it’s helping you develop your product faster and getting new releases out the door in days instead of months, but now your code base is made up of 60% or more open source components. And that percentage is only growing. The application layer continues to be the most attacked, so you know you need to stay on top of vulnerabilities.

I was going through a row of photography books in an antique store when I got a call from Bucky Moore, our lead investor and a board member. “Let me know if you need anything from me. This is getting serious,” he said. He seemed concerned. It was Sunday, March 22nd, right after the shelter in place order went in effect here in California. The next day, COVID-19 was no longer just in the news, it was everywhere.

Free and open source software (FOSS) components have become the basic building blocks of our software products, helping today’s developers build and ship innovative products faster than ever before. Many developers tend to forget that while open source licenses are free, they still come with a set of terms and conditions that users must abide by.

You work hard to produce quality applications on tight deadlines, and like every other development team out there, that often means relying on open source code to keep projects on track. Having access to plug-and-go code is invaluable when you’re racing the clock, but the accessibility of open source libraries comes with a caveat: increased risk.

Open source components are a major part of the software products we create and use. Along with the many advantages that using open source projects brings to software development organizations, it also comes with obligations and added responsibilities. One of these requirements is open source licensing compliance.

Have you ever wondered whether it’s ok to copy and paste code from an open source project? If you have, you’re not alone. A quick look around several developer websites shows a number of variations on this age-old question. It is never ok to copy and paste code from an open source project directly into your proprietary code. Don’t do it. Just don’t. Even if you’re on a tight deadline. Even if it’s only one loop.

When we think of open source analysis, security is often the first thing that comes to mind. But open source analysis is so much more than just security. It gives you visibility into your codebase to help you understand and manage your open source components. In this blog, we’ll define open source analysis, look at why it’s important to your business, and describe the characteristics of an effective open source analysis framework.

We now live in an era where the security of all layers of the software stack is immensely important, and simply open sourcing a code base is not enough to ensure that security vulnerabilities surface and are addressed. At Gravitational, we see it as a necessity to engage a third party that specializes in acting as an adversary, and provide an independent analysis of our sources.

I am not an engineer. I’m a director of human resources. I don’t work in a technical space, but the concept of open source is fascinating to me as it applies to organizational culture. A company like Gravitational that has intentionally chosen open source as a foundation for our work makes not only a technical decision, but a cultural one. We’re finding that employees and candidates care deeply and appreciate our choice. Open source is a big deal for us.