Seems to be the latter, fairly typical "its GPL unless you want to pay us for a different license"

https://github.com/mongoose-os-libs/mqtt/blob/master/LICENSE

It seems that it lacks the "or (at your option) any later version" part. Which is quite sad.

And an odd choice, even if your target market is tyrant devices. Why not encourage corporations to pay for the non-free license by restricting the uses of the free version?

Sounds like they are trying to say you can't opt for the GPL if you plan on commercial use.

Not a lawyer, but I don't see how that flies. They could make their own GPL-like license with that clause added in. But using it as-is means it's open for commercial use, subject of course to the GPL terms. https://www.gnu.org/licenses/gpl-faq.html#GPLCommercially

They might argue that packaging a product with their OS and selling it is the equivalent of white labeling it, which might be technically true, considering the user would have no idea what's powering the thing.

It would be the equivalent of writing a GUI plugin for WordPress and trying to sell it as something like Squarespace.

Not that I agree with this possibility of Mongoose OS's approach. I don't at all, and think it would completely negate their "open source" claim, from a semantical standpoint.

I haven't checked what Mongoose does, but it's fairly common for embedded OS's to link the application and kernel together. IOW, using the GPL may force you to give the source code to your customers if they ask for it.

So I'm a little confused on how licensing works in these types of situations. 'GPL may force you to give the source code', which source code? Presumably whatever code lives on the device that uses Mongoose is just one piece of a much larger puzzle. So does this imply you only need to give the code that lives on the device running Mongoose? Or any of your code that interacts with it?

What he's saying is that embedded devices a lot of the time statically link the kernel, libraries, and application all into on bare metal program. A GPL licence on the kernel and libraries would affect the application.

Right. My question is if the code on the bare metal device talks to, say, a cloud server running an API, does the code running the API also fall under the GPL, and therefore need to be released? I assume not, but assumptions can be dangerous.

Oh gotcha. No, your remote code wouldn't need to be released just because your IoT code is GPLed.

In reality nobody knows, it's very a very complex question that has been barely explored in court.

In practice everybody acts under the assumption that the GPL affects all code that is statically linked together, but nothing else. Some people extend the interpretation to dynamic linking, but consensus is that the GPL does not affect code interoperating over other interfaces like web APIs.

That's an odd phrasing for sure.

I assume what they mean is that you can purchase a special license which allows you to use moongoose without GPL (typically for proprietary use), for example, x264 and x265 (well known GPL licensed encoders for h264 and h265) does exactly this.

GPL does not allow static binaries from both GPLed code and commercial code.

A workaround is a plugin mechanism with dynamic loading of .dll or .so libraries. But that won't fly on a microcontroller.

.dll won't help with GPL, only with LGPL (IANAL)

I think you have it backwards, if I am interpreting your very brief statement fully correctly...

If you are building a library and you want it to be open source but also usable by products that are not open source, you can use LGPL. If you are building a proprietary library and you want to keep it proprietary, but link it into a GPL application, I think there is nothing is stopping you from doing that.

You still have an open-source application, it just won't work without the proprietary library.

(This sounds like it should be against the letter of the GPL, but as a thought experiment, pretend someone else wrote the library. Say, Nvidia, and you are Linus. You have no control over how their library gets licensed, and there is no person or body which can stop you from releasing your own code as GPL, even if it may have branches that depend on proprietary code.)

Doing OSS this way is most certainly against the spirit of the GPL, but I think it is within the letter.

You read the previous statement backwards. OP meant: dynamic linking allows you to use LGPL libraries with proprietary applications; to use GPL libraries in your application you have to make your application free even if you are linking dynamically.

Yes, but neither one prevents you from linking proprietary libraries into your OSS application.

> .dll won't help with GPL, only with LGPL (IANAL)

Was pretty much totally ambiguous about what exactly was meant.

Am I wrong?

Commercial code can be GPL.

> Have they placed additional restrictions on the GPL (which I believe you are prohibited from doing)?

At that point, doesn't the trivial defense just become "It's not GPL. It's my own custom license which happens to have all the requirements of the GPL plus $my_awesome_additions"?

There was a mistake on the site and it is now corrected

Cool, thanks for clearing up the confusion (probably mostly just on my part, but thanks.)

By having complex and/or copyleft licensing, it just opens the door wider for the Apache Mynewt OS with its Apache 2.0 license. http://mynewt.apache.org/