Bug 52704 - sRGB Color Space Profile is subject to 3rd party copyright
sRGB Color Space Profile is subject to 3rd party copyright
Status: NEW
Product: Fop - Now in Jira
Classification: Unclassified
Component: general
all
PC Linux
: P3 major
: ---
Assigned To: fop-dev
:
Depends on:
Blocks: 53044
  Show dependency tree
 
Reported: 2012-02-18 12:00 UTC by Sylvestre Ledru
Modified: 2012-08-16 14:09 UTC (History)
0 users



Attachments
Changes to FOP similar to that of pdf-box whereby the files are downloaded at compile time. (6.57 KB, patch)
2012-05-31 14:43 UTC, Robert Meyer
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sylvestre Ledru 2012-02-18 12:00:05 UTC
The file 
./src/java/org/apache/fop/pdf/sRGB Color Space Profile.icm
is not free. The attached license:
./src/java/org/apache/fop/pdf/sRGB Color Space Profile.icm.LICENSE.txt

contains the following:
 "...permission to use, copy and distribute this file for any purpose is
 hereby granted without fee, provided that the file is not changed
 including the HP copyright notice tag, ... "

This has been reported here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657281
and
https://savannah.nongnu.org/bugs/?34579
Comment 1 Sylvestre Ledru 2012-04-04 16:37:05 UTC
Increases the importance since it is a critical bug.
Comment 2 Glenn Adams 2012-04-04 17:36:14 UTC
(In reply to comment #1)
> Increases the importance since it is a critical bug.

please explain why you believe this is a critical bug; at present, there is no documented policy in the FOP project for labeling the importance of bugs
Comment 3 Glenn Adams 2012-04-04 17:47:57 UTC
change bug title to correspond to the real issue; the issue is not whether use of the sRGB file is free or not; in fact, it is free (no fee) according to the indicated copyright

someone needs to review whether this file satisfies the requirements listed in http://www.apache.org/legal/resolved.html, and, if it does not, then find a work around
Comment 4 Sylvestre Ledru 2012-04-04 18:14:19 UTC
Because it might lead to the removal of fop from Debian and Ubuntu...
Comment 5 Glenn Adams 2012-04-04 18:19:02 UTC
(In reply to comment #4)
> Because it might lead to the removal of fop from Debian and Ubuntu...

please provide further details about this threat; in particular, please elaborate your position on whether and how the included file is inconsistent with http://www.apache.org/legal/resolved.html#criteria
Comment 6 Sylvestre Ledru 2012-04-04 18:22:28 UTC
Sorry, I though it was clear enough.

The license says: "provided that the file is not changed"

It does not respect the criteria "The license must meet the Open Source Definition."

The OSD [1] says:
"3. Derived Works

The license must allow modifications"

[1] http://www.opensource.org/osd.html
Comment 7 Glenn Adams 2012-04-04 18:26:19 UTC
(In reply to comment #6)
> Sorry, I though it was clear enough.
> 
> The license says: "provided that the file is not changed"
> 
> It does not respect the criteria "The license must meet the Open Source
> Definition."
> 
> The OSD [1] says:
> "3. Derived Works
> 
> The license must allow modifications"
> 
> [1] http://www.opensource.org/osd.html

thanks, that is what I was looking for... i've asked the FOP PMC chair to initiate an inquiry|action on this matter; i'm sure it will be resolved without much difficulty
Comment 8 Chris Bowditch 2012-04-05 07:17:44 UTC
Hi guys,

I've referred this to Apache's Legal team. I'm hoping it isn't a problem since we have no plans to modify the file so we are therefore in compliance with the HP License.

Failing that the file will have to be moved to OFFO and a configuration item added to the fop.xconf to reference the file externally. Users will then be required to download it separately.

I will let you know when I hear back from legal.

Thanks,

Chris
Comment 9 Glenn Adams 2012-04-05 14:22:26 UTC
see http://issues.apache.org/jira/browse/LEGAL-131
Comment 10 Glenn Adams 2012-04-07 01:42:40 UTC
resetting P2 open bugs to P3 pending further review
Comment 11 Jeremias Maerki 2012-04-09 11:54:55 UTC
I'm pretty sure the following will be the outcome of the request for comment to the ASF legal list: The sRGB profile will likely need to be removed from the Subversion repository and downloaded from the internet during build (which I find weird and unreliable). Apache PDFBox had to do similar things:

http://www.apache.org/legal/resolved.html#no-modification

I had added the profile back in 2006 in good faith that putting the license text right next to the file is sufficient. Apparently, it isn't.

While this fixes the problem for the ASF, the binary JAR will still contain the color profile which the Linuxers will still leave unhappy. However, I wonder how other open source projects packaged as Unix packages avoid the problem of using things like Adobe's CMaps and Base14 AFM font metrics files.

To fix the Linuxers' problem we'd need an open source implementation of the sRGB spec as an ICC color profile. I haven't found one on the net. Practically all color profiles I can find have similar license terms as the HP color profile. Also note that Oracle Java 6.0_29, for example, also bundles the exact same HP sRGB profile as Apache FOP. OpenJDK, OTOH, seems to be having a different sRGB profile which contains the string "lcms" and that points to LittleCMS, but I haven't found the original file in its source code. I also had problems finding the source code repository of OpenJDK to get an idea where that file came from and what its license is. Maybe the Linuxers can help here.

Note that the sRGB color profile was added so the colors coming from XSL-FO and SVG can remain untouched for the output formats that support ICC color management (ex. PDF). FOP could theoretically live without the profile but at the loss of calibrated RGB colors and PDF/A and PDF/X functionality. I'm sure that's not in the interest of the project.
Comment 12 Sylvestre Ledru 2012-04-13 11:26:24 UTC
I am in touch with HP on this subject. Looks like they might be able to do something about this file.
Comment 13 Glenn Adams 2012-05-01 22:06:05 UTC
(In reply to comment #6)
> Sorry, I though it was clear enough.
> 
> The license says: "provided that the file is not changed"
> 
> It does not respect the criteria "The license must meet the Open Source
> Definition."
> 
> The OSD [1] says:
> "3. Derived Works
> 
> The license must allow modifications"
> 
> [1] http://www.opensource.org/osd.html

I notice that ASF pdfbox LICENSE.TXT includes the *unmodifiable* Adobe glyph list, saying the following in LICENSE.txt:

Glyphlist (http://www.adobe.com/devnet/opentype/archives/glyph.html)

   Copyright (c) 1997,1998,2002,2007 Adobe Systems Incorporated

   Permission is hereby granted, free of charge, to any person obtaining a
   copy of this documentation file to use, copy, publish, distribute,
   sublicense, and/or sell copies of the documentation, and to permit
   others to do the same, provided that:
   - No modification, editing or other alteration of this document is
   allowed; and
   - The above copyright notice and this permission notice shall be
   included in all copies of the documentation.

So there does appear to be at least one exception to the modifiable rule. Perhaps we can use this precedent to resolve our issue?
Comment 14 Robert Meyer 2012-05-31 14:43:10 UTC
Created attachment 28865 [details]
Changes to FOP similar to that of pdf-box whereby the files are downloaded at compile time.

I have attached a diff file with a possible solution to this problem. New entries have been added to the ant build script to download the files at compilation and place them into the build directory. Unfortunately, this is not just a patch and go as a modification will be need to be made to the rgbprofile.url property in the get-dependencies.xml file to determine the web location of where the file and its license can be found.

Also, although I removed the existing color profile from the src directory, the diff does not reflect this as it is a binary file and therefore will need to be removed manually.
Comment 15 alexandre.prokoudine 2012-06-04 18:16:18 UTC
Folks,

It's not exactly difficult to create a new sRGB profile that would be identical to the original one and have the licensing that you need.  In fact, Argyll color management system includes such an sRGB profile (and some more). Argyll's profiles are under GNU Affero GPL v3.
Comment 16 roucaries 2012-07-09 09:19:16 UTC
for glyph list adobe change the license see http://sourceforge.net/adobe/aglfn/home/Home/

http://sourceforge.net/adobe/aglfn/wiki/License/
Comment 17 Chris Bowditch 2012-07-09 16:16:33 UTC
Thanks for that information. The new license does indeed permit redistribution and modification. We also have a patch from Robert that will switch to downloading the file at compile time instead of including in the source. So for the 1.1 release we can either:

1. Apply Robert's patch or
2. Update the license header in the Adobe Glyph List source file to match the new one.
Comment 18 Glenn Adams 2012-07-09 16:25:04 UTC
(In reply to comment #12)
> I am in touch with HP on this subject. Looks like they might be able to do
> something about this file.

any news?
Comment 19 Glenn Adams 2012-07-09 16:26:18 UTC
(In reply to comment #15)
> Folks,
> 
> It's not exactly difficult to create a new sRGB profile that would be
> identical to the original one and have the licensing that you need.  In
> fact, Argyll color management system includes such an sRGB profile (and some
> more). Argyll's profiles are under GNU Affero GPL v3.

would you be willing to submit a patch that provides an ASF license compatible version of this profile that can be included in FOP distribution?
Comment 20 Sylvestre Ledru 2012-07-09 16:32:24 UTC
(In reply to comment #18)
> (In reply to comment #12)
> > I am in touch with HP on this subject. Looks like they might be able to do
> > something about this file.
> 
> any news?

Nothing yet. I pinged him 2 weeks ago but no answer. I just resent the email
Comment 21 Tom Callaway 2012-08-16 14:09:26 UTC
FWIW, this issue has been raised with Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=848659

As an additional data point, Fedora would strongly prefer that an ICM profile (under a Free license) be used (whether the existing one is relicensed by HP or if another one is found). The proposed patch having a download as part of the build process may resolve Apache of its legal obligations, but it would not resolve the same issue for any linux distribution (e.g. Fedora, Debian).