Hacker News Reader

Comment by wizwit999 | Hacker News Reader

Well the repeated obfuscation between 'product' and 'code' when someone asked you how an open source project with an Apache License can depend on your project. Realistically, there's no way a project with a fully permissive license like Apache/MIT can use your project.

You say:

> The GPL is a good fit for open source users

As the thread tells you, it's clearly not for the many Apache/MIT licensed Rust projects that cannot use your GPL licensed code.

Again you say:

> With the GPL, we are happy to let open source users use the library for free. Commercial users still will be able to use the library because of the escape hatch of the dual license.

You make this differentiation between commercial and open source users while conveniently ignoring that the most permissively open source projects (Apache/MIT) are practically prevented from using your software.

At least with BSL, projects are honest about what they're doing. Don't play both sides.

View on HN

I stand by what I said Because Apache/MIT is compatible with the GPL, it is totally fine for people who like to license their code in Apache/MIT to do so.

An example of that is KHTML, the web engine: KHTML was licensed under LGPL, despite it was based on Qt in very deep ways (usage of core feature such as QString, QList, all over the place). Qt was GPL at the time. Even then, Apple was able to take KHTML, and remove the Qt dependency, in order to create WebKit which is fully LGPL.

One can totally make a "more permissive" product based on Slint. If someone wants to use the extra permissions that are not granted by the GPL, they still have the option to do so by purchasing a license, or using the free Slint license, or (worst case) porting away from Slint.

From what I understand, if I have a project licensed under the Apache license, I cannot use Slint in the project. I'm no expert about this stuff, but here is what the Apache foundation has:

> Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.

> This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF's requirement that all Apache software must be distributed under the Apache License 2.0.

> We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors to create a derivative work. We want to honor their license. Unless GPLv3 licensors relax this interpretation of their own license regarding linking, our licensing philosophies are fundamentally incompatible. This is an identical issue for both GPLv2 and GPLv3.

https://www.apache.org/licenses/GPL-compatibility

Am I missing something?

I think the distinction that you may be missing is between software generally licensed under the Apache license and software that is part of the Apache project and governed by the Apache Software Foundation. The latter may choose not to include GPLv3 software in their project, but software outside of the ASF umbrella that's licensed under the Apache license can be combined with GPLv3 software.

I think the confusing part to the parent comment is that they don't understand that your GPL license infects their project, but not the code they write for that project (which can be MIT or Apache).

Personally, I'm not a big fan of licenses like GPL and BSL, but you do you. I just won't use your product.

If the project is licensed under the GPL, all the code in it is licensed under the GPL. The author is not precluded from later relicensing the non-GPL portions of the project under a different license - it's their code, they can release it under whatever license they want - but there will always be a version of that code that is under the GPL.

This is true, but if you dual license like this, your code will also carry another more permissive license, like Apache, BSD, or MIT, without an explicit re-licensing at a later date. It (that code only) can then be used under the more permissive license straight from the GPL-marked project. To convert from a GPL-licensed project, the user would only have to replace the GPL-licensed components.

It is impossible to tell, from this post, whether you mean to say that the teeth can be removed from the GPL by simply licensing a dependent work as LGPL, or whether you mean to say that the GPL does not steal ownership from you and you can adapt it later to be non-GPL.

If the former, this is laughably wrong and displays a complete misunderstanding of open source licensure. The GPL infects the entire project, that's its defining factor, and you cannot set the entire work's license as LGPL any more than you can set it as MIT.

If the latter, this is a fake distinction, and displays dishonesty about the risks. Regardless of what license I can distribute my code under later if I change it, in order to use a GPL-covered library I must license the version of my code that depends on it under the GPL. That version of the code will be GPL-licensed to anyone that has it, for eternity; I cannot retract it, regardless of what changes I make to my own copy.

Either way this is not a reassuring post. I am glad to know Slint is GPL so I can stay far away from it and recommend others do the same.

If I was laughably wrong, why are WebKit and Safari not GPL, despite it is based on KHTML which was using Qt 3.x which was GPL. From your argument, Qt's GPL should have "infected" KHTML's code and so WebKit, and by extension Safari. But Safari is not open source, is it?

This post would indicate that you are talking about the latter case, in which case you were not laughably wrong, but rather dishonest about the risks. You are talking as though people have the ability to be Apple, but everyone you're talking about is not in Apple's position, but in KDE's.

Yes, exactly. My point is that the open source project who wants to be a more liberal license can do it, just like KDE did.

Then if someone wants to take that for proprietary software, they can do it too, like Apple. They don't even need to go as far as Apple and make a fork, they can use Slint's paid, or free as in beer (ambassador) license.

Reply on news.ycombinator.com