[Pkg-fonts-devel] About the licensing of URW Garamond No. 8

[Walter Landry]

Nicolas Spalinger <nicolas_spalinger at sil.org> wrote:
> Walter Landry wrote:
>> Nicolas Spalinger <nicolas_spalinger at sil.org> wrote:
>>> Hi Walter,
>>>
>>> There are obviously varying needs and preferences (prejudices?) along
>>> the licensing spectrum but IMHO your reply is very reductive.
>>>
>>> At the end of the day upstreams make up their own mind about how they
>>> license their own creation but allow me to explain the reasoning of the
>>> OFL model a bit more:
>> 
>> I understand that many font designers want to put in annoying license
>> terms.  I really do understand that.  In fact, there are many regular
>> software developers who want to put in annoying license terms for
>> their programs.  Debian does not encourage these annoying terms for
>> programs, and Debian should not encourage annoying terms for fonts
>> either.
> 
> IMHO you are misunderstanding what I was trying to say: this was more of
> a general comment to describe our own views not just that of some
> particular upstreams:  there is a spectrum of community-validated
> licenses (I mean DFSG/FSF/OSD  compliant ones) and people have different
> preferences for various parts of the spectrum and it's fine. One license
> does not fit every single need or approach otherwise we'd all be using
> the same which is obviously not the case. How people interact with
> upstream and make relicensing recommendations reflects that is all I'm
> saying.

This whole discussion is about what license should be suggested to
upstream.  You want to suggest a license with annoying terms.  I want
to suggest a license without these annoying terms.

Regardless of what license is suggested, if upstream decides to use
OFL, then it can go into Debian.  This is not ideal, in the same way
that someone choosing the Q license is not ideal.

> The years of OFL research and community review have given birth to a
> nexus between the needs of two very different communities: type
> designers and the FLOSS communities. We have also pushed back on various
> unreasonable expectations from font designers to find an acceptable
> middle ground which the FSF, the Debian ftp-masters and OSI have
> validated. Having a common community-reviewed-and-validated license
> designed especially for fonts and to which the actual font design
> community has given input and now recognizes greatly helps in reducing
> licensing proliferation. Personally I am also very much in favour of
> Debian and other major community projects pushing back on software
> developers who put unreasonable requests on their licensing terms to the
> detriment of users.
> 
> Believe it or not but some designers actually want to do the right thing
> by contributing and benefiting from a libre software approach, there's
> just such a huge cultural gap to cross and a maze of crazy licenses full
> of programmer jargon that they very rarely get anywhere. A font-specific
> license helps tremendously. Compare the variety and quality of
> libre/open fonts now available to what we had a few years ago...

Just because a lot of people have agreed on an annoying license does
not mean that Debian should encourage it.

>>> For the GPL imcompatibility, fonts are much more useful aggregated to
>>> rather than "merged" with existing software, possible incompatibility
>>> with existing software licenses is not a problem. See
>>> http://www.gnu.org/licenses/license-list.html#Fonts
>> 
>> I was using the rendered fonts as art.  In the US, rendered fonts are
>> not copyrightable (as far as I understand).  Elsewhere, the situation
>> is unclear.
> 
> So how does the rendered art stand wrt. the GPL requirements? It is
> output or aggregation? The GPL GNU Bison exception discussion all over
> again?
> 
> As Khaled has rightly pointed out, the situation is not as unclear as
> you paint it to be. Especially for jurisdictions where fonts are clearly
> recognized as software and copyright or case laws have explicit mentions
> of their special status.

Khaled's reply just confirms that there are differing laws in
different jurisdictions.  That is why it is better to have a good
license for the fonts so that I do not have to depend on what a
jurisdiction thinks about rendered fonts.

>>> You say you needed a "GPL-compatible font" but what does that mean? I
>>> assume you needed a font to bundle with when distributing a piece of
>>> software under GPL, right? OFL-ed fonts explicitely allow anyone to
>>> bundle. (even with restricted software).  OTOH you probably want to
>>> recommend an external open font instead by adding a package dependency.
>> 
>> You have it backwards.  It is the GPL which does not allow
>> incorporating OFL-ed fonts.
> 
> Not sure I see what you mean here.
> What about aggregation?

I am not "aggregating" things.  It is an integral part of the program.
Without the art, the program would not run as surely as if I were
missing libc.

>>> BTW one of the goals we have in the Debian fonts team is to work to
>>> reduce the big duplication of fonts in various packages in our archive:
>>> there is no absolute need for every single piece of software to ship
>>> with its very own set of fonts... Sometimes it does but from a Debian
>>> perspective IMHO a dependency is much nicer. There is a lintian check
>>> for this too.
>>>
>>> I do agree that GPL-compatibility is great and very desirable but fonts
>>> have a different set of requirements corresponding to their special
>>> status and usage scenarios.
>> 
>> Somehow, everyone thinks that they are special and therefore they
>> deserve annoying license terms.  We had this debate on debian-legal
>> before with the LPPL.  I am sure we will have it again.  I still have
>> zero sympathy for this view.
> 
> Yes, we love a good debate don't we :-)
> The fact is that font software and font software producers don't behave
> in the same way than a program written in C by usual programmers.

Au contraire.  I have seen all of the same arguments from C programmers.

Cheers,
Walter Landry
wlandry at caltech.edu