Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Operating Without an OSS License? That Could Be Dangerous!

DZone 's Guide to

Operating Without an OSS License? That Could Be Dangerous!

If you are using open source software without paying attention to its licensing, you could be in trouble.

· Open Source Zone ·
Free Resource

Unless you are an intellectual property lawyer, talking about software licenses probably ranks pretty low on topics you want to discuss. I have good news and bad news. First, the bad news: you have to talk about it. The good news: you can use Nexus LIfecycle to manage them so you don't have to think about them too much.

You might be asking yourself, Why do you need to worry about them? If it is open source software (OSS), can't you just use the software? It depends (how is that for a legalese answer?).

Thankfully, Jerry Gergel and Melanie Latin, both with Sonatype, walked through some things to think about and how Nexus Lifecycle can help you manage OSS licenses for your artifact repository at the 2018 Nexus User Conference.

Their presentation answers the following questions:

  • What is OSS licensing, and more importantly, why do I care?
  • What do I really need to know to get started?
  • What are the woes of those who didn't care (or were unaware)?
  • How can Sonatype's Nexus Lifecycle help you?

It is important to remember that it is the intent of OSS licensing to make sure the software can remain open source and freely used. Many people assume that OSS licenses allow you to use the code freely, at your own risk, with acknowledgment of the author(s). However, some licenses contain requirements that could conflict with your business objectives. For instance, they might require you to make any software available that you use the OSS in.

This is called copyleft. Yes, that is a thing and it is a play on copyright, in case you missed that. It is important you are aware of which OSS packages carry these licenses, what their specifics are, and what your policies are on what requirements are allowable and which are not. Oh, and the licenses might change requirements or have different requirements for different versions.

Some common examples of permissive licenses:

  • BSD (Berkeley Software Distribution)
  • MIT
  • Apache 2

Some common examples of copyleft licenses:

  • Affero GPL (AGPL)
  • GPL
  • Lesser GPL (LGPL)
  • Mozilla Public LIcense (MPL)
  • Eclipse Public License (EPL)
  • Common Development and Distribution License (CDDL)

Jerry dug into the specifics on one copyleft example, the GNU Affero General Public License v3. It allows for commercial use, modifications, and distribution. It does not allow you to hold them liable or sublicense it, and it requires you to retain the copyright, include the license and install instructions, and disclose your source if distributed or published as a service (modified or derivative).

All of this begs the question, "What is our organization okay doing anytime, for certain software packages, and never?"

To help with this, Jerry laid our four questions you should answer:

  1. What is "distribution" and how does it relate to my organization?
  2. How do open source licenses affect patent rights in software?
  3. What is the "notice" requirement and how do we comply?
  4. Do we have "derivative work" and, related, does incorporating GPL code into my proprietary code cause the proprietary code to be licensed under GPL?

If you are answering these questions, you are managing your risk well.

Of course, Nexus Lifecycle can help. Nexus Lifecycle will catalog your licenses and show you what is risky based on your own policies. It also shows you security vulnerabilities alongside license information, so you can make judgment calls about each package before using it.

It can tell you:

  • What licenses are in my open source libraries?
  • Which OSS licenses are declared and observed?
  • Define your own policies to help guide development teams

The Sonatype Team also does its own research to see if one OSS uses another OSS with another license, and which one is effective/recognized. Nexus Lifecycle will show when licenses change and maybe you can pick a different version of the license that has more favorable license requirements. It will also show suggestions of which licenses are liberal, banned, allowable, etc. with different threat levels associated with each of them. Of course, it is fully customizable to your own governance policies.

Finally, you can customize what actions are taken if risky licenses are used, from notifications to different people to breaking a build. Lifecycle can also notify you at different points in the process. For instance, do you want to notify the developer if they pull down a OSS with a risky license? This helps you shift-left.

The bottom line: know your licenses, know your organization's needs and risks, and Nexus Lifecycle can help you manage all of your licenses to manage your risk. One last thing — talk to your lawyers before you set policies or accept licenses. We make software and provide information, but don't know your specific legal requirements.

You can listen to their full talk on OSS Licenses here and learning more about all of the Nexus products here.

And, keep an eye out for more session recaps from the 2018 Nexus User Conference — we'll be sharing many of them leading up to this year's conference on June 12.

Topics:
open source ,licensing ,copyleft ,copyright

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}