Hi all.
This is an un-retiring request for QCad on Fedora (https://admin.fedoraproject.org/pkgdb/package/rpms/qcad/). Now upstream provides an open-source community edition version of QCad including files with following licenses:
## Main license: GPLv3 ## ## 3rd parties licenses: ## dxflib: GPLv2+. # See src/3rdparty/dxflib/gpl-2.0greater.txt ## opennurbs: Public domain (neither copyright nor copyleft apply). # See src/3rdparty/opennurbs/readme.txt ## quazip: LPGLv2+. # See src/3rdparty/quazip/lgpl-2.1.txt ## spatialindexnavel: MIT # See src/3rdparty/spatialindexnavel/COPYING ## stemmer: BSD 2-Clause License # See src/3rdparty/stemmer/bsd-2.txt ## Hershey fonts are released under the terms described in fonts/hershey.readme. ## Other fonts in directory 'fonts' are released as public domain (all copyright ## is waived).
I don't know if Hershey license can be accepted on Fedora.
Review: https://bugzilla.redhat.com/show_bug.cgi?id=1401967
On 12/06/2016 02:25 PM, Antonio Trande wrote:
Hi all.
This is an un-retiring request for QCad on Fedora (https://admin.fedoraproject.org/pkgdb/package/rpms/qcad/). Now upstream provides an open-source community edition version of QCad including files with following licenses:
## Main license: GPLv3 ## ## 3rd parties licenses: ## dxflib: GPLv2+. # See src/3rdparty/dxflib/gpl-2.0greater.txt ## opennurbs: Public domain (neither copyright nor copyleft apply). # See src/3rdparty/opennurbs/readme.txt ## quazip: LPGLv2+. # See src/3rdparty/quazip/lgpl-2.1.txt ## spatialindexnavel: MIT # See src/3rdparty/spatialindexnavel/COPYING ## stemmer: BSD 2-Clause License # See src/3rdparty/stemmer/bsd-2.txt ## Hershey fonts are released under the terms described in fonts/hershey.readme. ## Other fonts in directory 'fonts' are released as public domain (all copyright ## is waived).
I don't know if Hershey license can be accepted on Fedora.
QCad needs a re-review; i can see another package in return.
Thanks.
On 12/06/2016 08:25 AM, Antonio Trande wrote:
This is an un-retiring request for QCad on Fedora (https://admin.fedoraproject.org/pkgdb/package/rpms/qcad/). Now upstream provides an open-source community edition version of QCad
Could you comment on the current relationship of QCad to its fork LibreCAD, available in Fedora from librecad.org? I believe librecad was forked for licensing and/or maintenance issues, so I am glad to hear that moved forward, but can you give some background on where the situation stands now as to the relative merits of both projects?
On 12/09/2016 08:43 PM, Przemek Klosowski wrote:
On 12/06/2016 08:25 AM, Antonio Trande wrote:
This is an un-retiring request for QCad on Fedora (https://admin.fedoraproject.org/pkgdb/package/rpms/qcad/). Now upstream provides an open-source community edition version of QCad
Could you comment on the current relationship of QCad to its fork LibreCAD, available in Fedora from librecad.org? I believe librecad was forked for licensing and/or maintenance issues, so I am glad to hear that moved forward, but can you give some background on where the situation stands now as to the relative merits of both projects?
Are you saying that QCad cannot be easily maintained on Fedora? Current relationship of QCad to its fork LibreCAD is not a pertinent matter to the packaging for me.
On 12/10/2016 07:12 AM, Antonio Trande wrote:
On 12/09/2016 08:43 PM, Przemek Klosowski wrote:
On 12/06/2016 08:25 AM, Antonio Trande wrote:
This is an un-retiring request for QCad on Fedora (https://admin.fedoraproject.org/pkgdb/package/rpms/qcad/). Now upstream provides an open-source community edition version of QCad
Could you comment on the current relationship of QCad to its fork LibreCAD, available in Fedora from librecad.org? I believe librecad was forked for licensing and/or maintenance issues, so I am glad to hear that moved forward, but can you give some background on where the situation stands now as to the relative merits of both projects?
Are you saying that QCad cannot be easily maintained on Fedora? Current relationship of QCad to its fork LibreCAD is not a pertinent matter to the packaging for me.
I am not saying anything---I am asking this question to find out what are the relative merits of both projects, since their web pages do not directly make such comparisons.
The reason why I'm asking is that I believe that in general FOSS projects should fork as little as possible, and merge as much as possible, to avoid duplication of effort. There are circumstances where the fork is the only solution, of course, and I am asking what are the circumstances in this case.
Greetings
p
Przemek Klosowski wrote:
The reason why I'm asking is that I believe that in general FOSS projects should fork as little as possible, and merge as much as possible, to avoid duplication of effort. There are circumstances where the fork is the only solution, of course, and I am asking what are the circumstances in this case.
In this case, it looks like they forked because of the totally closed development structure of the upstream project and its unwillingness to port from Qt 3 to Qt 4. By now, we are in Qt 5 era, and the projects have diverged so much that a merger is highly unlikely.
Kevin Kofler
On Tue, 2016-12-13 at 19:45 +0100, Kevin Kofler wrote:
Przemek Klosowski wrote:
The reason why I'm asking is that I believe that in general FOSS projects should fork as little as possible, and merge as much as possible, to avoid duplication of effort. There are circumstances where the fork is the only solution, of course, and I am asking what are the circumstances in this case.
In this case, it looks like they forked because of the totally closed development structure of the upstream project and its unwillingness to port from Qt 3 to Qt 4. By now, we are in Qt 5 era, and the projects have diverged so much that a merger is highly unlikely.
I haven't followed the fork -- I didn't even realize it existed until this thread -- I stayed with upstream, even buying a license for a few years. While it'd be nice to see it move along to a newer Qt, I've been very impressed with the feature additions since it became closed and open again. I'm equally unimpressed with his build processes; one glaring example is http://www.qcad.org/bugtracker/index.php?do=details&task_id=1369. I started packaging it for myself just to work around such issues.
So I'm curious, has the fork maintained any sort of feature parity? Did it adopt Qt 4 or 5? If not, I'd much prefer to see the upstream product make it back to Fedora. If the fork does use a newer Qt but hasn't progressed much feature-wise then I don't know what to think of the situation other than it sucks.