Bug 224135 - pango license field should be fixed
pango license field should be fixed
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pango (Show other bugs)
rawhide
All All
medium Severity low
: ---
: ---
Assigned To: Behdad Esfahbod
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-24 06:56 EST by Roozbeh Pournader
Modified: 2009-09-21 15:54 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-01 18:17:27 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 Roozbeh Pournader 2007-01-24 06:56:48 EST
Description of problem:
Pango's license field says LGPL, while it contains parts that are dual-licensed
as GPL and FreeType Project License.

Version-Release number of selected component (if applicable):
1.15.5-1.fc7

How reproducible:
Always

Steps to Reproduce:
1. rpm -q --qf "%{LICENSE}\n" pango
  
Actual results:
LGPL

Expected results:
GPL (or maybe something more descriptive)
Comment 1 Behdad Esfahbod 2007-01-24 11:52:12 EST
That's true.  However setting to GPL would be very wrong.  For one, it means you
cannot link non-FreeSoftware apps to Pango.

I've thought about this before, and I think GPL+FreeType is a superset to LGPL
from the point of view of how you can('t) use the library.

Pango's license is LGPL \cap (GPL \cup FreeType).  If we agree that LGPL \subset
(GPL \cup FreeType), it gives Pango's license is LGPL.

Ok, checked the FTL license and it seems that the only problem is the
advertising clause.  That is, LGPL \subset (FTL sans advertising clause). 
However, take a moment to think about what the advertising clause says:

    o You may not pretend that  you wrote this software.  If you use
      it, or  only parts of it,  in a program,  you must acknowledge
      somewhere  in  your  documentation  that  you  have  used  the
      FreeType code. (`credits')

So this only applies to code or products embedding the code.  Not those linking
to it.  Right?  Given that LGPL includes the Copyright preservation rule, I
believe you treating FTL code as LGPL fulfils the FTL license completely. 
(There is a minor issue though, that the Copyright holders of the code are the
individual authors of FreeType, not the FreeType project.  So you can tactically
remove any mention of FreeType, just leave the copyright holders...).


Anyway, if anything's to change, it should be the GPL+FTL license.  I decided to
do that by replacing the code instead of replacing the license.
Comment 2 Roozbeh Pournader 2007-01-26 08:38:30 EST
Random snippets from discussions on fedora-extras-list:

Christopher Stone:
> I had this discussion on IRC a few days ago and the conclusion was you
> either label it as GPL, or split the package up into a sub package
> that has the LGPL parts.

Ralf Corsepius:
> Fundamental counter-question: Do the GPL infected parts of pango impose
> the GPL on non-GPL'ed applications being linked against it?
> 
> If yes, then this would be the end of gtk and GNOME, definitely the end
> of pango.
Comment 3 Roozbeh Pournader 2007-01-26 09:18:58 EST
(In reply to comment #1)
> That's true.  However setting to GPL would be very wrong.  For one, it means
> you cannot link non-FreeSoftware apps to Pango.

I think your license discussions are quite wild. I don't think I can follow some
parts of it. Also, I don't know what is the *intended* usage of the license
field in the RPM really, but it could be used in many ways, which includes both
"How may I link against it?" (like the license of packages that Require: pango)
and "How may I extend it?" (like the license of patches that extend it). Some
details below:

> Pango's license is LGPL \cap (GPL \cup FreeType). [...]

Depends on how you define a license as a set. It seems that your are defining
the set members as things that the license allows you to do (which not very
well-defined, because that is mostly defined in different copyright and patent
laws and depends on the jurisdiction), which we can call the license's freedoms. 

In that case, the part in the parentheses should be "GPL *or* FreeType". You
can't have all the freedoms the GPL and the FTL licenses give you. You can
either have the freedoms offered by the GPL, or the freedoms offered by the FTL,
or the intersection of the freedoms offered by the two.

> [...] So this only applies to code or products embedding the code.  Not those
> linking to it.  Right?

Assuming that you are not missing other requirements of the FTL which may make
it incompatible with GPL/LGPL, the license field in the RPM is not necessarily
about what may be linked to the library in the RPM. It's also about how may the
RPM be extended, I believe.

> Anyway, if anything's to change, it should be the GPL+FTL license.  I decided
> to do that by replacing the code instead of replacing the license.

That would quite help the occasional headache that I get when I encounter this
case again and again. Thanks a lot.

But before that, please consider using a license field saying something like this:
LGPL and (GPL or FreeType Public License)

..., or consider packaing the GPL/FTL parts separately (/me hides).
Comment 4 Michael Schwendt 2007-01-26 10:39:30 EST
Let's put the RPM "License:" tag aside for a moment, please.
If authors choose double-licensing, this ought to become clear in
the header of the source files, too.

If any source file is GPL'ed (according to its file header, for
instance), the combined work must be GPL'ed, too. This is a MUST
and is in accordance with the licence terms of the GPL. You cannot
relicense or sublicense the GPL'ed files and neither the combined
work. The combined work cannot be LGPL either, because the LGPL and
the GPL are not equivalent and not interchangable. The LGPL is *less*
restrictive in that you can use the source in proprietary programs.
This would be in violation of the licence terms which applies to
GPL'ed portions of the source code, which require the combined work
to be GPL'ed, too.
Comment 5 Behdad Esfahbod 2007-01-26 14:33:32 EST
All the comments other than roozbeh's own words are missing some point of the
problem.
Comment 6 Roozbeh Pournader 2007-01-27 04:06:24 EST
(In reply to comment #4)
> If any source file is GPL'ed (according to its file header, for
> instance), the combined work must be GPL'ed, too. [...]

Sure. But no file is strictly GPL'ed. Only some of the files are double licensed
GPL and FTL. The code is here:

http://svn.gnome.org/viewcvs/pango/trunk/pango/opentype/

The file headers say different things: some don't mention the license (like
harfbuzz-buffer.c) and some say LGPL (like harfbuzz-dump.c), but most refer to
the file COPYING which says choose either GPL (version 2 only) or the FreeType
License for the subdirectory.
Comment 7 Michael Schwendt 2007-01-27 05:16:03 EST
All that matters is that _when you choose_ a licence from the
(GPL, FTL) upon reusing the dual-licensed files in a _valid_ way,
do you choose the licence of your derived product in an
irreversible way? E.g. LGPL => GPL and FTL => LGPL are both an
irreversible change in the licensing.

If you proceed in accordance with the terms of the FTL (since you
cannot return from GPL to LGPL) and _relicense_ your work under
the LGPL, are they fully compatible? (cf. sections 4-6 of the LGPL)

[...]

Extracting and reusing multi-licensed individual source files is
a gray area and a different topic (especially wrt unmodified files).
Comment 8 Liang Zhang 2007-09-28 04:41:54 EDT
The upstream bug:
http://bugzilla.gnome.org/show_bug.cgi?id=481207
Comment 9 Behdad Esfahbod 2008-02-01 18:17:27 EST
HarfBuzz has been relicensed to MIT Old Style in 1.19.x which is in Rawhide.

  http://lwn.net/Articles/265375/

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