The most valuable feature is its ability to identify all of the components in a build, and then surface the licenses that are associated with it, allowing us to make a decision as to whether or not we allow a team to use the components. That eliminates the risk that comes with running consumer software that contains open source components. It allows us to be ahead on that so that we are in compliance with open source rules, so that our company is seen as a good steward of open source.

We also like their policy engine because it is very simple in that it is a "red, yellow, and green" mechanism, like a stoplight that everybody's familiar with. Red to deny, yellow to flag, and green to approve. We found that to be in direct correlation with how we were viewing licenses. We've added a couple of policies since then that are not covered in FOSSA directly, but their policy engine has been flexible enough to allow us to accomplish adding what we call "white licenses." That means they have no color assigned yet because we've never seen them in our ecosystem. We have a way, through FOSSA, to identify those using the API, which extends the policy engine for us. It does the same for "black licenses," licenses that we just flat out deny.

And because of the way their policy engine works, its accuracy is fairly high. It identifies multiple licenses on some components and makes a decision for us. It would be beneficial to be able to affect some of those, twiddle some knobs and change some dials in the background for how those are handled, but for the most part, it works all-around.

I am impressed with the tool’s seamless integration and quick results.

Being able to know the licenses of the libraries is most valuable because we sell products, and we need to provide to the customers the licenses that we are using.

It is easy to use with a wide range of developer ecosystem tools, and I would rate it a 10 out of 10 from this perspective.

It is holistic in terms of collaboration between the legal teams and DevOps. As a security specialist, I'm just helping developers to set up their repositories. It is the legal team that takes a case up with the Dev team.

I view FOSSA as a singular tool, not really one that has components, so it's hard for me to say that there's a valuable feature. FOSSA, to me, is something that scans, and it determines what you have and if there's a problem. But if I were to call it a feature, the most valuable would be the deep dependency scanning.

If I were to use another tool that scans source code but not during build-time, one that just scans the source code as a static thing, then it would tell me what it thinks goes into my mobile app. But when I use FOSSA, and it scans during the build, it tells me what actually goes into my mobile app. I believe it's a more accurate way to determine what's in my code, because it not only tells me what my code says should go, but it tells me what actually goes during the build. When the build pulls artifacts from an artifact store, FOSSA detects that happening.

I found FOSSA's out-of-the-box policy engine to be accurate and that it was tuned appropriately to the settings that we were looking for. The policy engine is pretty straightforward. When it comes to licenses, there are always very strange cases that no policy engine can predict, so those happen once in a while. But for the most part, in terms of an automated policy engine, I find it to be very straightforward to make small modifications to, but it's very rare that we have to make modifications to it. It's easy to use. It's a four-category system that handles most cases pretty well.

The way we've set it up, it's compatible with our build and packaging system, and that's all we need it to be. So it's perfectly compatible.

The solution provides us with contextualized, actionable data, but I wouldn't call it "intelligence." It gives us a signal which says, "We have found a violation." As an analogy, data tells you what the temperature is outside. Intelligence tells you that the temperature is so cold that you have to wear a sweater, and wisdom is to know that you can't wear a sweater over a coat. Those are different. So FOSSA gives us data. It tells us there's a problem. It doesn't tell us much about how to fix the problem. It tells us where the problem is, but it doesn't give us intelligence. It gives us data. It provides us the signal of the problem and the component that is causing the problem, and allows us to inspect that component to see if it really is a problem.

FOSSA has a feature that allows you to automate the scanning of licenses. You can do that by setting up different policies that are custom-tailored for your organization, which in my case are legal policies or intellectual property policies. These policies are used to scan the open-source licenses and flag them, approve them, or reject them based on your company's preferences. One of the things that I really love about FOSSA is the way we can take what would manually require probably hundreds of hours of individual review and automate that through this platform.

In terms of ease of use and accuracy of its out-of-the-box policy engine, it is certainly very easy to use. It is also very accurate. There were some things that we custom-tailored based on our risk appetite and our internal policies related to intellectual property. The out-of-the-box policies were great, but we just slightly tailored them for what we needed for our use case. The majority did not need tailoring, and across the board, all of the policies that were out of the box were consistent with the decisions that I would have made in the absence of internal policies that I had to be mindful of.

One of the things that I really like about FOSSA is that it allows you to go very granular. For example, if there's a package that's been flagged because it's subject to a license that may be conflicts with or raises a concern with one of the policies that I've set, then FOSSA enables you to go really granular into that package to see which aspects of the package are subject to which licenses. We can ultimately determine with our engineering teams if we really need this part of the package or not. If it's raising this flag, we can make really actionable decisions at a very micro level to enable the build to keep pushing forward.

It is a combination of both features and the perspective that FOSSA tries to take, which is sort of different than a lot of their competitors. The main feature and perspective that they take is their desire to be embedded within the software development lifecycle as close to the introduction of dependencies as possible. That has allowed us to build these checks and FOSSA execution into the pull request checks that run automatically whenever an engineer opens a pull request to introduce new code changes into a code base.

The solution’s compatibility with a wide range of developer ecosystem tools is incredibly easy to use. I've written a handful of scripts to even ease that process even more. It is at the point where, in order for one of our teams to integrate FOSSA into their development process, it requires them to add essentially two commands to their pull requests check pipeline. That builds in a bit more functionality than the FOSSA command line tool provides out-of-the-box. However, just executing FOSSA can be achieved by adding a single line to a continuous integration pipeline. With all of the various platforms that you can use to build your project, FOSSA is incredibly easy to integrate.

Their CLI tool is very efficient. It does not send your source code over to their servers. It just does fingerprinting. It is also very easy to integrate into software development practices.

The box policy was great. It was very closely aligned. We had multiple policies depending on which code base we were scanning so we had some code that was software as a service and we had some code that was distributed. We had different policies for that. The policy-setting at FOSSA is the number one reason I picked it because the policy set up and having the different policies was so easy and so intuitive. It was really exactly what I needed for what we cared about at my company, what we were looking for, and the checking again as the policy and licensing really meshed well with the way FOSSA did it.

I like that their result set with very tailored. Some other open-source license management things, like Flexera, for example, would do a really in-depth, crazy scan where it gives you 10,000 results and then you have to go through and check which result sets you actually care about and clear the stuff that you're not concerned about it, which was too time-consuming. FOSSA is very tailored. It gives us the dependencies that we know we use.

FOSSA's result set was very tailored to what I cared about. I didn't have to send a whole bunch of time clearing a whole bunch of false positives. I was really the only person on the legal team doing open-source compliance. I didn't have a whole team of compliance people to go through and look at a million potentially false positives. I needed something that would just give me the information I cared about and then tell me if there was a change once I had approved the ongoing list.

In terms of its compatibility with the wide range of developer ecosystem tools, when I was at my previous company, we'd use it with three different CI tools. We used it with CircleCI, Travis, and with Jenkins. It was set up to work the best with CircleCI. I thought it was pretty easy to set up with all three. I think it depended on the complexity of your CI setup. Like Jenkins, for example, which is notoriously difficult to set up, the setup there was also pretty complex.

Overall, I thought it was pretty easy to set up. I did most of the coding myself and I'm not a software engineer anymore but I was still able to figure it out. It was pretty easy, pretty compatible, pretty user-friendly and certainly, for an actual true software developer, not a reformed one, it wouldn't be a problem for someone to set up and use.

It made it so that it was something that even a legal team could set up. It's a one-time setup and then you're just off and running unless you change something or add a new repository you want to do scanning on. It's great. Setting it up in the CI and having it run was one of the appeals. 

The scalability is excellent.

Policies and identification of open-source licensing issues are the most valuable features. It reduces the time needed to identify open-source software licensing issues.

It is holistic in terms of collaboration between the legal teams and DevOps. I'm legal, and I work with DevOps. It identifies licensing issues in DevOps projects that legal can review.

It cuts the software engineers work a lot. Because if it is already approved and scanned, then they don't have to do it again. 

The solution is holistic. Our legal teams and DevOps work hand in hand with it. For example, we have a legal team who is part of the setup for FOSSA. 

The most valuable feature is definitely the ease and speed of integrating into build pipelines, like a Jenkins pipeline or something along those lines. The ease of a new development team coming on board and integrating FOSSA with a new project, or even an existing project, can be done so quickly that it's invaluable and it's easy to ask the developers to use a tool like this. Those developers greatly value the very quick feedback they get on any licensing or security vulnerability issues.

The out-of-the-box legal policies are very good but I think that they lack thoroughness of some of the unclassified licenses. The accuracy was good, I don't think I had to make any major changes. I would only have to make changes if I were a risk-averse or an incredibly risk-tolerant company. But if you're middle of the road, the out-of-the-box legal policies are pretty acceptable. It probably just needs to classify more of the unclassified licenses in one of the three categories for disposition to get a better starting point for new companies adopting the out-of-the-box policies.

We use the security vulnerability management features. I give the developers a heads up that there might be some published vulnerabilities that they might be unaware of. It's good because it gives them really quick feedback, so if they're doing a nightly build they'd get feedback the next day, or if they're building it right away they might get near-immediate feedback. But we don't have any enforced policies regarding security vulnerabilities, especially for internal or hosted applications. 

The background and information these features provide on security workflows is just integration to the national vulnerability database, so it's limited to the data that's contained in the NVD, which of course is standard industry-accepted vulnerability data. There's definitely room for growth there and actually doing analysis of the proprietary code, but looking at the NVD information as a baseline is certainly useful.

In terms of the compatibility with a wide range of developer ecosystem tools, the interoperability with different developer ecosystems is excellent, and that's actually one of the reasons we chose FOSSA as our enterprise solution. Even if they didn't have out-of-the-box compatibility with a certain build environment or a build pipeline, they were able to get it working with one of them or any of the new environments very quickly. It definitely has industry-leading interoperability for different build environments, which is really valuable to us.

This affects our open-source management operations by allowing for a much greater deal of efficiency. As part of the legal team, having to look at an incredibly large volume of open-source components coming into the company, it was immensely time-consuming and it took away attorney's resources from more mission-critical or more complex responsibilities, such as embedded software or any software being distributed outside of the company. Having it as a resource to very quickly triage incredibly high volumes of open-source coming into the company through agile development programs was invaluable.

It is holistic and helps us work with both legal teams and DevOps. It's a great way to help legal and development teams work together by automating a lot of the guidance that gets provided in the more straightforward scenarios like internal development or projects that aren't externally distributed. It's a great resource for having a centralized place for all of the outstanding issues to provide automated, legal, and security guidance to those development teams.

My team is purely legal, but I would say that there's definitely a lot less person power required to address any license concerns as the majority of license questions are resolved in an automated fashion by us populating the license policies in the tool as completely as possible. So the more completely we populate those license policies, the more of that work is offloaded to the tool from my legal team, which is excellent for making more available time where it's more valuably used. 

It has decreased the time our staff spends on troubleshooting by 10 to 20 hours per week where an attorney could have that time then reallocated to something more important.

The most valuable part is the open source license compliance.

The solution’s out-of-the-box policy engine's ease of use is very high. It works extremely well. That's easy to quantify. Its accuracy seems really good, but I have not diligently measured it. When we have checked what it is doing, it has all come out great. We're extremely happy with the results, but I can't say that it is an accurate product.

The solution’s compatibility with developer ecosystem tools is pretty good. There is some stuff within the C++ world that we haven't been able to get it to work very well with, but that's a really small amount of what we do. Most of our stuff is in Clojure and in Ruby and all the things that we want FOSSA to do there are great. It's not like we have a wide scope of developers who are using it. I'm effectively the only person actually using FOSSA. I just gather up all the information and all the repos from all the other parts of the company and run scans on them daily. I'm the major customer here.