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)
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.
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.
(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).
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.
All the comments other than roozbeh's own words are missing some point of the problem.
(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.
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).
The upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=481207
HarfBuzz has been relicensed to MIT Old Style in 1.19.x which is in Rawhide. http://lwn.net/Articles/265375/