Firewall Best Practices: Quarantine for Copyleft Licenses

Sonatype Lifecycle & Repository Firewall Best Practices
, , ,
1

Quarantine for Copyleft Licenses

Have you rolled out quarantine to all your repositories? I’m always eager to learn more about what you’re blocking and why you’re blocking it – especially for apps that won’t ever be distributed to an end-user.

Brass tacks here – some licenses should almost never be used in the software you distribute to others. The GPLv2 is a good example. As a copyleft license, it has some strict requirements that might not be compatible with your business goals.

But! If your usage of a component with the GPLv2 license is purely internal (like, for testing environments), then those requirements may not apply, which means quarantine might not be necessary.

Speaking generally, the best practice is to quarantine for the License-Copyleft policy for apps going to production, but consider warning only for apps that are purely internal.

Of course, your Legal department may not agree. They’re the experts and the stakeholders who need to manage legal risk, so follow their lead.

So, here’s the challenge. Take a look at the two examples below, and tell us which one should have the License-Copyleft policy set to “Quarantine” and which one should have it set to “Warn.”

  1. A repo (named maven-proxy-usaeast1-prod) is hooked up to an automation server like Jenkins or Bamboo. A build task completes once a day, and the resulting .exe file is automatically pushed to a website, where any user can download it.
  2. A repo (named maven-proxy-product-testing) is used by four developers to build custom testing tools as part of a QA cycle. The repo isn’t used by anyone else, and whatever the team develops gets archived on an internal server somewhere.

Chances are you didn’t have to think too hard – but give us your answer in the comments, anyway! And for more, check the rest of the best practices posts and visit us at learn.sonatype.com.

8 Likes
2

Distribution is the keyword. If the app does not get distributed (depending on the meaning of distribution within the license) you should be clear. How do you prevent others from using the library in an app that does get distributed? That’s a bigger challenge.

3 Likes
3

Exactly. I am not a lawyer, BUT it’s the distribution that sort of activates the license’s requirements. No distribution, no requirements.

(Again, Legal teams may disagree or have a more risk-adverse attitude – they’re the experts.)

Of course, this raises the question “what does it mean to distribute something.” There’s nuance, and again I’m not a lawyer, but we can generally something has been distributed when the end-user can access and use it without any external support from the manufacturer.

1 Like
4

As for how to prevent someone from using the library?

Well, if you mean “how to prevent a library that has a copyleft license from appearing in something I distribute ,” then blocking with policy is the right thing to do. You can even use Lifecycle’s built-in application categories of Distributed, Hosted, or Internal to help.

Read about application categories here.

But if you mean “how to prevent a library I made with a copyleft license from accidentally appearing in something I distribute,” that’s a much trickier question. For starters, if you’ve developed a library that simply cannot go into a production environment, don’t put it somewhere a production dev can access. We already encourage you to store artifacts in a Nexus Repository repo; make sure the repo can only be accessed by your testing devs.

1 Like
6

1 - Quarantine
2 - Warn