Use case example questions

[joehand]

We are looking at using license zero for https://github.com/datproject/dat (command line application) and https://github.com/datproject/dat-node (high-level Node.js library for building applications). I am getting a bit confused about the different cases when a license is required or not, especially with end-user applications such as the Dat CLI. Additionally, I can't figure out how these work with stacked licenses/sublicenses

I see this example in the guide:

A developer employed at a for-profit company wants to use your video player application to show commercials in their office lobby.

But the A developer part confused me. Is this just a user of the video player application?

Modules in question:

• Dat (user application used via command line npm install -g dat)
• dat-node (Node.js library)
• neat-log (L0-noncommercial licensed Node.js library for command line output

Example

• Dat CLI is BSD licensed
• dat-node is L0-reciprocal licensed (hypothetical)
• neat-log is L0-noncommercial licensed

Dat CLI is both noncommercial and open source for our own development. I assume we do not have to buy a private license for neat-log or dat-node. But I do not understand how these licenses stack or are sub-licensed to end users.

Question:

• Does a commercial user using Dat CLI have to buy a license?
• Does a user building closed-source software using Dat CLI have to buy a license?
• What licenses to they have to buy?

In general, I do not understand how/if applications such as Dat CLI work with L0 (whether using L0 itself or with dependencies). Is there anywhere I can read about this? Most of what I've found is about software dependencies.

(Unrelated comment, I am getting a bit confused in general with the terms. Sometimes the license types are referred to as parity/charity and sometimes noncommercial/reciprocal. Then the L0 project page doesn't list either of these terms: https://licensezero.com/projects/0153a099-6acd-4023-8a96-9d81d9969a58)

[joehand]

To get at a specific example that's confused me. Oregon Health and Science University is a public research university but makes a profit off some of their research. If we license Dat CLI as L0-noncommercial:

• A researcher at OHSU wants to use the Dat CLI to transfer data to a colleague. Do both parties need a private license?
• A researcher at OHSU wants to use the Dat CLI to transfer data to a for-profit company. Do both parties need a private license?

[joehand]

Reading through this relevant discussion: https://github.com/licensezero/licensezero-private-license/issues/1. Though I think that is leaving me more confused about sub-licensing...

[joehand]

The examples in https://github.com/licensezero/licensezero-examples-and-explanations/blob/master/EXAMPLES.md were helpful in understanding how licenses on Dat CLI may be used. But I still am lost in to how sublicensing for dependencies would work.

[kemitchell]

@joehand Thanks for your note! Let's think through this together.

First things first: Confusion on Reciprocal/Noncommercial and Parity/Prosperity is very justified. L0 switched to Parity and Prosperity in the past couple of weeks. You can think of Parity as Reciprocal 2.0 and Prosperity as Noncommercial 2.0. We do find the new names help avoid confusion. I'll use them from here on out, and do another pass through the website and the Go CLI to make sure I've updated all the explanations there.

Back to your plan. The prospect here, as I understand it:

• https://www.npmjs.com/package/dat under BSD License
• https://www.npmjs.com/package/dat-node under Parity
• https://www.npmjs.com/package/neat-log under Prosperity

A couple more important relationships:

• dat depends on dat-node
• dat depends on neat-log

And an assumption:

• Your organization either owns all copyright in all of these packages, or has the right to use and license it however you choose.

You probably see this coming: You should double-check what follows with your organization's lawyer. I can't give or stand accountable for legal advice via GitHub. L0's terms of service have to make clear that it's up to you to decide whether the approach is a good one for you.

The dependency relationship between dat, dat-node, and neat-log create a web of licenses. Users of dat need a license not just for the code of dat itself, but for the code of the packages it depends on. That means they need a license for dat-node and neat-log, as well.

In broad strokes:

• The BSD license for dat lets users do pretty much whatever they like with the dat code.
• The Parity license for dat-node requires release of source code for software built with dat-node.
• The Prosperity license for neat-log requires limiting commercial use to a trial period of 32 days.

To use dat, the CLI, with its dependencies dat-node and neat-log, users have to follow all of those rules for the combined, complete dat program. So:

• Users must limit commercial use of dat to a trial period of 32 days.
• Developers who build on neat-log via dat must release source code for their software.

What if users don't want to limit commercial use to 32 days, or to build closed, proprietary software on top of dat, or specifically neat-log? Let's look at how private licenses would fill the gap:

• Each user who wants to use dat commercially, without building software on it, could buy a private license for neat-log. The "Copyright License" and "Patent License" sections of the private license would give them permission to use neat-log without any trial time limit.
• Each developer who wants to build on dat (with neat-log) or neat-log alone could buy a private license for neat-log. Again, the copyright and patent sections of the private license give them permission to work with the software, without releasing source code. However, the Sublicensing section of the private license, in particular rule 2, prevents them from passing on permission to create closed, proprietary software to anyone else. Each developer building closed software on neat-log needs their own private license.

[kemitchell]

@joehand you asked a few specific questions about Oregon HSU. I don't know OHSU's situation, or the researchers you have in mind there. But I can point you right to the part of Prosperity that would matter for them. From current version 1.0.0:

1. You must limit use of this software in any manner primarily intended for or directed toward commercial advantage or private monetary compensation to a trial period of 32 consecutive calendar days.

This definition of commercial use---in any manner primarily intended for or directed toward commercial advantage or private monetary compensation---is the same as in the noncommercial Creative Commons licenses you may have run into.

With academics, may of whom are involved in industrial application or business-funded research to some extent, the question under this kind of language is whether gain is their primary motivation. Prosperity doesn't limit use that's just arguably, possibly, or secondarily commercial.

[kemitchell]

@joehand You mentioned licensezero/licensezero-private-license#1. That issue has big potential to confuse. @makkus and I didn't stay on topic, had lots of prior correspondence, and eventually tweaked the private license text as a result. I'm going to close the issue, to keep anyone else from stumbling into it.

When thinking about the private license and how it works, I'd suggest you start form this basic outline, comparing it to a permissive license like BSD or MIT:

• Like BSD, the private license is permissive. There are no commercial-use trial periods or requirements to release source code under the private license.
• Unlike BSD, the private license applies only to the person buying the license. That makes it a "private" license, rather than a "public" license like BSD.
• Unlike BSD, those who buy private licenses can only pass their rights on to others, like end-users, under specific rules. Those rules are in the final "Sublicensing" section, which I strongly recommend that you read.

In current v4.0.0 of the private license, the Sublicensing section looks like:

Sublicensing

If you combine my contributions to the project with other software in a larger program, you may sublicense my contributions to the project as part of your larger program, and allow further sublicensing in turn, under these rules:

1. Your larger program must have significant additional content or functionality beyond that of the project, and end users must license your larger program primarily for that added content or functionality.

2. You may not sublicense anyone to break any rule of the public license for my contributions to the project for any changes of their own or any software besides your larger program.

3. No Liability, Defensive Termination, Sublicensing, and Redistribution must apply to each sublicense.

   You may build, and sublicense for, as many larger programs as you like.

You can ignore rule 3 in your first read through. Its effect is like BSD, while rules 1 and 2 are different.

The motivation behind rules 1 and 2 is making sure is making sure that one person with a private license can't give everyone else permission. If they could, there'd be no reason for anyone else to buy a private license.

[joehand]

Thanks! That is extremely helpful.

I think your examples in the second of each set of the last 4 bullets switched neat-log for dat-node:

Developers who build on ~neat-log~dat-node via dat must release source code for their software.

Each developer who wants to build on dat (with ~neat-log~dat-node) or ~neat-log~dat-node alone could buy a private license for ~neat-log~dat-node. Again, the copyright and patent sections of the private license give them permission to work with the software, without releasing source code. However, the Sublicensing section of the private license, in particular rule 2, prevents them from passing on permission to create closed, proprietary software to anyone else. Each developer building closed software on neat-log needs their own private license.

---

A few remaining questions. If I am understanding correctly the prosperity license:

This limit does not apply to use in developing feedback, modifications, or extensions that you contribute back to those giving this license.

In this case, that feedback, modification, etc. would have to be for neat-log, not any higher-level applications. If a user was developing feedback, etc. for dat in a commercial setting they'd still need a license.

The last place I am struggling a bit is with this language of "Each developer who wants to build on dat". In the license, I think the applicable line is:

Release all source code for software that you analyze, change, or otherwise make using this software.

Specifically, the "otherwise make using this software" part seems a bit squishy to me. I can't tell if this is meant to be wholly inclusive or more restricted. Dat is a pretty generic tool. Does that mean anytime someone uses Dat to transfer files for a piece software, all their code needs to be open sourced unless they have a license?

As another hypothetical example, a company is building closed-source, commercial software on the Dat Protocol (not using dat-node). They use Dat CLI to test their application twice, today and 33 days from now. Would they be required to buy both licenses (neat-log and dat-node) for every developer that uses the Dat command line to test their application?

Thanks for your help! I'll be happy to summarize these to high level answers for my own benefit, and to share with the community.

[joehand]

I guess a more straightforward question for that last part.

neat-log is used in a chat application (like Slack), Cabal. With the L0-prosperity license, anyone using Cabal for "primarily intended for or directed toward commercial advantage" must buy a neat-log license. I follow that.

If neat-log is L0-parity licensed. Anyone using Cabal to communicate in order to develop software must either:

1) Release software as open source 2) Buy a license

Does that fall under the "otherwise make using this software"? What if they are making software-like things (say, digital art)?

[kemitchell]

I think your examples in the second of each set of the last 4 bullets switched neat-log for dat-node:

Thank you for correcting!

And forgive me. I use Dat every day. But I'm not up to date on its dependency tree. Though I'm sure I use some of those every day, too.

This limit does not apply to use in developing feedback, modifications, or extensions that you contribute back to those giving this license.

In this case, that feedback, modification, etc. would have to be for neat-log, not any higher-level applications.

That's how I'd read Prosperity, too. "This software" is neat-log, not the dat program that depends on it.

I hadn't thought about allowing continued use in developing feedback, modifications, or extensions to other programs by the same author. I've opened a request-for-feedback issue on the Prosperity repo and mention you there: https://github.com/licensezero/prosperity-public-license/issues/1

Specifically, the "otherwise make using this software" part seems a bit squishy to me. I can't tell if this is meant to be wholly inclusive or more restricted. Dat is a pretty generic tool. Does that mean anytime someone uses Dat to transfer files for a piece software, all their code needs to be open sourced unless they have a license?

@makkus brought this up, too. You can read my original response in the "Analyze, Change, Make" section of https://github.com/licensezero/parity-public-license/issues/9#issuecomment-400780482.

Long story short, you're absolutely right. This part is squishy. From my point of view, you asked exactly the right follow-up too. Does "make" restrict or expand the set of situations where rule 3 requires release of source code?

I would read "analyze, change, or otherwise make" to cover examples like the primary use cases of Standard (analyze), Prettier (change), Browserify (make, arguably change), Atom (make), and code generators. I would not read it trigger on use of programs like GitLab, Trello, or IRC. But others could read it differently, especially with the right motivation.

The question is who bears the burden of that ambiguity? The more specific the rule's language tries to be, the more I think that favors users, because more use cases will fall outside the specific language, which will also likely go out of date. The squishier the rule's language remains, the more I think it favors licensing developers. It will often be cheaper to release source code or buy a private license than argue about, say, "make" in context.

[kemitchell]

@joehand re Slack, it could depend on the situation. But it wasn't my intent, drafting the license, to cover that kind of scenario.

At the bottom of https://github.com/licensezero/parity-public-license/issues/9#issuecomment-400780482 I wrote:

I don't think folks would expect the license for their project management system to require open source release. Parity is different from the kinds of share-alike licenses we've seen before, but it's still a license for tools rather than platforms. Parity works great for platforms, and requires those making changes to platforms to share them. But it doesn't try to help platform programmers set rules about work that gets discussed on their platforms, rather than made in some more direct sense on their platforms.

I wouldn't be surprise to meet a platform developer someday who changes my mind, for a platform that's almost all about developer communication, rather than writing or analyzing code. In the meantime, some platforms might include tools, like text editors or code analyzers, with Rule 3 implications under the current version of Parity.

I will put some more thought on clarifying this in the language. If I can find a succinct, plain way to express the difference, I think it would be worth a little length. But I don't want to start down a path of evolving the rule's language over every use case. That's how we end up with huge licenses:

But a number of other factors at play in the drafting of GPLv3 unintentionally caused the complexity of the license to grow. Lawyers representing vendors' and commercial users' interests provided useful suggestions for improvements from a legal and commercial perspective, but these often took the form of making simply worded provisions more verbose, arguably without net increases in clarity. Responses to feedback from the technical community, typically identifying loopholes in license provisions, had a similar effect.

https://opensource.com/article/18/6/gplv3-anniversary

[joehand]

Thanks! This got to be pretty specific, so I will close.

The platform case is a good example and I'll work from that assumption moving forward. As discussed, there is a tough balance of sustainability and adoption. But giving the burden to the users does seem to be the right approach.