Sublicensing and "significant additional content or functionality"

[makkus]

As a non-law-savy persion, this might be a silly concern so feel free to ignore if that's the case, but I'm wondering if it wouldn't make sense to have an option to restrict sub-licensing.

For the purpose of this example, let's assume monetary value somewhat resembles 'actual' value, and work done on something. Say I wrote a command-line tool that saves some people some time. I license it using Prosperity and I price it at $5. Now somebody else comes along and writes a really neat GUI for that tool. The work they did can be considered substantial, they worked twice as long on it as I did on my cli tool which is necessarily included in their product (and of course they buy a license for $5 from me), along with potential other cli-tools their GUI makes easier to use. People who are not comfortable with the command-line would never use my tool, but they can use the GUI tool, which is the main reason they buy a license for it. The GUI tool is reasonably priced at $10, but end-users would get a $15 product, and the GUI developer can get more sales because the end-product is cheaper than it's actual value. I only get $5, once. On a side-note: I'm not sure whether end-users of the GUI would be allowed to directly use my cli tool, as it comes with the GUI distribution.

I'm aware this example stands on shaky grounds because of equaling monetary value with work done, and maybe 'significant additional content or functionality' has a meaning in law-speak that is much stronger than it sounds to me. But maybe it gets my point across. I think it's a difference whether you sell a license to an end-user, or to be used as part of another product. The value differs to the buyer, because if they can buy one license they can only 'use' it once themselves, but under the right conditions they can 're-sell' it multiple times. In the case of licensezero, I think this ambiguity wouldn't necessarily be ...necessary.

Because it comes with a tool that can already deal with situations like the one I described, the stacked license feature. As it can easily be automated, the GUI tool dev could just buy a license for my tool whenever they sell their own product on behalf of their customer, and include it in their invoice (there might be tax-implications I don't know about though). Or the end-user buys directly from licensezero.com (although, unlikely, as we've established they don't like the command-line :-) ) if the GUI tool can also be purchased via it.

Anyway, just my initial thoughts when reading the license.

[kemitchell]

As a non-law-savy persion, this might be a silly concern so feel free to ignore if that's the case,

That’s not how this works! As an obviously savvy non-lawyer, your impressions and feedback matter more than anything. License Zero is not for lawyers. It’s for developers. Its terms ought to please lawyers who look into them. But that should be necessary as infrequently as possible!

Or the end-user buys directly from licensezero.com (although, unlikely, as we've established they don't like the command-line :-) ) if the GUI tool can also be purchased via it.

The website doesn’t broadly advertise the fact that each L0 project gets its own project page. Users can buy licenses for the project directly, at the bottom of that page.

Whenever possible, L0 encourages use of the CLI. There are big benefits to teaching the CLI, for specific projects and the seller community as a whole. But it’s not the only way.

I think it's a difference whether you sell a license to an end-user, or to be used as part of another product.

Absolutely. Here’s the relevant part of the private license form:

Sublicensing

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

  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 additional content or functionality.

How do we change number 1 to address your scenario? I see two possible approaches:

1. Make a specific exception for developer tools and libraries, rather than end product applications.

2. Address the “loophole” that allows sublicensors to sublicense wrappers around individual programs, like GUIs, by wrapping many applications, not just yours. This would likely happen in the language about end user purpose.

[makkus]

That’s not how this works! As an obviously savvy non-lawyer, your impressions and feedback matter more than anything. License Zero is not for lawyers. It’s for developers. Its terms ought to please lawyers who look into them. But that should be necessary as infrequently as possible!

Right. Yeah, I think this is just one of those topics that I thought was so far removed from my normal mode of thinking that I better not try to come up with an opinion, and if I do by accident, I'll better make my own perceived incompetence crystal clear :-)

How do we change number 1 to address your scenario? I see two possible approaches: ...

I'm not sure. I guess it's not always clear in which category a product falls, it might depend on the circumstance on how it is used. If for example the "docker build" command was a standalone application that was 'Licensezeroed', developers would use it directly to create Docker images, and they would distribute those images either freely (so in the case of Parity there would be no need to be a license), or not (in which case they would have to buy a license).

The "docker build" tool could also be used in a pipeline to auto-build such images though. Which opens up 2 more scenarios:

1) those images are only used internally, in which case I'm not sure whether "docker build" would be used as end-user application, or as a sort of library. If the former, how would I sell a license? Just to one developer that sets up the pipeline, or a company-wide (most likely more expensive) one? Probably the latter, I guess.

2) the pipeline-framework itself is distributed or sold as a product

The whole picture changes again if I choose Prosperity instead of Parity.

As I said, I'm not sure how I'd deal with all that, need to let it marinate for a bit. Maybe it's best to keep it like it is right now and assume that the current license catches a meaningful majority of cases and accept that if one has special requirements one needs to deal with it independently.

Or, and this is probably way out there, a license could have 'plugins', a bit like Creative Commons. Just an idea, and it would probably have terrible consequences, but it'd be dead cool to have a license that has an API and a plugin-system I reckon! :-)

[makkus]

Another quick though, I think you mentioned you did similar yourself in another thread and you give one or two examples in your guide:

Would it make sense to setup a document that lists existing applications (like my "docker build" example here), assume they would be Parity or Prosperity licensed, and either speculate yourself, or give other people the chance to comment on what they think that would mean practically? And what the private license would in turn allow the user to do?

Might help giving people a better sense of what different licenses could mean in certain situations, and also give you a sense of how people read your licenses. Might also be counter-productive if people would take that as legal advice though. Anyway, just a thought.

[kemitchell]

@makkus, excellent comments as usual. You may feel out of your depth, but the incisiveness of your questions says otherwise!

Company Licensing

If the former, how would I sell a license? Just to one developer that sets up the pipeline, or a company-wide (most likely more expensive) one? Probably the latter, I guess.

@substack brought up just this point, a while back. My answer then, when the public license choice of L0-R, was that I'd read that license so that every developer needs a license, as they would for Sublime Text or IntelliJ.

Parity, which replaced L0-R, makes that even more clear:

2. If you run or combine this software with other software in
   any larger program, release all source code for that program.

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

Let's say I write a code formatting tool and license it under Parity. If one developer on a company's proprietary software development team uses my tool to format his company's codebase, they need a private license for closed, proprietary work. If that developer instead configures the project to run the tool for every commit, by any team member, then every team member making commits needs a private license.

licensezero.com takes roughly the same approach as Sublime. Developers can buy single licenses, for themselves, self-serve. Any site-license or other multi-user deal, say for a company, requires reaching out to the developer. One of the reasons: License Zero wants to find the path of least friction. If individual developers can use credit cards to buy their licenses, and submit those purchases as expenses, that imposes minimum friction on the licensing developer. If licensezero.com focused on site licenses to companies instead, licensing developers would often get stuck dealing with company procurement departments. Having insiders at a company deal with a routine expense reimbursement process is much better than having outside developers deal with bigger-dollar company procurement processes.

The licenses page on licensezero.com includes a section with form quotes for selling through company procurement groups, rather than online, via licensezero.com, when for some reason that makes more sense. It's on my list to publish a form site-license contract between a developer and company, which requires the developer to generate 365-day waivers with licensezero waiver in the names of specific developers covered by the site license.

But it's not 100% clear how to build that approach on top of licensezero.com quite yet. It might end up being a web app that lets the company request a waiver automatically, and keeps track of how many they're entitled to at one time.

Distribution

I couldn't help noticing the word "distribute" a few times in your post. Thinking about distribution first is the right instinct with copyleft licenses ... until Parity showed up!

Unlike GPL and AGPL, Parity's obligations to share source don't trigger on "distribution". Rather, once Parity requires release of source code, Parity tells users they have to distribute!

To release source code, publish the preferred form for making
changes through a freely accessible distribution system widely
used for similar source code...

A Parity user's obligation to share source code kicks in when they make the changes, build on Parity code, or use Parity tools to write software, not later on, if they happen to "distribute" that work or offer it as a network service.

I've seen a video of Linus Torvals saying:

My argument for liking [GPL] version two, and I still think version two is a great license, was that I give you source code, you give me your changes back, we’re even.

…

You don’t have to use Linux. If you do use Linux, the only thing I ask for is source code back. And then there’s all the other verbiage in the GPL version 2.0 about exact details, and those aren’t important. And that was always my standpoint.

As it turns out, the details do matter. GPLv2 only requires source code if you "distribute", and even in those situations, source code goes to users, not back to the original developers, like Linus. The fact that sometimes changes to Linux get back to Linus is a side effect of GPLv2. GPLv2 was written to make sure users, not developers, get source code for the programs they use.

Parity is a bit closer to what Linus seemed to want. Parity requires source code with or without "distribution": the "details" that don't matter to Linus don't appear in Parity.

As far as where that source code has to go, Parity is halfway there. Parity doesn't require sending source code back to the original developer, but instead requires publishing it in a way that makes it practically possible for the developer to find.

[kemitchell]

Would it make sense to setup a document that lists existing applications (like my "docker build" example here), assume they would be Parity or Prosperity licensed, and either speculate yourself, or give other people the chance to comment on what they think that would mean practically? And what the private license would in turn allow the user to do?

I call this list my "test suite". It is absolutely on my to-do list to consider publishing it.

I worry a little about offering too many examples. In the end, I've put more work into making the rules in the licenses as clear as possible, so that people don't have to take anyone's word for how they work, and apply them on their own. I'd hate to see people read through 50 worked examples, pick the one that seems closest to their own situation, with the result they like, follow it without reading the license, and run into surprises.

That's paternalistic, and I don't like it. I think the answer here is that I publish my "test suite", as worked examples, but emphasize at the top that it's no substitute for reading the licenses and working through. More information, not less.

[kemitchell]

@makkus, I've started pulling some of my "test suite" together in https://github.com/licensezero/licensezero-examples-and-explanations.

[makkus]

Thanks @kemitchell , that all makes sense. I haven't digested all of it just yet, so might add some more comments and/or questions later. For now, there is one thing I'm not quite sure about:

As far as where that source code has to go, Parity is halfway there. Parity doesn't require sending source code back to the original developer, but instead requires publishing it in a way that makes it practically possible for the developer to find.

I'm wondering: if I publish a tool using Parity, somebody else uses it and publishes their changes, also using Parity, what would be the implications? I guess I could still sell licenses for my code, but end-users would need to buy licenses from the both of us, correct? And if I would incorporate those changes and use the resulting code (which would mainly be my own project) as a sort of end-user in the tool sense, not library sense, I would have to get a license from the other developer if I wanted to use it for non-free private projects? What would happen if somebody would license their additions as AGPL instead for example? There might be situations where the combined code might be of no use to somebody who would otherwise purchase a license, as they might not want to run any AGPL code on their infrastructure, and can't purchase a license for the code in question?

I can't quite put my finger on it yet, but I feel the distinction between library and tool is still important. Even though both those use-cases trigger the share-alike requirements (and I think that is a good idea), it might still make sense to treat them differently when thinking about private licenses. I'll need to think more about it and come up with a more coherent argument and better examples...

[kemitchell]

@makkus, we're way off the topic of this issue now, but what you're describing the guide calls "stacked licensing".

Your basic assessment is correct: Users of a combined work would need private licenses from both developers for closed, proprietary work. The issue of whether to incorporate another person's changes, when you don't have control of their pricing, led to availability locks.

[makkus]

Oh, cool, thanks. Haven't read that one yet.

[kemitchell]

I'm going to go ahead and close, since I think this issue might be confusing for folks just coming in.

The upshot here was really #2, which clarifies some of the terms in the Sublicensing section.

I'm also going to update the README shortly, with an introduction and suggested approach for those new to L0, who want to read up quickly.