Calligra/Libs: Difference between revisions

From KDE Community Wiki
(→‎License cleanup: from Debian)
Line 102: Line 102:
words/msword-odf/wv2/src/word_helper.cpp
words/msword-odf/wv2/src/word_helper.cpp
words/msword-odf/wv2/src/wv2version.cpp
words/msword-odf/wv2/src/wv2version.cpp
</pre>
==Reported by Debian==
*From Raúl Sánchez: [email protected]
*http://lists.kde.org/?l=calligra-devel&m=141409908920334&w=2
<pre>
As a Debian maintainer of the calligra package, I'm reviewing licensing and
copyright details. We've found some issues that I'll explain in this email
and we'd like to hear your point of view.
I'm considering that general licensing as per COPYING, COPYING.DOC and
COPYING.LIB applies to any files that don't have an explicit license. But in
some cases it might be unclear, so I'm pointing them out.
Please correct me if there's any mistakes in this assessment.
ZIP files
=========
libs/flake/tests/store.zip:
  only jpg and png files.
PROPOSAL: if general license applies, no further action.
filters/libmsooxml/doc/presetShapeDefinitions.xml.zip:
  only an xml file. I'd assign this the general license. Just out of curiosity
what is this for?
PROPOSAL: if general license applies, no further action.
stage/templates/exportHTML/templates/stage.zip:
  This zip contains several png files which copyright and licensing I'd
appreciate to be confirmed. It also contains a css where I'd assume general
license applies and a minified js file (see next section)
PROPOSAL: if general license applies for png/jpg/css, no further action. Read
next section.
Minified js files
=================
  Minified js files are considered compiled files in Debian, and require source
code (the non minified js) to produce the minified/compiled file on package
build.
  The oldest changeset where I could trace
stage/templates/exportHTML/templates/stage.zip which contains the js/jquery-
min.js file is this:
http://commits.kde.org/calligra/0d3c0851acbeec87c541d50a803b0ee49c111a57
  Unfortunately, this is not enough to generate the minified file from source.
PROPOSAL: provided non-minified source and procedure to generate minified js
(possibly at build time)
More minified files:
kexi/webforms/webroot/extjs/ext-all.js
kexi/webforms/webroot/extjs/extjs/adapter/ext/ext-base.js
PROPOSAL1: provided non-minified source and procedure to generate minified js
(possibly at build time)
PROPOSAL2: remove webforms as already done in master.
Color profiles (ICC, ICM)
===================
  We're concerned about license for these profiles. In some cases, neither
licensing nor copyright is clear. Metadata is helpful, but not enough.
Public domain profiles are ok, but there must be a way to verify it. For
instance: download url where the authorship/license is stated.
  If color profiles (as binary file) are generated from a human readable
source, then having source (with licensing information) would be helpful as
well.
  Note: I used iccdump from debian package argyll to get profile metadata.
(argyll package is https://packages.debian.org/sid/argyll )
krita/data/profiles/WideGamut.icm (No copyright)
krita/data/profiles/sRGB.icm (No copyright)
PROPOSAL: verify authorship and licensing of these files.
krita/data/profiles/scRGB.icm (© Cyrille Berger)
  Verified. For instance:
  http://commits.kde.org/calligra/d97b7d6a5e46c057f6660cd76409b2eb62943612
PROPOSAL: If assessment is correct, no further action.
krita/data/profiles/krita25_lcms-builtin-sRGB_g100-truegamma.icc (No copyright,
use freely)
  Included in http://commits.kde.org/calligra/b0d83bbb35b5 mentioning an
email. Is that email public?
PROPOSAL: verify authorship and licensing of this file.
plugins/colorengines/lcms2/colorprofiles/data/fogra27l.icm (public domain)
  According to metadata, profile is public domain, yet the origin is needed for
verification.
  References:
  - Addition of the profile in koffice:
svn://svn.kde.org/home/kde/trunk/koffice/libs/pigment/colorprofiles/data/fogra27l.icm@1069457
  - Rename of the same profile in scribus (where it has been presumably taken)
    svn://scribus.net/trunk/Scribus@6750
PROPOSAL1: verify authorship and licensing of this file.
PROPOSAL2: fogra27l is superseded by fogra39l, according to
http://alturl.com/ztw34 (should take to fogra.org website). Using fogra39l
would lead to the same situation. See also http://www.color.org/fogra39.xalter
PROPOSAL3: switch to a verified free profile.
plugins/colorengines/lcms2/colorprofiles/data/CMY.icm (copyright Sun
Microsystems, 1996)
  This is very problematic. Debian packages can't ship this file without
clarifying licensing which I couldn't find anywhere.
  Added in
svn://svn.kde.org/home/kde/trunk/koffice/krita/data/profiles/CMY.icm@365801
PROPOSAL1: verify authorship and licensing of this file.
PROPOSAL2: switch to a verified free profile. Here is a public domain, generic
CMYK:
      http://www.argyllcms.com/cmyk.icm (see also
http://sourceforge.net/p/lcms/mailman/message/32755884/ )
Java jar files
==============
jar files are binary files, as such, in Debian we need the source code of those
files and generate them on package build (or removing the files from the tarball
and adding dependencies on the packages that provide these files).
In the jar case, there are some pointers on where the jar comes from, but
still bundling a generated binary is not desirable.
The fixes for that from the licensing point of view are:
- Removing the feature
- If the jar generates code needed at build time, adding the required (source)
files which are generated from the jar. But not the jar. Also include a script
or document a procedure how to get those files.
- If the jar is required as a runtime dependency, you could either add a run
time dependency on a separate package providing that jar or generate the jar
at build time.
filters/libmso/generated/mso.jar
  As per README in that directory this jar generates some code that's used
later.
PROPOSAL: Describe (or script) the procedure to generate the code and remove
the jar file.
filters/plan/mpxj/planconvert/jar/PlanConvert.jar
  The feature looks good, but maybe since there's already a cmake switch to
enable it the java part could be a separated dependency rather that
included in calligra itself. For instance: providing a separate package for
mpx conversion which calligra(plan) would invoke if feature is enabled.
PROPOSAL1: bundling source java files and build jar
PROPOSAL2: depend on external package.
Binaries
=========
These are binary files which should be avoided in an upstream tarball if
possible.
3rdparty/google-breakpad/src/client/mac/gcov/libgcov.a
3rdparty/google-breakpad/src/third_party/linux/lib/glog/libglog.a
3rdparty/google-breakpad/src/third_party/linux/lib/gflags/libgflags.a
3rdparty/google-breakpad/src/tools/windows/binaries/symupload.exe
3rdparty/google-breakpad/src/tools/windows/binaries/dump_syms.exe
PROPOSAL: remove these files.
  What do you think?
  On these licensing conflicts, Debian maintainers of Calligra decided to
repack the vanilla tarball, stripping the conflicting files. This is suboptimal
as well and requires more time from maintainers in order to check that
Calligra still works properly and workaround possible problems. This have been
done in order not to loose the chance Calligra is in the main section, where
Debian free software guidelines compliant packages live.
  Throughout this mail, there have been some proposals. I'm willing to provide
and review patches fixing the issues if you are ok with the proposals.
  If these all issues are addressed, calligra will stay in the debian main
section as it is now and we all would be probably happier :)
  Last but not least, thanks to Maximiliano Curia who helped a lot reviewing
and commenting on this email.
  Pd: Please, CC me on answers.
</pre>
</pre>


== Brainstorming ==
== Brainstorming ==
*[[/Brainstorming/]]
*[[/Brainstorming/]]

Revision as of 21:48, 23 October 2014

General

Design Documents and usecases

Calligra Wide Technologies

Common specifications

Todo for the libraries

In the 2.0 release the libs are shared only by the applications and external users will not be able to depend on forward compatibility of the libraries as shipped in 2.0

There are several things in the KOffice libraries that have to be renamed/deleted and generally cleaned up before we can make the libs become binary+source compatible in future features. Lets keep a list of things on a Refactor Todo page.

License cleanup

GPL code in LGPL libs/ dir: obtained using grep -lR "GNU General"|grep -e '\.h$' -e '\.cpp' -e '\.cc'|grep -v -e test -e benchmarks -e parser. Please remove items from the list when fixed.

main/thememanager.cpp
main/thememanager.h
pigment/compositeops/KoOptimizedCompositeOpFactory.cpp
pigment/compositeops/KoOptimizedCompositeOpFactory.h
pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.h
pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch_Scalar.cpp
pigment/compositeops/KoStreamedMath.h
pigment/compositeops/KoVcMultiArchBuildSupport.h
pigment/KoColorDisplayRendererInterface.cpp
pigment/KoColorDisplayRendererInterface.h
vectorimage/libwmf/qwmf.cc
vectorimage/libwmf/qwmf.h
widgets/KoContextBarButton.cpp
widgets/KoContextBarButton.h

Maybe also this - GPL code in filters/ dir:

libmso/msodraw.h
libmso/msoleps.h
libmso/shapes2.cpp
sheets/qpro/libqpro/qpro/common.h
sheets/qpro/libqpro/qpro/formula.h
sheets/qpro/libqpro/qpro/record_factory.h
sheets/qpro/libqpro/qpro/record.h
sheets/qpro/libqpro/qpro/stream.h
sheets/qpro/libqpro/qpro/tablenames.h
sheets/qpro/libqpro/src/formula.cc
sheets/qpro/libqpro/src/record.cc
sheets/qpro/libqpro/src/record_factory.cc
sheets/qpro/libqpro/src/stream.cc
sheets/qpro/libqpro/src/tablenames.cc
words/msword-odf/conversion.cpp
words/msword-odf/conversion.h
words/msword-odf/document.cpp
words/msword-odf/document.h
words/msword-odf/drawclient.cpp
words/msword-odf/exceptions.h
words/msword-odf/graphicshandler.cpp
words/msword-odf/graphicshandler.h
words/msword-odf/msdoc.h
words/msword-odf/mswordodfimport.cpp
words/msword-odf/mswordodfimport.h
words/msword-odf/paragraph.cpp
words/msword-odf/paragraph.h
words/msword-odf/tablehandler.cpp
words/msword-odf/tablehandler.h
words/msword-odf/texthandler.cpp
words/msword-odf/texthandler.h
words/msword-odf/versionmagic.h
words/msword-odf/wv2/src/associatedstrings.h
words/msword-odf/wv2/src/properties97.cpp
words/msword-odf/wv2/src/styles.cpp
words/msword-odf/wv2/src/textconverter.cpp
words/msword-odf/wv2/src/ustring.cpp
words/msword-odf/wv2/src/utilities.cpp
words/msword-odf/wv2/src/word95_generated.cpp
words/msword-odf/wv2/src/word95_helper.cpp
words/msword-odf/wv2/src/word97_generated.cpp
words/msword-odf/wv2/src/word97_helper.cpp
words/msword-odf/wv2/src/word_helper.cpp
words/msword-odf/wv2/src/wv2version.cpp

Reported by Debian

As a Debian maintainer of the calligra package, I'm reviewing licensing and
copyright details. We've found some issues that I'll explain in this email
and we'd like to hear your point of view.

I'm considering that general licensing as per COPYING, COPYING.DOC and
COPYING.LIB applies to any files that don't have an explicit license. But in
some cases it might be unclear, so I'm pointing them out.

Please correct me if there's any mistakes in this assessment.

ZIP files
=========
libs/flake/tests/store.zip:
  only jpg and png files.
PROPOSAL: if general license applies, no further action.

filters/libmsooxml/doc/presetShapeDefinitions.xml.zip:
  only an xml file. I'd assign this the general license. Just out of curiosity
what is this for?
PROPOSAL: if general license applies, no further action.

stage/templates/exportHTML/templates/stage.zip:
  This zip contains several png files which copyright and licensing I'd
appreciate to be confirmed. It also contains a css where I'd assume general
license applies and a minified js file (see next section)
PROPOSAL: if general license applies for png/jpg/css, no further action. Read
next section.

Minified js files
=================
  Minified js files are considered compiled files in Debian, and require source
code (the non minified js) to produce the minified/compiled file on package
build.

  The oldest changeset where I could trace
stage/templates/exportHTML/templates/stage.zip which contains the js/jquery-
min.js file is this:
http://commits.kde.org/calligra/0d3c0851acbeec87c541d50a803b0ee49c111a57

  Unfortunately, this is not enough to generate the minified file from source.
PROPOSAL: provided non-minified source and procedure to generate minified js
(possibly at build time)

More minified files:
 kexi/webforms/webroot/extjs/ext-all.js
 kexi/webforms/webroot/extjs/extjs/adapter/ext/ext-base.js
PROPOSAL1: provided non-minified source and procedure to generate minified js
(possibly at build time)
PROPOSAL2: remove webforms as already done in master.

Color profiles (ICC, ICM)
===================
  We're concerned about license for these profiles. In some cases, neither
licensing nor copyright is clear. Metadata is helpful, but not enough.
Public domain profiles are ok, but there must be a way to verify it. For
instance: download url where the authorship/license is stated.

  If color profiles (as binary file) are generated from a human readable
source, then having source (with licensing information) would be helpful as
well.

  Note: I used iccdump from debian package argyll to get profile metadata.
(argyll package is https://packages.debian.org/sid/argyll )

krita/data/profiles/WideGamut.icm (No copyright)
krita/data/profiles/sRGB.icm (No copyright)
PROPOSAL: verify authorship and licensing of these files.

krita/data/profiles/scRGB.icm (© Cyrille Berger)
  Verified. For instance:
  http://commits.kde.org/calligra/d97b7d6a5e46c057f6660cd76409b2eb62943612
PROPOSAL: If assessment is correct, no further action.

krita/data/profiles/krita25_lcms-builtin-sRGB_g100-truegamma.icc (No copyright,
use freely)
  Included in http://commits.kde.org/calligra/b0d83bbb35b5 mentioning an
email. Is that email public?
PROPOSAL: verify authorship and licensing of this file.

plugins/colorengines/lcms2/colorprofiles/data/fogra27l.icm (public domain)
  According to metadata, profile is public domain, yet the origin is needed for
verification.
  References:
  - Addition of the profile in koffice:
svn://svn.kde.org/home/kde/trunk/koffice/libs/pigment/colorprofiles/data/fogra27l.icm@1069457
  - Rename of the same profile in scribus (where it has been presumably taken)
    svn://scribus.net/trunk/Scribus@6750
PROPOSAL1: verify authorship and licensing of this file.
PROPOSAL2: fogra27l is superseded by fogra39l, according to
http://alturl.com/ztw34 (should take to fogra.org website). Using fogra39l
would lead to the same situation. See also http://www.color.org/fogra39.xalter
PROPOSAL3: switch to a verified free profile.

plugins/colorengines/lcms2/colorprofiles/data/CMY.icm (copyright Sun
Microsystems, 1996)
  This is very problematic. Debian packages can't ship this file without
clarifying licensing which I couldn't find anywhere.
  Added in
svn://svn.kde.org/home/kde/trunk/koffice/krita/data/profiles/CMY.icm@365801
PROPOSAL1: verify authorship and licensing of this file.
PROPOSAL2: switch to a verified free profile. Here is a public domain, generic
CMYK:
       http://www.argyllcms.com/cmyk.icm (see also
http://sourceforge.net/p/lcms/mailman/message/32755884/ )

Java jar files
==============
jar files are binary files, as such, in Debian we need the source code of those
files and generate them on package build (or removing the files from the tarball
and adding dependencies on the packages that provide these files).

In the jar case, there are some pointers on where the jar comes from, but
still bundling a generated binary is not desirable.

The fixes for that from the licensing point of view are:
- Removing the feature
- If the jar generates code needed at build time, adding the required (source)
files which are generated from the jar. But not the jar. Also include a script
or document a procedure how to get those files.
- If the jar is required as a runtime dependency, you could either add a run
time dependency on a separate package providing that jar or generate the jar
at build time.

filters/libmso/generated/mso.jar
  As per README in that directory this jar generates some code that's used
later.
PROPOSAL: Describe (or script) the procedure to generate the code and remove
the jar file.

filters/plan/mpxj/planconvert/jar/PlanConvert.jar
  The feature looks good, but maybe since there's already a cmake switch to
enable it the java part could be a separated dependency rather that
included in calligra itself. For instance: providing a separate package for
mpx conversion which calligra(plan) would invoke if feature is enabled.
PROPOSAL1: bundling source java files and build jar
PROPOSAL2: depend on external package.

Binaries
=========
These are binary files which should be avoided in an upstream tarball if
possible.
3rdparty/google-breakpad/src/client/mac/gcov/libgcov.a
3rdparty/google-breakpad/src/third_party/linux/lib/glog/libglog.a
3rdparty/google-breakpad/src/third_party/linux/lib/gflags/libgflags.a
3rdparty/google-breakpad/src/tools/windows/binaries/symupload.exe
3rdparty/google-breakpad/src/tools/windows/binaries/dump_syms.exe
PROPOSAL: remove these files.

  What do you think?

  On these licensing conflicts, Debian maintainers of Calligra decided to
repack the vanilla tarball, stripping the conflicting files. This is suboptimal
as well and requires more time from maintainers in order to check that
Calligra still works properly and workaround possible problems. This have been
done in order not to loose the chance Calligra is in the main section, where
Debian free software guidelines compliant packages live.

  Throughout this mail, there have been some proposals. I'm willing to provide
and review patches fixing the issues if you are ok with the proposals.

  If these all issues are addressed, calligra will stay in the debian main
section as it is now and we all would be probably happier :)

  Last but not least, thanks to Maximiliano Curia who helped a lot reviewing
and commenting on this email.

  Pd: Please, CC me on answers.

Brainstorming