Proposed "LibGodot" Lets You Embed Godot Game Engine Into Other Apps

[uid313]

its a little more complex than this PostgreSQl gets it license in 1994. In 1994 it was still normal for projects using the MIT license to customize. PostgreSQL license was for the time it was done in 1994 the most common way todo MIT licensing.

https://fedoraproject.org/wiki/Licensing:MIT

Yes this fedora page details the MIT licensing rabbit hole of hell of MIT variant. Like it or not PostgreSQL License is not a vanity license but from a time when MIT license was not a correctly established license resulting in people doing multi ways to attempt to license something MIT making a huge ass mess.

MIT license legal defacto legal disclaimer was only designed to protect MIT and no body else this is also why you still see modern variants of MIT appearing.

uid313 MIT is not a correctly established license and that is why we keep on seeing more and more variants of MIT license. No one is making a MIT license with a correctly design universal protect main project from legal attack so leading to variant after variant with a per project version of this.

I will give you something are vanity license. Postgresql license is just not a vanity license but a side effect of the MIT license collective not having a good universal license for everyone to use. Variant licenses like what we have with MIT is their own unique form of headache independent to vanity licenses. Variant licenses in the MIT case is a sign of big problem with the MIT license eco system itself not each project doing their own version of MIT license doing it out of vanity but instead out of legal need because core MIT license does not cover their asses.

Yes the Redhat employee who got the job at one point to audit the licenses of fedora and rhel was one of the first to document what the problem was with MIT license also documented with a few other licenses that they are Variant nightmares because the core license was not designed as universally used and everyone just fixed the license to deal with their personal problem.

Yes when you see something licensed MIT the question really is what in Variant is this and do remember new Variants of MIT license appear every year quite commonly without a unique branding. At least the MIT variants that put their brand on them like the PostgreSQL one make it clear what MIT variant you are dealing with.

Some areas of licensing are just a complete mess and MIT licensing is one of those areas.
.

When you create a new MIT License on GitHub or look up the one on Wikipedia that is from SPDX it is a nice version that is applicable to all, and everyone can use the same unmodified license and it has no mention of MIT or any particular author or software instead it uses the terms such as "the software" and "the authors".

[ssokolow]

When you create a new MIT License on GitHub or look up the one on Wikipedia that is from SPDX it is a nice version that is applicable to all, and everyone can use the same unmodified license and it has no mention of MIT or any particular author or software instead it uses the terms such as "the software" and "the authors".

For the record, that's the variant of the MIT license also commonly referred to as the "Expat license" because it was originated when the Expat XML parser adapted it.

[oiaohm]

When you create a new MIT License on GitHub or look up the one on Wikipedia that is from SPDX it is a nice version that is applicable to all, and everyone can use the same unmodified license and it has no mention of MIT or any particular author or software instead it uses the terms such as "the software" and "the authors".

https://en.wikipedia.org/wiki/Software_Package_Data_Exchange

https://spdx.org/licenses/MIT.html

SPDX only comes into existence in 2011.

That the OSI variant not the SPDX version yes wikipedia gets this wrong. version https://opensource.org/license/mit

Yes the OSI/Open Source Initiative only comes into existance in 1998 and the OSI variant of MIT only comes into existence in 1999. Posgresql is licensing in 1994. Yes OSI is out comes out of the redhat/fedora license audit mess.

Postgresql license is not vanity license because at time Postgresql project set it license there was no decent common standard MIT license. Postgresql would be a legacy license that license the correct way for the time it was done and the project just has not undertaken the cost to re-license. Yes there is cost having to contact authors and have legal staff watch over the process making sure all the correct i are dotted and t are crossed.

Notice how you said when you create a new MIT license on Github it gives you the SPDX/ISO variant of MIT.

Does Github run anything like tool reuse/.fossology to make sure that when you claim your project is SPDX license MIT is in fact SPDX license MIT as in that you as author have not modified the provided MIT license? The horrible answer is Github does not run License audit tool to make sure SPDX claim and source code stated license do in fact match.

uid313 the fact github does not audit license is why you cannot trust that something tagged as being some SPDX license on github is that in fact license.

With licensing to have trust there need to verification. There are new MIT variant appearing all the time and we really do need places like github and gitlab to add tools to their solution that audit licenses and crack down on incorrect SPDX claims.

I do suspect most of the new MIT variant is developer incompetence caused from what I have seen because they are modifying parts of the SPDX/ISO template of MIT that you are not meant to be altering. Yes could be a grammar checker tool or something else they are using that results in making something with a slightly different legal meaning.

Developers being incompetent at licensing that project that should be no surprise really majority of them are not contract/license lawyers.

Old license like Postgresql are legacy licenses. Unless your item is dealing with legacy license project you should not use a legacy license. But at the time projects started doing these legacy license this was not out of vanity but this how license of that time frame was done.

Projects that licensed before 1998 are basically legacy there was no party before OSI defining what were established licenses. Also in 1998 FSF and others were also making their own lists of what were so called established licenses yes thee different license in fact contained different MIT variants. The SPDX license database of 2011 takes these different lists of licenses and picks out the best ones.

OSI and related come out of the Fedora/Redhat license audit and the found mess this is 1997 event.

SPDX comes out of the Linux kernel license audit of 2010.

Between OSI/FSF and others license lists starting in 1998 there are 9 different MIT variants you could be using and be on those lists. Yes from 1998 to 2011 you could be using 9 different versions of MIT and not be a vanity license because 9 variants of MIT were declared established licenses.

uid313 this licensing stuff is just a pure mess.

Next thing I see is party like github getting sued for fraud because the SPDX license tag on project is wrong and it provable that the project by tools is not that license and party like github should have prevented the fraud being argued in court so finally leading to us having clean licensing with parties like github auditing license on projects so developers cannot stuff it up. So 3 different events required to get to clean licensing and we have only had 2 of the 4 events so far.
1) Redhat/Fedora 1997 license audit start parties creating lists defining what are established licenses.
2) Linux kernel license audit 2010 starting SPDX to make 1 list out of all the established license lists to make established license not a fragmented mess
3) Some legal event to make validating of license claims required this is either like a party like github getting sued for fraud over SPDX tags or some government deciding to regulate that this has to be done so making github and so on do auditing of project licenses.
4) Some form of mop up legal/regulation event to catch and clean up the parties not caught by number 3.

So on clean license we are currently close but no cigar. Yes today's rose color glasses is really simple to think define of what is established license has existed longer than what you think in the software world. The term established license referring to preexisting licenses only appears with OSI. Vanity license term appears after that.

Look at project licensing is a dive into history to correctly say if something is a vanity license or not. Established license being using in Vanity license define is hidden warning that items license before 1998 cannot have vanity license applied in most cases because licensing back then was wild wild west like the movie world historically showed with no sold rules. Yes postgresql happens to a pre 1998 example.

Yes it important we be aware that licensing is still mess it just way less of a mess than it use to be but we have not got licensing nice and clean yet.

[uid313]

https://en.wikipedia.org/wiki/Software_Package_Data_Exchange

https://spdx.org/licenses/MIT.html

SPDX only comes into existence in 2011.

That the OSI variant not the SPDX version yes wikipedia gets this wrong. version https://opensource.org/license/mit

Yes the OSI/Open Source Initiative only comes into existance in 1998 and the OSI variant of MIT only comes into existence in 1999. Posgresql is licensing in 1994. Yes OSI is out comes out of the redhat/fedora license audit mess.

Postgresql license is not vanity license because at time Postgresql project set it license there was no decent common standard MIT license. Postgresql would be a legacy license that license the correct way for the time it was done and the project just has not undertaken the cost to re-license. Yes there is cost having to contact authors and have legal staff watch over the process making sure all the correct i are dotted and t are crossed.

Notice how you said when you create a new MIT license on Github it gives you the SPDX/ISO variant of MIT.

Does Github run anything like tool reuse/.fossology to make sure that when you claim your project is SPDX license MIT is in fact SPDX license MIT as in that you as author have not modified the provided MIT license? The horrible answer is Github does not run License audit tool to make sure SPDX claim and source code stated license do in fact match.

uid313 the fact github does not audit license is why you cannot trust that something tagged as being some SPDX license on github is that in fact license.

With licensing to have trust there need to verification. There are new MIT variant appearing all the time and we really do need places like github and gitlab to add tools to their solution that audit licenses and crack down on incorrect SPDX claims.

I do suspect most of the new MIT variant is developer incompetence caused from what I have seen because they are modifying parts of the SPDX/ISO template of MIT that you are not meant to be altering. Yes could be a grammar checker tool or something else they are using that results in making something with a slightly different legal meaning.

Developers being incompetent at licensing that project that should be no surprise really majority of them are not contract/license lawyers.

Old license like Postgresql are legacy licenses. Unless your item is dealing with legacy license project you should not use a legacy license. But at the time projects started doing these legacy license this was not out of vanity but this how license of that time frame was done.

Projects that licensed before 1998 are basically legacy there was no party before OSI defining what were established licenses. Also in 1998 FSF and others were also making their own lists of what were so called established licenses yes thee different license in fact contained different MIT variants. The SPDX license database of 2011 takes these different lists of licenses and picks out the best ones.

OSI and related come out of the Fedora/Redhat license audit and the found mess this is 1997 event.

SPDX comes out of the Linux kernel license audit of 2010.

Between OSI/FSF and others license lists starting in 1998 there are 9 different MIT variants you could be using and be on those lists. Yes from 1998 to 2011 you could be using 9 different versions of MIT and not be a vanity license because 9 variants of MIT were declared established licenses.

uid313 this licensing stuff is just a pure mess.

Next thing I see is party like github getting sued for fraud because the SPDX license tag on project is wrong and it provable that the project by tools is not that license and party like github should have prevented the fraud being argued in court so finally leading to us having clean licensing with parties like github auditing license on projects so developers cannot stuff it up. So 3 different events required to get to clean licensing and we have only had 2 of the 4 events so far.
1) Redhat/Fedora 1997 license audit start parties creating lists defining what are established licenses.
2) Linux kernel license audit 2010 starting SPDX to make 1 list out of all the established license lists to make established license not a fragmented mess
3) Some legal event to make validating of license claims required this is either like a party like github getting sued for fraud over SPDX tags or some government deciding to regulate that this has to be done so making github and so on do auditing of project licenses.
4) Some form of mop up legal/regulation event to catch and clean up the parties not caught by number 3.

So on clean license we are currently close but no cigar. Yes today's rose color glasses is really simple to think define of what is established license has existed longer than what you think in the software world. The term established license referring to preexisting licenses only appears with OSI. Vanity license term appears after that.

Look at project licensing is a dive into history to correctly say if something is a vanity license or not. Established license being using in Vanity license define is hidden warning that items license before 1998 cannot have vanity license applied in most cases because licensing back then was wild wild west like the movie world historically showed with no sold rules. Yes postgresql happens to a pre 1998 example.

Yes it important we be aware that licensing is still mess it just way less of a mess than it use to be but we have not got licensing nice and clean yet.

Okay so I agree that the PostgeSQL License is a "legacy license" not a "vanity license", still I wish that Python, PHP, Ruby and PostgreSQL moved from their licenses, whether vanity licenses or legacy licenses into a common license such as the new modern MIT License that comes from the Expat License. The new MIT License as the one in OSI and SPDX.

[oiaohm]

For the record, that's the variant of the MIT license also commonly referred to as the "Expat license" because it was originated when the Expat XML parser adapted it.

I am sorry that not quite right. I refer to it as the as the OSI license and there is a reason. The expat was one the the first get their license from OSI(open source initiative). OSI starts February 1998 the draft version of what comes the OSI MIT license comes into existence before Expat and this draft is what early Expat in fact uses. OSI had not stamped it s the OSI MIT license fully officially at that point but OSI person was the author of the generic cover text in the OSI MIT variant.

Yes this licensing stuff is a pure mess. With parties claiming stuff that under closer inspection is not true. Yes FSF calling it the Expat license is because the FSF license naming convention is naming after the first project to use the license not the party that authored the license when it came to MIT variant licenses.

So the license expat uses if you name by author who wrote/made the variant the license is the OSI MIT license if you name after the first project to use it this license is the Expat license. Nothing like as clear as mud. This is not uncommon for a MIT variant to have 2 names the worst example has 40 different names for the same exact bit of license text.

Yes the following is correct statement:
The OSI MIT license is commonly refereed to as the Expat license due to Expat being the first project to use OSI MIT license and this comes known as the SPDX MIT license.

So this one bit of license text has 3 different names for the exact same thing. Yes the original name is the OSI MIT license. Yes there might be a 4 or 5 name out there for it as well.

[oiaohm]

Okay so I agree that the PostgeSQL License is a "legacy license" not a "vanity license", still I wish that Python, PHP, Ruby and PostgreSQL moved from their licenses, whether vanity licenses or legacy licenses into a common license such as the new modern MIT License that comes from the Expat License. The new MIT License as the one in OSI and SPDX.

Postgresql

https://fedoraproject.org/wiki/Licensing/PostgreSQL_License

While this is clearly just an MIT variant, the PostgreSQL community felt strongly enough about this license that they submitted a template form of the variant that they use for OSI approval and it was granted in February 2010.

This why this is such a mess. Postgresql license was created in 1994. OSI comes into existence in 1998 but postgresql only submit their license to OSI list in 2010. Postgresql license is in the original SPDX list.

Do note the problem here some of the PostgreSQL developers prefer the old license. To change license you have to have all current authors of the project agree to it and one of those authors is the "UNIVERSITY OF CALIFORNIA" who gets their name advertised by sticking to the old license. Legacy license can run into a vanity problem when trying to change to a modern license. Legacy licensed projects also run into trouble where due to pre git source code management not being exactly clear on who authored what so making it hard as well to work out who you have to contact to authorize the license change.

Yes the legacy licenses run into Vanity and poor quality source management tools providing poor quality author information so making it hard to determined who the current authors really are who need to be contacted to approve license change.

Modern vanity licensed projects you can get yourself a nice list of who need to be contacted and what need to be removed if particular parties don't agree to allow the license change to proceed forwards. I am not saying changing a vanity license project to something more standard is going to be pain free but it vastly less painful than the legacy licensed stuff.

I understand you wish that projects using Vanity and Legacy licenses would move to standard licenses. Getting the required agreements to change licenses is not simple. Lot of cases are like what happened with the mono project where when they changed licensed they had to remove blocks of code and re-code because those authors would not agree to the new license. Postgresql is particular bad because it was the University of California who coded Postgresql core code that fairly much all of postgresql is built on top of who is not going to agree. Yes this will be pulling the bottom side block out a janga as first move and praying the compete thing does not fall apart.

Some of these legacy licenses we just have to live with because there is just no practical way to change the license. Postgresql does not have the developers really to redo the core with all the other work Postgresql developers need todo. Re-license a legacy license project like Postgresl to have hope of changing the license inside 5 years you would be needing a team of about 8000 people who complete job 5 days a week 9-5 is to work out who the current authors are and contact them and this is not doing the recoding of parts from parties that don't approve the change. This are calculable of people required from prior re-licenses like the mono re-license.

Yes project re-licensing of big projects like PostgreSQL right expensive undertaking with really no productive progress on usability. This is why it kind of important to get licensing right from the start and I get so annoyed that you can just make new variants of licenses on github and the like and the site does not stop you. This is going to be someone in the future headache when find themself suck with one of these variants and something is added that causing them problems that they now cannot change because the project has grown to the point it no longer cost effective to change..

uid313 I just know the postgresql and expat one well because I had to use both of those in projects and they had to go though legal department for approval and that produced one hell of a history document.

[anda_skoa]

The two I'm aware of off the top of my head are System Settings and Discover, because I do interact with them often enough for the design differences to stick in my mind.

Right, I occasionally do use those.

But their usage time is by far less than that of Konsole, Kmail/Kontact, Kate/KWrite or Dolphin.

If I understood Nate Graham's rationale correctly, it's "If I had to contribute in C++ instead of QML, I probably wouldn't contribute at all".

Using QML does not necessarily imply any specific UI component set.
Even if one were to limit oneself to QtQuick, there would still be QtQuick.Controls 2, which has native styling on various platforms.

But it is easy enough to use QML to build QtWidgets applications, e.g. with Declarative Widgets or a similar approach.

That's what I said. wxWidgets used to be called wxWindows... but, no. It was multiplatform long before the switch. IIRC, they renamed it when Microsoft noticed and politely asked them to.

Ah, sorry, I had interpreted it the other way around.

It was the default and the only solution I could find other than disabling it and re-creating it by programmatically changing the foreground and background colors.

Interesting.
I've used ListView in lots of projects and it never had a default delegate set on the highlight property.

And the declarative approach makes is trivial to react inside the main delegate on whether the current instance is the "current item" or whether its model index indicates that it is a selected entry.

You're talking to someone who doesn't run a single Electron application, and who avoids in-browser applications whenever a native application is available for exactly that reason.

Same

[ssokolow]

Using QML does not necessarily imply any specific UI component set.

That's sort of like saying "Using Assembly Language to get compactness doesn't necessarily imply writing DOS applications."

One of my biggest reasons for preferring PyQt or PySide over QML is that MyPy's strict mode gives must stronger compile-time checks than QML, even if it's still nothing compared to Rust.

Even if one were to limit oneself to QtQuick, there would still be QtQuick.Controls 2, which has native styling on various platforms.

QtQuick.Controls 1 is the one that is a wxWidgets-esque wrapper around native controls. QtQuick.Controls 2 is more un-native to QWidget than QWidget ever was to Mac OS X.

But it is easy enough to use QML to build QtWidgets applications, e.g. with Declarative Widgets or a similar approach.

Even if that repo weren't archived with a big "NOTE: This Project is no longer supported or maintained by KDAB." warning in the README, I don't want to add that complexity to my build dependencies. (I want it to be someone else's responsibility to figure out how to ensure that the C++ build automation is hidden behind Cargo or Poetry/PIP/whatever and Just Works™ regardless of what platform I'm trying to target.)

...and I suspect I'd run up against rough edges. (One of my big reasons for never using QtQuick.Controls is that I always run up against the same problem that originally drove me off GTK+ 2.x, but worse... things that Just Work™ with QWidgets but must be reinvented in other APIs. Last I checked, it doesn't even have a tree view widget.)

Interesting.
I've used ListView in lots of projects and it never had a default delegate set on the highlight property.

It's possible I misinterpreted how the API was intended to be used. All I know is that QWidget Just Worked™ and it called the relevant functionality "highlight" while, with with QtQuick.Controls 2.12, I had to override the default behaviour and reinvent selection highlighting to make it feel less "bad Android port".

[ssokolow]

I am sorry that not quite right. I refer to it as the as the OSI license and there is a reason. The expat was one the the first get their license from OSI(open source initiative). OSI starts February 1998 the draft version of what comes the OSI MIT license comes into existence before Expat and this draft is what early Expat in fact uses. OSI had not stamped it s the OSI MIT license fully officially at that point but OSI person was the author of the generic cover text in the OSI MIT variant.

Yes this licensing stuff is a pure mess. With parties claiming stuff that under closer inspection is not true. Yes FSF calling it the Expat license is because the FSF license naming convention is naming after the first project to use the license not the party that authored the license when it came to MIT variant licenses.

So the license expat uses if you name by author who wrote/made the variant the license is the OSI MIT license if you name after the first project to use it this license is the Expat license. Nothing like as clear as mud. This is not uncommon for a MIT variant to have 2 names the worst example has 40 different names for the same exact bit of license text.

Yes the following is correct statement:
The OSI MIT license is commonly refereed to as the Expat license due to Expat being the first project to use OSI MIT license and this comes known as the SPDX MIT license.

So this one bit of license text has 3 different names for the exact same thing. Yes the original name is the OSI MIT license. Yes there might be a 4 or 5 name out there for it as well.

Ahh. I stand corrected.

[oiaohm]

Ahh. I stand corrected.

The horrible part about this unless you know the MIT licenses well getting a MIT license variant name wrong is the normal. And even if you know the MIT license names well you can still get it wrong. Yes you will find cases of people in different forums and the like having a 3 way argument over what MIT license variant is better between OSI MIT license, Expat MIT license and the SPDX MIT license. You see this and you first post is like any everyone stop they are all the same thing. As I say this licensing is a mess not helped that we have multi named different license text. Another license with a stack of variants with horrible bad naming is the BSD variants and they also have problem of different parties given a single variant multi names.

Lot of ways I care less about vanity licensing. I really hate non named variants of license and lack of enforcement to prevent license variants by mistake . Vanity licensing at least it clear you are dealing they brand the license it has a fixed name. Lot of MIT and BSD variants don't have clear branding on them so you end up with stack of mess with single license having many names..

https://fedoraproject.org/wiki/Licensing:BSD

Like really if all the MIT and BSD license variants were vanity licenses dealing with them would be simpler. Because the vanity name would give each license a single name instead of being thrown in a pile who who knows what.

Lets say OSI when they made their MIT license variant add a simple header "OSI MIT License" at the top of it. You would have never need to be corrected because you would have never made the mistake. Named FSF would have used OSI MIT License instead of Expat license. Yes people would not be calling it the SPDX MIT license either. The simple result of this is the license text would have a single name because it was named.

Some how we have to get people to stop repeating this licensing mistake of altering license and not naming it so the mess stops getting bigger.