CopperSpice License Question

Discuss anything related to product development
barbara
Posts: 447
Joined: Sat Apr 04 2015 2:32 am
Contact:

CopperSpice License Question

Post by barbara »

Admin Note: This was a post in another topic and we decided it deserved to be a separate discussion.
crispina wrote: Thu Dec 10 2020 9:18 pm
Your comment about either building from source or using pre-built binaries has made me think about the open source usage obligations that are now on the Qt website (https://www.qt.io/download-open-source).

I am assuming that this means you should not use static linking if developing an open source project with Qt. As CS was forked from Qt4, has removed MOC and uses many of its own libraries it is able to provide pre-built binaries for linking and development. I am also assuming that Linux applications developed with CS can also provide pre-built shared library binaries ( .so) downloaded from the CS website with binary builds if the application source code is open source (on github or similar) as required by LGPL.

I have noted that with the release of Qt6 the Qt Company is going to replace qmake with the cmake build system and will be removing MOC. As the Qt LGPL states that any modifications to Qt components must be contributed back to the community does this mean that Qt will be using the CS code to do this?

I am not a licensing expert or lawyer but I have watched your extremely good Youtube video on Copyright Copyleft licensing. I get worried when I see things like “re-linking mechanism” and if it has implications for using CS. Hopefully you get the drift of what I am getting at. Maybe it is something CS users should not worry about given that CS was forked from Qt4 when Qt was under difference management. However, if it is going to be an issue then I will have to look at how to use Gtk for my TikiDiary (talking diary) open source Linux application as the CS libraries are generally not available in Linux package management systems. I have also noted other changes to the Qt license which are published at https://www.qt.io/blog/qt-offering-changes-2020.

I would appreciate your feedback on these licensing obligations and any implications for CS application development.
barbara
Posts: 447
Joined: Sat Apr 04 2015 2:32 am
Contact:

Re: CopperSpice License Question

Post by barbara »

You are correct that CopperSpice was derived from Qt 4.8 and as such is under the LGPL 2.1 license. We will not change this nor move to LGPL 3.

With LGPL 2.1 you may use CopperSpice and distribute your application as GPL, LGPL, or closed source. Since CS is freely available on github the only significant requirement on your end is you must provide access to any changes you make to CopperSpice that were not up streamed. This applies to any Linux, Windows, or OS X application.
I have noted that with the release of Qt6 the Qt Company is going to replace qmake with the cmake build system and will be removing MOC.
Qt 6 is moving in the direction of CMake however both build systems are available. Since the official release came out this month and moc is still present, any notion of removing it did not happen. From what we heard they have no plans to remove moc until possibly after meta classes are added to C++ in 2026 or 2029. Since they have never broken ABI until a major release it is doubtful they will make this change until Qt 7 or Qt 8.
I get worried when I see things like “re-linking mechanism” and if it has implications for using CS.
This is primarily an LGPL 3 issue. Since CopperSpice is LGPL 2.1 the only requirement for re-linking on a closed source application is to link dynamically with our CS libraries.

If your question is, can you redistribute the CS shared libraries with your application, the answer is yes.
crispina
Posts: 22
Joined: Tue Nov 17 2020 2:57 pm

Re: CopperSpice License Question

Post by crispina »

If your question is, can you redistribute the CS shared libraries with your application, the answer is yes.
Thanks for this clarification. The CS libraries are generally not available in Linux repositories. As a developer of small Linux open source projects I would normally provide the source code and a deb package installer with the control file listing the required dependency packages in the repositories. As far I can see, with CS, the best option for me is to provide the source code and a pre-built application binary together with CS library (.so) files to end users (like the diamond binaries). I had been considering moving my project to use Gtk (this would be a huge effort) not for technical reasons as CS is great but purely because of my concern of providing an application binary coupled with CS library (e.g. libCsCore1.7.so) files to end users. Many end users do not want to compile software but just want to install and use it.

I noted from your Youtube Copyright Copyleft video that Qt moved from LGPL v2.1 to LGPLv3 with the release of Qt version 5.7 which I assume was to add extra open source usage obligations. It seems that one of the Qt licensing changes is that long-term-supported (LTS) releases and the offline installer will become available to commercial licensees only.
barbara
Posts: 447
Joined: Sat Apr 04 2015 2:32 am
Contact:

Re: CopperSpice License Question

Post by barbara »

We are aware that packages for CopperSpice have not been generated as of yet. This is definitely on the CS road map. If you are interested in working with us or want to create a pull request please let us know.

I would like to reiterate that since CopperSpice is LGPL 2.1 licensed it is perfectly legal to redistribute the shared libraries.
Qt moved from LGPL v2.1 to LGPLv3 with the release of Qt version 5.7 which I assume was to add extra open source usage obligations. It seems that one of the Qt licensing changes is that long-term-supported (LTS) releases and the offline installer will become available to commercial licensees only.
This is not legal advice however it is a well established fact that the LGPL 3 license is more restrictive. It is often referred to as the "anti-tivoization clause". It was not the desire of the CopperSpice project to pursue this path. Instead we strongly believe the true essence of open source software is to be as "open" as possible so we will remain with the LGPL 2.1 license.

The nice part is that CS can be released as LGPL 2.1 and yet developers can choose to create a open or closed source application.
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: CopperSpice License Question

Post by seasoned_geek »

What about BSD?

Gede released under BSD. If at some point I want to merge Diamond and Gede into something of an IDE I'm not allowed to change from BSD license.

The real problem with OpenSource is all of the projects seem to spin a roulette wheel in isolation when choosing a license. Makes for a large nightmare.
ansel
Posts: 152
Joined: Fri Apr 10 2015 8:23 am

Re: CopperSpice License Question

Post by ansel »

seasoned_geek wrote: Thu Dec 17 2020 5:54 pm What about BSD?

Gede released under BSD. If at some point I want to merge Diamond and Gede into something of an IDE I'm not allowed to change from BSD license.
Open source licenses are certainly a bit tricky. If Project A is GPL and Project B is BSD, you can certainly combine them. However, the overall project must be distributed under the terms of the GPL.

As a side issue, Diamond is a CopperSpice project and since it is not designed to be an IDE we are not looking to merge it with a debugger. Since Diamond is an open source project licensed under GPL, you have the right to fork Diamond and merge it with any code which has a GPL-compatible license. Keep in mind any fork that you create must have a new application name. This is the beauty of open source, you are free to use our source code as a basis for a new project as long as the name is different.
Ansel Sermersheim
CopperSpice Cofounder
barbara
Posts: 447
Joined: Sat Apr 04 2015 2:32 am
Contact:

Re: CopperSpice License Question

Post by barbara »

The real problem with OpenSource is all of the projects seem to spin a roulette wheel when choosing a license.
There are about four significant open source licenses, most of the rest are duplicates. We consider these to be the key ones: BSD, GPL, LGPL, and Apache.

When we select a license for one of our libraries our preferred choice is BSD. For applications we use GPL. The only time we use an alternative license is when we are required. Nothing about picking a license is based on chance or done haphazardly.

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

Re: CopperSpice License Question

Post by seasoned_geek »

ansel wrote: Fri Dec 18 2020 6:15 am
Open source licenses are certainly a bit tricky. If Project A is GPL and Project B is BSD, you can certainly combine them. However, the overall project must be distributed under the terms of the GPL.

As a side issue, Diamond is a CopperSpice project and since it is not designed to be an IDE we are not looking to merge it with a debugger. Since Diamond is an open source project licensed under GPL, you have the right to fork Diamond and merge it with any code which has a GPL-compatible license. Keep in mind any fork that you create must have a new application name. This is the beauty of open source, you are free to use our source code as a basis for a new project as long as the name is different.
Thanks, yes, this was the explanation I was seeking. Most lawyers can't define GPL-compatible. At least not without thousands of billable hours.

If I get back to it, the fork will be RedDiamond on SourceForge. That will be just the fork of Diamond. It still has a very long way to go before it could be the base for an IDE.

The fork of Gede to CopperSpice, is RedBug on SourceForge. No, I haven't uploaded anything. I do like the debugger as it "works" built with Qt. It allows for debugging of Rust and Go. Eventually it will also be able to display a CopperSpice QString. Gotta rip out the DOS C programmer shortcuts in it though. Used a C char type all over the place. Got away with it under Qt. Fell over kind of bad with CopperSpice.
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: CopperSpice License Question

Post by seasoned_geek »

barbara wrote: Fri Dec 18 2020 6:23 am When we select a license for one of our libraries our preferred choice is BSD. For applications we use GPL. The only time we use an alternative license is when we are required. Nothing about picking a license is based on chance or done haphazardly.
I'm sure you believe that.
I'm certain many other OpenSource projects believe that.

That belief has lead to this list of OpenSource licenses.

https://opensource.org/licenses/category

When people want to use two or more different things together, it is a nightmare.
crispina
Posts: 22
Joined: Tue Nov 17 2020 2:57 pm

Re: CopperSpice License Question

Post by crispina »

CopperSpice users will have probably already seen the recent stories about Qt LTS versions going closed source. Some examples are below.
LTS versions of Qt going closed-source.
The Qt Company are making LTS releases commercial only and thus closed-source. "The problem is that these releases are in effect no longer maintained. If there is a security issue, or a fix needed to support some change in one of the target operating systems, open-source users will not get that fix other than in the not-ready version 6.0 .....
https://www.reddit.com/r/linux/comments/kr0j1h/lts_versions_of_qt_going_closedsource/
The Qt Company has followed up on its plan to make long-term support releases commercial-only by closing the source for 5.15 today, earning protests from open-source contributors who say that the 6.0 release, which remains open, is not yet usable...
https://www.theregister.com/2021/01/05/qt_lts_goes_commercial_only/
The Qt announcement is at:-
https://lists.qt-project.org/pipermail/development/2021-January/040798.html

Not sure how this will impact many Linux open source Qt projects in the long term and if they will consider switching to CopperSpice.
Post Reply