Possible impending Qt fork and copperspice opportunity

Discuss anything related to product development
marlowa
Posts: 117
Joined: Sun Oct 25 2015 10:52 am

Possible impending Qt fork and copperspice opportunity

Post by marlowa »

Hello Everyone,

I just read the article at https://www.phoronix.com/scan.php?page=news_item&px=More-Interest-Possible-Qt-Fork which speculates on a fork of Qt due to Qt licensing becoming more restrictive in a way that might impede its use in open source projects. See also https://www.phoronix.com/scan.php?page=news_item&px=Qt-Might-Restrict-New-Releases.

This might be an opportunity for Copperspice, which already is a fork of Qt (albeit on version 4 rather than version 5). Instead of forking Qt from scratch again it might be worth people considering Copperspice and how it could be used to dodge these new restrictions. Of course, their is a lot of work to do before any fork would be in a position to be used instead of Qt in a large project such as KDE. Maybe it isn't even possible/feasible. But I just thought I'd mention it, FYI.

This issue has happened with Qt despite a strong history of open source development and using a well-established open source license. I think this shows the importance of open source projects being very up-front as to what license they have with corresponding implications for use or not in proprietary software and how the project is funded. It would be nice, IMO, for Copperspice to have a more prominent page from the home page that says what the license is and explains how the project is funded.
barbara
Posts: 446
Joined: Sat Apr 04 2015 2:32 am
Contact:

Re: Possible impending Qt fork and copperspice opportunity

Post by barbara »

Copperspice, which already is a fork of Qt (albeit on version 4 rather than version 5).
I would like to correct this information and set the record straight. The starting point of a software project has nothing to do with where development is today. CopperSpice was derived from Qt 4 and has moved forward and evolved considerably. Qt 5 was also derived from Qt 4 and it too has moved forward.

Our project was started before Qt 5 was released and there was no need to start over and repeat completed work.

Barbara
barbara
Posts: 446
Joined: Sat Apr 04 2015 2:32 am
Contact:

Re: Possible impending Qt fork and copperspice opportunity

Post by barbara »

We received an email asking about the license for CopperSpice and we would like clear up a few possible misconceptions.

Qt 4 was both GPL 3 and LGPL 2.1 and the CopperSpice team selected LPGL 2.1 for our derivative work. The license for Qt changed starting with the release of Qt 5.7, when they switched to GPL 3 and LGPL 3.

A few people have stated they dislike LGPL 2.1 since it is requires open sourcing any changes to CopperSpice. However, what is often misunderstood is that an application developed using CopperSpice does not need to be released as open source. As someone using the CopperSpice libraries, you are allowed to release your application with almost any license, including LGPL 3 or even proprietary.

By CopperSpice remaining as LGPL 2.1 we offer the most flexibility possible. As developers you are not restricted and can freely adjust the license for your applications. In fact, our own applications DoxyPress and Diamond are both released as GPL 2 however we could have used LGPL 3 for Diamond.

Barbara
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: Possible impending Qt fork and copperspice opportunity

Post by seasoned_geek »

Well,

There are many discussions about forking Qt. I've been involved in some of them and probably the cause of others. Yes, it is due to the licensing and Qt Company's interpretation of the licensing.

Under the last interpretation, if there is one licensed Qt product used in a project, developers writing firmware/device drivers in C/C++ can't use QtCreator unless they purchase the same commercial Qt license as the other seats.

Under the previous wording if you had a commercial Qt license on a project you couldn't use Doxygen, Wireshark, or any of the other development tools developed with OpenSource Qt.

"Windows 7 support will be, dropped in Qt 6"

Honestly I had never heard of CopperSpice until I started looking for an alternative to Qt when the Windows 7 discussion started. Everyone who read that thread now knows of CopperSpice. Actually my previous statement wasn't quite true. A client had asked me about Qt alternatives due to the licensing and I found CopperSpice in a search. I put it on a list to look at "one day."

The forking of Qt4 discussion I had started when someone with a FOSS email address reached out to me at the start of the licensing issue. That was several months prior in the archive and I don't remember the thread subject. That is the conversation you probably came across. A port of Qt prior to the license change and without QML.

For CopperSpice to make good inroads here, where companies don't mind paying reasonable "developer seat" fees that come with some level of support but refuse to pay royalties needs several things:
  • Stable API so that code written today will still compile against the current version in 2051 much like COBOL-78 compiles with today's COBOL compilers.
  • A reasonable developer seat fee.
  • A capable IDE.
  • Many will still need 32-bit support.
In my "spare" time I've started looking at making some enhancements to Diamond to kick the tires on CopperSpice. Adding themes, support for EDT keypad navigation, choosing a default font other than Courier. (Until you've used EDT keypad navigation for a bit you cannot understand how great it is.) (Under KDE Neon the default font was almost illegible on the screen.)

Assuming I'm successful in my "spare" time the editor would then be suitable for a fork to begin CsCreator. Someone could then be "inspired" by Gede to add debugging support.

http://gede.acidron.com/

I'm certain someone could "suggestions" like KDevelop and QtCreator have. Providing completion suggestions as a person types.

While it doesn't work perfectly I do kind of like the "linting as you type" feature QtCreator has gotten recently.

Integrated help/documentation along with jumping between declaration and implementation could then be added.

Yes, I know, that is all way more than 10 minutes of work.

At any rate there are companies looking to jump ship. I still haven't figured out how anyone gets a medical device using QML through the FDA approval process but that may be one of the universes great mysteries that never gets solved.
CandL
Posts: 49
Joined: Mon Oct 14 2019 6:37 pm

Re: Possible impending Qt fork and copperspice opportunity

Post by CandL »

Wow ... let me catch my breath.... Seasoned_geek is on a roll.

First let me say I too am some what of a "curmudgeon" but some of the statements appear a bit extreme. I also know this is a Copperspice forum but Open Source licensing is big factor.... my intent is to always do the "right thing" and not cheat anyone

"Under the previous wording if you had a commercial Qt license on a project you couldn't use Doxygen, Wireshark, or any of the other development tools developed with OpenSource Qt."

First I am not a lawyer, but from all accounts this is a matter of FUD (fear, uncertainty and doubt). Something Qt is quite happy to sow if it increases their purses. But if I read the the Qt and Qt Creator licenses what it says is I cannot MIX the Open Source and Commercial version of Qt libraries.

So if I implement a "Chinese Wall" (Legal term) I could in my company produce both commercial and open source applications ... not easy but doable.

So relating back Copperspice... I believe that I could use the open source /community version of Qt Creator with CMake/Conan/Copperspice to create "signal/slot GUI" application. I am trying to respect each organizations "trademark terms " so the wording gets awkward. But I believe this approach would be completely legal.

Does anyone know of a legal case in ANY country that would imply this is a problem? The Qt company seems very good at sowing FUD, but they seem reluctant to actually push the issue in court. Frankly if they do push the issue, and loose their business model take a big hit.

Sorry for the Open Source fork in the discussion but it is a user issue ( see also the Oracle/Java issues and then RedHat/OpenJDK)
barbara
Posts: 446
Joined: Sat Apr 04 2015 2:32 am
Contact:

Re: Possible impending Qt fork and copperspice opportunity

Post by barbara »

seasoned_geek wrote: Tue Jun 23 2020 9:50 pm Honestly I had never heard of CopperSpice until I started looking for an alternative to Qt when the Windows 7 discussion started.
Sorry you had not heard of CopperSpice and we are very glad you found us! Our first official public presentation was in September 2015 at CppCon. It was announced by someone else on Reddit in July 2015 to a bit of community bewilderment. Ansel and I, as the co-founders of the project, have spoken at countless conferences and local ACCU C++ meetings. We started a YouTube channel in July 2017 and we have over 50 videos. Over the past few years a team has assembled with some members more visible than others.

For CopperSpice to make good inroads here, where companies don't mind paying reasonable "developer seat" fees that come with some level of support but refuse to pay royalties needs several things:
  • Stable API so that code written today will still compile against the current version in 2051 much like COBOL-78 compiles with today's COBOL compilers.
  • A reasonable developer seat fee.
  • A capable IDE.
  • Many will still need 32-bit support.
We firmly believe in the idea of open source software and value what it can provide to developers. One of the reasons we chose the road we did was due to the lack of true open governance we saw in Qt. We value all the work they did and honor their contributions. Ansel and I were asked to contribute to Qt back in 2015 but declined due to their CLA and licensing.

We know some developers want a stable API and others simply do not care. There is no "one answer fits all". Keeping a stable ABI does not seem to be a pronounced issue. Our current users have been telling us they want the awesome parts of Qt and true integration with C++. As one simple example, you can not use C++ algorithms safely with Qt copy on write containers. CopperSpice uses composition, not inheritance and not a roll your own. So the CS QVector is an std::vector and QList is an std::deque. We have retained the Qt API and added the STL API. Best of every world and all the QList problems have gone away.

We have more areas of CS which are under development by various people. We want to make CS less of something unique and more of an extension of C++. The direction of CopperSpice is to be a set of libraries and not a framework.

Our work on strings is being used by the C++ standards committee as a case study for UTF-8 and full Unicode support. Our work on removing moc was used by the committee to ask, why are meta classes so complicated. The CopperSpice libraries are used in the Microsoft conformance test suite to ensure MSVC continues to support all the features of the C++ standard. It was lovely to be recognized by them as a cutting edge product and we learned last year they regularly find things while compiling CopperSpice. Yes, I will confess that one item was our bug.

So the idea of never changing the API is worrisome to me. We want to keep making CS better and sometimes a "bad" API is impossible to support. Right now we are in a full redesign of QVariant and this has resulted in a a few API adjustments. Maybe the real issue is more about random changes that provide nothing, which I agree is silly. Since we document all of our changes and the API docs do not hide things, this should make moving to a new version less work.

CopperSpice currently has a subscription model to support users who require a higher level of support or want to influence our road map. In terms of an IDE there is no reason users of CopperSpice are limited from using QtCreator. Several of our existing clients currently do and it is perfectly legal. In our CS Overview documentation we provide the steps to set up a CS project in QtCreator.

In terms of platform support we have trimmed down OS X allowable versions, but only due to XCode limitations. For Windows we have a minimum required version for MSVC since early versions did not support enough of C++11 when it did support C++17. For Windows MinGW (my environment of choice) I will do my very very best to keep Windows Vista building for 32-bit. Hard to build CS on a 32-bit computer but simple enough to build on a 64-bit computer in 32-bit mode. At this time there is nothing we need to adjust to turn on support for Windows 7. It just works.

We migrate to newer versions of Unix when it seems appropriate. Arch was added by a team member and he supplied us a docker image for our CI system. CentOs 8 was added at the request of multiple CopperSpice users. This was the first version of CentOs which shipped with a new enough compiler.

Hope this helps to give you some of the background.

Barbara
barbara
Posts: 446
Joined: Sat Apr 04 2015 2:32 am
Contact:

Re: Possible impending Qt fork and copperspice opportunity

Post by barbara »

CandL wrote: Wed Jun 24 2020 1:28 pm I believe that I could use the open source /community version of Qt Creator with CMake/Conan/Copperspice to create "signal/slot GUI" application. I am trying to respect each organizations "trademark terms " so the wording gets awkward. But I believe this approach would be completely legal.
CopperSpice, CMake, and Conan are truly open source projects so they play well together. The Open Source/Community version of QtCreator is fine to use with CopperSpice.

However, if you pay for a Qt commercial license you might not be able to use the Open Source/Community version of QtCreator for any reason, it depends on the exact terms of your license. This has nothing to do with CopperSpice and was never intended to be a limitation about us.

I am not suggesting we need to do this, however, if someone wants to port QtCreator to CopperSpice we would need to verify a few things about the licensing of their code.

Barbara
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: Possible impending Qt fork and copperspice opportunity

Post by seasoned_geek »

According to the last heated exchange on qt-interest.

If you have a Qt license, nobody working on the project can use QtCreator unless they have a license. That means your firmware people who are just writing C/C++ code for device drivers and kernel stuff have to have a full-tilt Qt license if they want to use QtCreator if any individual anywhere on the project is using a licensed copy of Qt.

You should easily be able to find that heated exchange on qt-interest.

At least one of my clients is following stuff on this board now due to all of the FUD and rewording going on with Qt licensing. Not to mention their incessant demand for royalties.
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: Possible impending Qt fork and copperspice opportunity

Post by seasoned_geek »

So the idea of never changing the API is worrisome to me. We want to keep making CS better and sometimes a "bad" API is impossible to support. Right now we are in a full redesign of QVariant and this has resulted in a a few API adjustments. Maybe the real issue is more about random changes that provide nothing, which I agree is silly. Since we document all of our changes and the API docs do not hide things, this should make moving to a new version less work.
Things can be added. Nothing deleted. Once a header file is in a given directory tree, it stays there. Once a class/function/whatever is in a given header file, it stays there.

New things can be added, but nothing that would break an existing build.

If you want the medical device and industrial control system worlds to move to CopperSpice, the installed base must be sacred.

Current developers guiding the course of Qt have less than zero concept of "installed base." Whatever Apple shipped 15 minutes ago is all they care about. They will make sweeping API changes without a nanosecond's thought about the installed base. They will take a header file, move it to a different directory tree and bust it up into 10-20 new header files without so much as a casual mention until after it is released.

This is why many have been leaving Qt. Personally I believe they want to drop C++ and QWidgets entirely so they keep making it physically impossible to maintain a product code base.
ansel
Posts: 152
Joined: Fri Apr 10 2015 8:23 am

Re: Possible impending Qt fork and copperspice opportunity

Post by ansel »

seasoned_geek wrote: Thu Jun 25 2020 5:37 pm New things can be added, but nothing that would break an existing build.
This point was mentioned in another thread on the Developers forum under API Stability. We have added a detailed reply in that thread.

Sweeping changes need to be well thought out and implemented with a purpose. But sometimes you find security problems or fundamental design flaws and the choice is to live with bad code, or fix it. Our philosophy with CopperSpice is never to hide the changes we have made, and document them.

As an example, if you look in our QString8 API documentation under "Removed or Unsupported Methods" you will find a detailed table of the methods which were unsafe to use. For every method we show the supported replacement and the rationale. Some of the syntax for the usage of QString needed to be changed, and we document both the prior syntax and the new syntax.

It would never be our way to hide changes. We want CopperSpice to evolve and there will be times this will require removing functionality which is problematic and replacing it with something better.
Ansel Sermersheim
CopperSpice Cofounder
Post Reply