[RFC] Decisions about Licensing

[Giovanni]

Hello,

I hope to trigger a discussion about the licensing model, I need to understand if the current model is adequate or could be improved somehow.

So far our policy has been: free code == commercial code, this means that we have to put some licensing restrictions on the free code. This is why we have our current model of registration in order to get a free commercial license. The idea is to offer a free solution with the same quality of the commercial one.

The previous model of GPL+exception while having the same code of commercial version, sadly, killed sales. Seeing possible sales vanish because GPL+exception was "the same" or "sufficient" has been really hard, it was not sustainable

The alternative I can think of is to have a free product and a commercial product, maintained separately. The free one would be under a permissive license (free as in free beer) the commercial product would be commercial-only and substantially different, commercial codebase would not be public. BTW, this is what others do. Under this scenario the public product would be a subset of the commercial one and not necessarily the latest or most optimized version.

Any other sensible solutions?

Giovanni

[utzig]

BTW, this is what others do.

What others (beyond FreeRTOS)?
What would be the differences, specifically what would be missing in free version?
And what about optional paid support/consulting?

Fabio Utzig

[Giovanni]

Thanks for commenting.

What would be the differences, specifically what would be missing in free version?

This hypothetical free version could, for example, be a derivative of RT 2.6 able to use the latest HAL/OSAL. But do we need to fight the battle of free as in free beer?

Hobbyists have no problem with GPL, same for other FOSS projects, universities and education in general can also work with the GPL version. Small companies are served by the free license, big ones should buy if they see the value in it.

Let's assume this free version is created (GPL+exception as before). Who would benefit from it? the answer is:
1) Small companies that want to use it without associate their products with the ChibiOS brand (required by the free license).
2) Large companies that just want it for free.

Both not exactly high in my priorities. Am I missing other potential users here?

And what about optional paid support/consulting?

Paid support and training does work but it is not compatible with my busy schedule, usually I ask others to do that when there is demand.

Giovanni

[utzig]

This hypothetical free version could, for example, be a derivative of RT 2.6 able to use the latest HAL/OSAL. But do we need to fight the battle of free as in free beer?

Hobbyists have no problem with GPL, same for other FOSS projects, universities and education in general can also work with the GPL version. Small companies are served by the free license, big ones should buy if they see the value in it.

Let's assume this free version is created (GPL+exception as before). Who would benefit from it? the answer is:
1) Small companies that want to use it without associate their products with the ChibiOS brand (required by the free license).
2) Large companies that just want it for free.

Both not exactly high in my priorities. Am I missing other potential users here?

I like free beer. If you are paying for it I will gladly drink it! My current situation is that I pretty much left the embedded systems market (I do python/go programming these days...) so this doesn't really affect me. The things I use ChibiOS for right now are thing which I'm interested in and not commercial. But I started using ChibiOS because I consulted for companies which where using STM32 hardware and the licensing looked good enough for me to try it so I ended up creating some commercial products that ran (and still do) ChibiOS. Relicensing it as GPL most probably removes it of the equation for me if I ever get back to creating a commercial product.

Also I don't think you can relicense past versions so 3.x that were already released have to remain with the current license and people would still be able to use current versions like they are using today (not encumbered by GPL). And maybe even fork the current version before it turns into plain GPL (depends on the exception text). Well, I'm not a lawyer so take it with a grain of salt..

Paid support and training does work but it is not compatible with my busy schedule, usually I ask others to do that when there is demand.

NuttX is an example of RTOS that works quite well with a permissive license and based on consulting work. There are always alternatives for solving the problems of you having a busy schedule.

[skute]

The way I'm understanding the problem is not with the license itself, but rather enforcing it. If you want to earn a reasonable profit for you work, then you are forced to limit what is available for free. However, the point of FOSS, is that it's not meant to earn a reasonable profit.

It seems you're stuck either letting everyone have everything for free or going to the new model you've proposed (which allows you to enforce licensing) at the expense of limiting the free version for students/hobbyists/etc. A different option that might work would be to use a sliding scale or donation based profit system where users can pay what they feel comfortable paying. This has worked for other types of medium (https://louisck.net/news/a-statement-from-louis-c-k) and perhaps it would work for you?

Whatever you decide, at the end of the day it's your software and I'm sure everyone thanks you for what you've given thus far.

[steved]

The alternative I can think of is to have a free product and a commercial product, maintained separately. The free one would be under a permissive license (free as in free beer) the commercial product would be commercial-only and substantially different, commercial codebase would not be public. BTW, this is what others do. Under this scenario the public product would be a subset of the commercial one and not necessarily the latest or most optimized version.

Paradoxically, I can see that this approach could even lose you sales! I imagine most people looking for an RTOS would shortlist a few, then download the most easily available version of each. This would most likely be the "free" version. Thus the "benefits" of the commercial version, whether it be "better" code or additional features, wouldn't be available for evaluation, yet could be the deciding factor in whether to choose Chibi over some other RTOS.
Also, I can imagine that many potential licensees start by downloading whatever is free to develop their potential product, and only look for a licence when the product is about to hit the market. So they wouldn't use the extra features, at least not initially.
Unless the Chibi commercial licensing has changed recently, it seems a bit complex to me, with chunks of money for various parts, or a "global" option which looks as if it will always be the best deal.
You could also look at what the uGfx people have done - they require a paid licence for any commercial use, but have a range of options starting at a licence for 10 units and going up to unlimited. This approach probably encourages the "little people", who might otherwise keep a low profile and use the software anyway, to pay something. (Only having paid options involving what, to many, are large sums of money can be counter-productive; people will often happily pay an amount which they think is a fair reflection of the value they derive from something, as long as you make it easy for them to do so).

As a final thought, maintaining two codebases, even with a substantial overlap, would inevitably be more work. The free version would really need any bug fixes to be implemented at the same time as in the paid for version, otherwise the results from evaluation copies could suffer.

[Giovanni]

Also I don't think you can relicense past versions so 3.x that were already released have to remain with the current license and people would still be able to use current versions like they are using today (not encumbered by GPL). And maybe even fork the current version before it turns into plain GPL (depends on the exception text). Well, I'm not a lawyer so take it with a grain of salt..

You misunderstood something I think, the point I am trying to discuss is not about changing the current licensing model but about the introduction of a -new- free (as in free beer) version, limited in functionalities compared to GPL, commercial free and commercial full versions, which would stay just like now.

You are right about the licensing, 2.6.x is still available as GPL+exception and I couldn't change it, I wouldn't anyway.

The way I'm understanding the problem is not with the license itself, but rather enforcing it. If you want to earn a reasonable profit for you work, then you are forced to limit what is available for free. However, the point of FOSS, is that it's not meant to earn a reasonable profit.

I have no problems enforcing the commercial license simply because I don't, for example that limit of 500, there is no reliable way to enforce it, it would also be pointless because you can extend it by 500 indefinitely by simply asking, it is a way for us to measure ChibiOS deployment. The only case that could trigger an action is a violation of GPL.

About FOSS, development requires time and effort, without profit or sponsors projects cannot survive unless you handle them like an hobby.

Giovanni

[Giovanni]

You could also look at what the uGfx people have done - they require a paid licence for any commercial use, but have a range of options starting at a licence for 10 units and going up to unlimited.

We did this in the past, we had solutions for 100 licenses. Nobody asked for those so we removed them. Just a person asked for one of those but after we removed them, I wanted to grant them a license for free but they ended up making a donation instead.

Maybe it could make more sense if it is implemented as an automatic service, you compile an online form and receive a digitally signed document with the license automatically. A tool would allow to "process" the GPL code and replace licenses... not a bad idea actually.

Giovanni

[steved]

We did this in the past, we had solutions for 100 licenses. Nobody asked for those so we removed them. Just a person asked for one of those but after we removed them, I wanted to grant them a license for free but they ended up making a donation instead.
Giovanni

That could have been a very beneficial deletion - IIRC I saw that option when deciding what RTOS to use, and thought it would be an affordable way of testing the water....

[igor]

Hi Giovanni,

Hello,

I hope to trigger a discussion about the licensing model, I need to understand if the current model is adequate or could be improved somehow.

So far our policy has been: free code == commercial code, this means that we have to put some licensing restrictions on the free code. This is why we have our current model of registration in order to get a free commercial license. The idea is to offer a free solution with the same quality of the commercial one.

The previous model of GPL+exception while having the same code of commercial version, sadly, killed sales. Seeing possible sales vanish because GPL+exception was "the same" or "sufficient" has been really hard, it was not sustainable

The alternative I can think of is to have a free product and a commercial product, maintained separately. The free one would be under a permissive license (free as in free beer) the commercial product would be commercial-only and substantially different, commercial codebase would not be public. BTW, this is what others do. Under this scenario the public product would be a subset of the commercial one and not necessarily the latest or most optimized version.

Any other sensible solutions?

Giovanni

Thanks a lot for bringing this up. I rally do like your SW but I have hard time to understand part of your licensing decision.
Maybe it's because it's not so clear to me what is your business model - and what your competitors might be.

In my experience, people who do want to make money with FOSS follow any (combination) of the following patterns:

- grant use for non commercial purposes (if I do not make money out of it, so do you, but you get the advertisement and my undying gratitude), charge - with separate license for commercial use - this of course has issues with the ownership of the code - more on this later
- sell licenses either proportional to the number of installations (royalty) or in royalty-free mode, where the customer pays upfront a lump sum
- however, what most of the revenue really comes from is from support, consultancy, development of ad-hoc features

It's really the last bullet to generate significant revenue, because it provides to customers the tailored services they most likely need, plus the support over the life-cycle of the product, which makes the difference between best-effort and commercially-grade solutions.
IMHO the royalty driven model will die very soon, if it's not already dead. More and more companies selling silicon and HW in general are making available for free RTOS for their HW, so you have competitions at your door.
The real difference lies in how easily is it to find someone who can work efficiently with a certain sw solution.

Splitting the code base will have various detrimental effects:

- more burden for you to maintain both
- less incentives for others to use it (why should I choose some castrated OS?) and contribute back
- less visibility/advertisement, because of the previous point

At most, what does seem to work, is that a certain fix/feature sponsored by a paying customer, doesn't become immediately public.
For example 2-3 months or until a product is launched, so that the customer can have a perceived competitive edge over their competitors.
This is very different from a separate code base, it's just an overlay of patches that is continuously updated and stuff eventually does end up in the free codebase.
Anything else will be perceived by non commercial users as sub-par and they will choose alternatives (your free user of today could be your customer of tomorrow).
For example, what if you intentionally keep the code unoptimized, but I submit a free patch that provides the same optimization?
You are putting yourself in the not so nice situation of having to choose between giving up an advantage of the closed version or not integrating my competing patch.

Finally wrt contributions:

- requiring contributors to give up their rights might solve the situation for you, but it doesn't look so nice. Is it really the only way?
- discarding any history of who contributed what is even worse and frankly, unacceptable by any modern standard of sw development.
I was - really badly - surprised when I submitted a small enhancement to the Makefile and utzig told me that my commit message would be discarded.
- will you move to something saner than sourceforge? The world is using github - I do not want to endorse the specific service provider, but the tool is definitely *the* standard. Incidentally it also supports proper history and commit mesages by others than the repo maintainer.

The great thing about true FOSS is that it ruthlessly kills its competitors, over time.
If you look at those companies that are successful in the FOSS market, they mostly sell services connected to their SW.
The FOSS is a business card for your tailored consulting business. It is *not* the money making machine, it's the vehicle for your company to be known and to establish new business relationships.

I read your comment about potential users and I'm afraid you'll find out that the market is going to change rapidly.
With the IoT/Drone craze, large HW companies have smelled the business and are pouring lots of energy and resources.
RTOSes are bound to becoming a commodity: these companies want to sell their HW.