How to read open source license obligations

Interpreting open source licenses requires considerable skills and experience. Ideally, engineers and lawyers work together: Lawyers know the meaning and consequences of legal terms, and engineers can make sense of it in the context of software. There are some basics, however, that help set your thinking straight.

A critical aspect is: What is a (re-)distribution ? You distribute code (binary or source, doesn’t matter), if you pass it on to another legal entity. Legal entities can be both regular people (“natural person”) or companies (“juristic person”). If the code does not cross such a boundary, it is not being distributed.

Licenses have

  • permissions (what you are allowed to do),
  • obligations (what you must do to receive the permissions), and
  • prohibitions (things you are not allowed to do).

Most obligations are conditional on you distributing the code. No distribution, no obligations. (Open source program offices often model this using open source use cases and distribution cases, but this topic is beyond the scope of this blog post.)

Of the two categories of open source licenses, copyleft licenses require that the license itself propagates; you can’t shake it off. Permissive licenses, the other category, only require that you fulfill the individual obligations, but then can provide any larger aggregate (“derivative” or “combined” work) under a different license.

Let’s take a look at the BSD 2-clause license, a simple straightforward permissive license. Its second clause (of two) states:

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

See https://opensource.org/licenses/BSD-2-Clause

First, in contrast to a copyleft license, it is important to notice that there are no effects on code outside the BSD 2-clause licensed code. Whatever and however you combine this code with, is not affected by this license.

Second, you have to create a set of notices, generally called the “legal notices”, as you distribute this code whether it is integrated with your code or standalone. How to do so, is left somewhat vague (“in the documentation”).

Most people are interested, however, in what happens when they integrate or even modify the BSD 2-clause licensed code. So:

Third, a binary in which you hold some copyright (because you modified the original code or extended it) can be provided under a license of your choice, as long as you abide by the obligations of the included BSD 2-license code.

In short, you can’t get around the obligations, but from an intellectual property perspective, they are benign and don’t get in the way of you commercializing software that you build on so-licensed code.

If you would like to learn more about open source licenses, how to comply with them, and how to deliver a product that includes open source software in a license compliant way, I recommend my license-compliant delivery seminar and handbook.

Back to open source license compliance and work-for-hire.

Posted on

Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share the Joy

Share on LinkedIn

Share by email

Share on Twitter / X

Share on WhatsApp

Featured Startups

QDAcity makes qualitative research and qualitative data analysis fun and easy.
EDITIVE makes inter- and intra-company document collaboration more effective.

Featured Projects

Making free and open data easy, safe, and reliable to use
Bringing business intelligence to engineering management
Making open source in products easy, safe, and fun to use