Increases the importance since it is a critical bug.

(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

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

Because it might lead to the removal of fop from Debian and Ubuntu...

(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

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

(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

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

see http://issues.apache.org/jira/browse/LEGAL-131

resetting P2 open bugs to P3 pending further review

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.

I am in touch with HP on this subject. Looks like they might be able to do something about this file.

(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?

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.

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.

for glyph list adobe change the license see http://sourceforge.net/adobe/aglfn/home/Home/

http://sourceforge.net/adobe/aglfn/wiki/License/

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.

(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?

(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?

(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

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).