Bug 657552 - License violation
License violation
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: shared-color-profiles (Show other bugs)
rawhide
All Linux
low Severity urgent
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-Legal
  Show dependency treegraph
 
Reported: 2010-11-26 07:57 EST by Kai-Uwe Behrmann
Modified: 2011-01-13 11:41 EST (History)
4 users (show)

See Also:
Fixed In Version: shared-color-profiles-0.1.3-1.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-11 08:33:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kai-Uwe Behrmann 2010-11-26 07:57:47 EST
Description of problem:
The ICC profiles in the Oyranos folder are modified and thus not original.
The zlib/libpng license clearly states:
    2. Altered source versions must be plainly marked as such, and must not be
    misrepresented as being the original software.


Version-Release number of selected component (if applicable):
shared-color-profiles-extra 0.1.1


How reproducible:
Download the http://sourceforge.net/projects/openicc/ openicc-data-1.0.0.tar.gz
look at the accompanying license file. Compare the ICC profiles by name and
with a binary diff tool. They very obviously and willingly differ, which is not allowed.


Steps to Reproduce:
1. 
2. 
3.
  
Actual results:
non original ICC profiles harm Oyranos dependent packages. It was requested
to split the Oyranos profiles out, so other projects can use them.
The faked profiles irritate developers and users.


Expected results:
replace the ICC profiles by the openicc-data-1.0.0.tar.gz from http://sourceforge.net/projects/openicc/
or rename the profiles (but who uses them then?)
or remove them entirely


Additional info:
http://www.opensource.org/licenses/zlib-license.php
https://github.com/hughsie/shared-color-profiles/issues/issue/1
http://lists.freedesktop.org/archives/openicc/2010q3/002204.html
Fedora RPMs for OpenICC-data:
https://build.opensuse.org/package/binaries?package=openicc-data&project=multimedia:color_management&repository=Fedora_13
Comment 1 Christoph Wickert 2010-12-28 16:27:00 EST
This is a legal issue, adding a blocker on bug 182235
Comment 2 Richard Hughes 2011-01-11 04:29:09 EST
Kai-Uwe already reported the bug upstream in https://github.com/hughsie/shared-color-profiles/issues/issue/1 which I fixed the very next day by renaming the profiles to make it clear they were not from oyranos.

For the record, All I did was changed the titles into the correct case and formatting so they matched the other profiles in the shared-color-profiles package. I will upload a new shared-color-profiles package today to rename the profiles to match upstream.

And, for the record, such a simple ICC profile normally isn't considered appropriate for a license as it constitutes trivial data. Really, the sRGB and AdobeRGB profiles are three 2D floating-point co-ordinates. That said, I will update the package in Fedora to avoid legal arguments.

gnome-color-manager uses the profiles shipped in share-color-profiles to be able to provide a few RGB and GREY working spaces to applications by default.
Comment 3 Kai-Uwe Behrmann 2011-01-11 05:07:01 EST
I reported the bug publicly on a email list in reply to your message end of august 2010. The profiles should not have appeared in Fedora 14 at all.

You obtained reasoning from several colour management experts on the OpenICC list, why its bad behaviour to alter shipped ICC profile data and thus changing the md5 hash sum. Changed profiles can alter unneeded colour conversions in various work flows.

In opposite to Richards above statement, ICC profiles are subject to licensing with clear legal enforcement. Look into ICC profiles from Xrite, Heidelberg or other profiling vendors. The ICC standard makes it clear that the copyright tag is mandatory for a complete and valid ICC profile.

Its still much easier to use the peer reviewed OpenICC-data profile package as well in Fedora. Btw. its the only package, which covers the complete required set for using Oyranos and dependent applications like kolor-manager for KDE and CinePaint.
Comment 4 Richard Hughes 2011-01-11 08:33:12 EST
(In reply to comment #3)
> In opposite to Richards above statement, ICC profiles are subject to licensing
> with clear legal enforcement. Look into ICC profiles from Xrite, Heidelberg or
> other profiling vendors. The ICC standard makes it clear that the copyright tag
> is mandatory for a complete and valid ICC profile.

Please talk to a member of fedora legal if you are concerned about legal matters. I think you'll find copyrighting three pairs of floating point numbers is kinda tricky, which is the ones we're referring to.

> Its still much easier to use the peer reviewed OpenICC-data profile package as
> well in Fedora. 

Right, as some background, you maintain OpenICC-data which is a direct competitor to shared-color-profiles. So you could say you're somewhat biased. 

That said, if you want to submit OpenICC-data for inclusion into Fedora I suggest you go through the same package review process that shared-color-profiles has. I'm certainly not going to attempt to impede it, but in the same way I'm not going to change gnome-color-manager to depend on your package rather then shared-color-profiles.

> Btw. its the only package, which covers the complete required
> set for using Oyranos and dependent applications like kolor-manager for KDE and
> CinePaint.

Right, we don't ship kolor-manager, cinepaint or oyranos by default in any spin of Fedora. This bug should focus on the reported license violation (which could have been solved easily in IRC or email, btw).

Anyway, I've released shared-color-profiles-0.1.3 and just built this for rawhide. If there are no problems I'll also built it for F14 in a few days.

Richard.
Comment 5 Kai-Uwe Behrmann 2011-01-11 10:01:16 EST
(In reply to comment #4)
> (In reply to comment #3)

> > Its still much easier to use the peer reviewed OpenICC-data profile package as
> > well in Fedora. 
> 
> Right, as some background, you maintain OpenICC-data which is a direct
> competitor to shared-color-profiles. So you could say you're somewhat biased. 

I don't feel like a competitor in providing a coherent set of ICC data profiles to the graphics community and this since years. I don not get any payment or other advantage by doing so, other that moving things forward. But I care a lot about fragmentation as this is bad for the Linux graphics stack.
 
> That said, if you want to submit OpenICC-data for inclusion into Fedora I
> suggest you go through the same package review process that
> shared-color-profiles has. I'm certainly not going to attempt to impede it, but
> in the same way I'm not going to change gnome-color-manager to depend on your
> package rather then shared-color-profiles.

Various ICC profile packages with similar data inside is non understandable by outsiders. The package is not my personal one. The content comes from various sources and was peer reviewed by the OpenICC list readers. You are free to commit.

> > Btw. its the only package, which covers the complete required
> > set for using Oyranos and dependent applications like kolor-manager for KDE and
> > CinePaint.
> 
> Right, we don't ship kolor-manager, cinepaint or oyranos by default in any spin

CinePaint and ICC Examin are available from the Fedora online repositories. Just use the Fedora package manager.

> of Fedora. This bug should focus on the reported license violation (which could
> have been solved easily in IRC or email, btw).

I am not excited about such slapstick comments. You had the chance to solve that since 30th august 2010. It needed several steps by me, to see responsible action on your side.
 
> Anyway, I've released shared-color-profiles-0.1.3 and just built this for
> rawhide. If there are no problems I'll also built it for F14 in a few days.
> 
> Richard.
Comment 6 Kevin Kofler 2011-01-13 11:18:31 EST
Is this even a license violation in the first place? The license says:
>    2. Altered source versions must be plainly marked as such, and must not be
>    misrepresented as being the original software
but it does not say how this marking has to happen, i.e. that the name of the folder has to be changed.
Comment 7 Kai-Uwe Behrmann 2011-01-13 11:41:47 EST
As long as the name of a person or project is continually used without permission, the misinterpretation is nearly forced. Crippling data and then foreseeingly publicise under the old name is exactly what this clause is about to avoid. 

For the record, the new package is a compilation from different sources. So the directory name very much inappropriately points to the original author of the modified data.

Note You need to log in before you can comment on or make changes to this bug.