FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

LinkBack Thread Tools
Old 04-29-2011, 03:57 PM
Joerg Jaspert
Default Ubuntu Font Licence 1.0

[ Note that we decided to include the debian-devel list in our reply, as
this issue seems to have already found a wider audience, which we want
to invite to this discussion too. Please stay ontopic and away from
ranting about Ubuntu/Canonical/Whatever, gains nothing for anyone, but
help to resolve the issues at hand. Thanks.

On 12462 March 1977, Paul Sladen wrote:

> Hello all, I've see the following message to pkg-font; (at the moment
> I'm on a quest for information and not seeking to take a viewpoint):

> "[Pkg-fonts-devel] ubuntu-font-family-sources_0.70.1-1_amd64.changes REJECTED"
> http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/2011-April/006515.html

Yes. Turns out there was a slight misunderstanding on our side. It was
believed that a prod message containing an explanation had already been
sent out before the reject happened, so the reject was more concise than
it should have been.

> Juliank has forwarded the above to a bug report:
> "Naming restrictions in UFL considered non-free by Debian"
> https://bugs.launchpad.net/ubuntu-font-licence/+bug/769874

Heck, thats large already. Oh fun.

> and tried to guess/interpret. The email above notes a "discussion in
> the FTP Team". Would you/FTP master be able to provide a summary of
> the that discussion and add it to the bug report (LP: #769874)---this
> would make it easier to pass on to right people and flag up that
> there's a serious issue if there is one.

"To post a comment you must log in." - Sorry, but no, thanks. If there
would be a useful mail interface given (asking on IRC got one, but it
needs registered mail addresses which just sucks), sure, but we are not
jumping through extra hoops here. Please pass this mail to wherever it
should end up additionally instead.

> If it's helpful, there's a diff against the SIL OFL at:
> http://font.ubuntu.com/ufl/ofl-1.1-ufl-1.0.diff.html
> and there is a FAQ about the interim status/changed from the SIL OFL
> at (if for TL;DR, there are 9 bullet points at end):
> http://font.ubuntu.com/ufl/FAQ.html

> Some people on #debian-devel have raised versioning interaction with:
> http://www.debian.org/social_contract.html#guidelines (4)
> "The license may require derived works to carry a different name
> or version number from the original software."

> For clarity, I don't think the aim in developing an open/libre font is
> to distribute it under a non-DFSG licence! Thus, it would be useful
> to be take an FTP master summary back, to the people who can further
> deal with it and to be able to hold up the individual points
> specifically.

Ok, well, lets try.

The definitions include
"Substantially Changed" refers to Modified Versions which can be easily
identified as dissimilar to the Font Software by users of the Font
Software comparing the Original Version with the Modified Version.

What constitutes "easily identified as dissimilar"? Is it necessary to
check all characters in the font and if so, what check is meant? Is it
different if the md5sum of the font file is different? Is there a set of
special characters to check?
We actually doubt there can be an agreement when a font is dissimilar
for users, not with that text. Typographers would likely see something
as dissimilar where most users (us included) would see no difference at
all. Taken alone this may not be a show-stopper, but the definition is
used later on in such a way that the lack of clarity becomes a major

1 seems ok, except for some curiousity about the definition of "easily
viewed by the user"? Is a "strings font.ttf" easy? Or does it need to be
some kind of ttf viewer app? Does one need to make sure there is one for
all the platforms one intends to distribute? That might be a FAQ entry
somewhere, but that curious part just had to ask it. This is not a
reject reason though.

3 sounds ok to us.

4 in itself is free, even though it does take away even the authors
possibility to dual-license a work, should one chose to use this
license. Harsh, but nothing keeping it out of the archive.

So, the interesting part is 2, which is why it is listed last. And as a
short summary: We think that aspects of this section make the license
unsuitable for works in Debian main.

Taking 2b first. This subsection is in itself ok, DFSG 4 does allow to
require a different name for a distribution of modified version,
although "similar names" seems to be a bit of a gray area.

The major issues arise in subsections 2a and c. These two subsections
include between them an invariant section. This type of invariance is
not something covered by DFSG 4. DFSG 4 tries to allow a copyright
holder to say "If you change foo, you must not call it foo", but does
not have similar provisions to allow a copyright holder to say things
such as "You must not call foo by any other name" or "If you change foo,
the name you must use is bar". Especially noting the parenthetical
statement at the end of DFSG 4, we don't believe it would be in the
spirit or intent of the DFSG to make the leap that would be required to
say that 2a and c are allowed by this clause. The vote[0] taken by the
Debian project relating to the GFDL also reinforces the project's
dislike for invariance in main. It is also unclear as to whether "font
name" refers to the name of the font file on disk, the package name,
some form of internal font name or a combination of these. If the
reference is to the name of the font file or the internal font name,
this becomes a restriction on how you can modify the software, which
also fails to comply with DFSG 3.

Additionally 2c states exactly how you must change the name to follow
the license, which will cause issues if you want to combine multiple
fonts licensed using this license into a new derivative work, possibly
even making this impossible. This on its own is not a reject reason.

[0] http://www.debian.org/vote/2006/vote_001

Note that, while researching (basically reading IRC and bug logs) we
found claims that the preferred form of modification of those fonts are
in a format that is currently not able to be processed with tools
available in main. Remember that main needs to stay self contained, and
that it needs to be able to build itself. What we can read in the
current font tarball about the tools used does not seem to ensure this,
as it points to some "Free-as-in-beer" programs to process the source,
as well as some Commercial tool. And the build process description also
uses those tools. If the fonts get released under a free license, that
would put them into contrib only, not main. (Yes, we know that there are
fonts in Debian that only ship .ttf files. To the best of our knowledge
they are modified using ttf editors and ttf editors are available in
Debian main. This font family here is pretty clearly not modified using
ttf editors and therefore this doesn't apply here).

bye, Joerg
That's it! You people have stood in my way long enough. I'm going to
clown college!

Thread Tools

All times are GMT. The time now is 02:52 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org