Please describe the problem:
https://bugzilla.redhat.com/show_bug.cgi?id=224135

Opened by Roozbeh Pournader (roozbeh@farsiweb.info)  	 on 2007-01-24 06:56 EST  	[reply]  	   Private

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 From Behdad Esfahbod (besfahbo@redhat.com) 	on 2007-01-24 11:52 EST 	[reply] 	Private

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 From Roozbeh Pournader (roozbeh@farsiweb.info) 	on 2007-01-26 08:38 EST 	[reply] 	Private

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 From Roozbeh Pournader (roozbeh@farsiweb.info) 	on 2007-01-26 09:18 EST 	[reply] 	Private

(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 From Michael Schwendt (bugs.michael@gmx.net) 	on 2007-01-26 10:39 EST 	[reply] 	Private

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 From Behdad Esfahbod (besfahbo@redhat.com) 	on 2007-01-26 14:33 EST 	[reply] 	Private

All the comments other than roozbeh's own words are missing some point of the
problem.


Comment #6 From Roozbeh Pournader (roozbeh@farsiweb.info) 	on 2007-01-27 04:06 EST 	[reply] 	Private

(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 From Michael Schwendt (bugs.michael@gmx.net) 	on 2007-01-27 05:16 EST 	[reply] 	Private

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




Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information: