Should License Zero private licenses allow redistribution and sublicensing of customers?

[kemitchell]

At present, if you privately license a License Zero library for use in your web app, the private license allows you to use the software to serve as many users as you'd like. If you put that library in a proprietary client-side web app, however, you need to buy private licenses for each of your customers, or instruct them to buy themselves.

Allowing the redistribution and sublicensing for incorporation proprietary software would better model the idea of paying to turn a License Zero into permissive source for purposes of the paying licensee's business. It would cede potential for a lot of additional revenue, and lead to situations where consumption becomes radically decoupled from support.

[makkus]

Not sure whether I should respond here, as this is already closed, or open a new issue, hope this is ok.

For my project I'd like to disable sub-licensing in the private license.

I think people will want to have different options in regards to license terms, depending on the type of product they want to sell. For a library, sub-licensing is obviously a must. For an application, what you have currently ('...significant additional content or functionality...) is probably a good fit for a lot of cases, as it basically restricts sublicensing mostly. I think my project sits somewhere in the middle.

Overall I don't think it'll be really easy to tell whether there has been 'significant additional functionality' added or not (in my case, anyway). And I'd like to have the option to charge differently when it is used as a library and integrated into another product, or whether it is used as an end-user tool and it is licensed to a single person.

I see the appeal of having only a single private license available though. Cuts out a huge chunk of overhead, for both you developing the client, and for users purchasing from licensezero and not having to check every single license they purchase.

For the latter, maybe it'd be possible to have a key describing the terms of the license, like:

terms:
  sub_licensing: false
  <maybe_even_something_else_like_no_of_seats??>: 40

For the sub_licensing case, all dependencies needed to be true to be able to sell your proprietary product, so the licensezero cli could fairly easily print out a summary or somesuch.

As I said, I can totally see how you wouldn't want to open that can of worms, but I figured it might not hurt to try to explain my requirements (as I see them at the moment -- that might very well change. For example, I've come to appreciate your decision to sell a version of a product as is, and with a perpetual license, instead of a subscription, with the option to just create a whole new product for the next version. That really cuts away a lot of otherwise difficult to handle edge-cases, and is fairer to the customer too).