The Ubuntu Font Licence

Naming restrictions in UFL considered non-free by Debian

Reported by Julian Andres Klode on 2011-04-24
48
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Ubuntu Font Family
Undecided
Unassigned
Ubuntu Font Licence
Undecided
Unassigned
Debian
New
Unknown
ubuntu-font-family-sources (Ubuntu)
Undecided
Unassigned

Bug Description

The Debian ftpmaster consider the Ubuntu Font License to be non-free:

  "After discussion in the FTP Team, we consider the font naming restrictions
  to restrictive and unclear for main."

  http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/2011-April/006515.html

Debian ITP:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603157

Paul Sladen (sladen) on 2011-04-26
Changed in ubuntu-font-family:
status: New → Incomplete
Changed in ubuntu-font-licence:
status: New → Incomplete
Changed in ubuntu-font-family:
milestone: none → 1.00
description: updated
Julian Andres Klode (juliank) wrote :

It seems to be that the restriction to keep "Ubuntu" in the name can be considered non-free. Changing section 2 into

"
2) The font name complies with the following:
(a) Modified Versions which are Substantially Changed must be renamed to
avoid use of the name of the Original Version or similar names entirely.
(b) Modified Versions which are not Substantially Changed must be
renamed either according to (a) or both (i) retain the name of the Original Version and (ii) add
additional naming elements to distinguish the Modified Version from the
Original Version. The name of such Modified Versions must be the name of
the Original Version, with "derivative X" where X represents the name of
the new work, appended to that name.
"

should work.

- Remove 2a)
- Allow total rename for not Substantially Changed versions.

Julian Andres Klode (juliank) wrote :

But no guarantee that it suffices.

The name requirements in the UFL are the result of some protracted
conversations with font designers, and they don't restrict what can be
done with the work in any way, they provide a framework for naming only.
As such, they appear to be in compliance with the DFSG as it stands
today, which specifically recognises that works can be free even if they
have special requirements around naming and versioning. The UFL amounts
to a requirement that minor derivatives use a version like "derivative
Foo X.y"

I respect the right of the ftp-masters to make their own call on that,
but it doesn't seem to add up under current Debian policy as I read it.

Mark

Julian Andres Klode (juliank) wrote :

I think the point is that a specific name is required rather than some random one, making it some kind of invariant section. If you make that "Ubuntu derivate Blah" part optional, and allow a free-form version for minor changes like you do for major changes, the problem goes away.

Gerfried Fuchs (rhonda) wrote :

Mark, I think you are referring to DFSG #4 (Integrity of The Author's Source Code), especially this sentence: "The license may require derived works to carry a different name ... from the original software."

While strictly reading it your suggestion doesn't directly violate this, the unclear wording that I pointed out in Bug #655096 is still there, and I can just guess that this is what the ftpmaster team is referring to here with respect to being "unclear" (not involved with their communication channels). To be honest I consider your response a bit disappointing, instead of trying to establish a communication channel to look for a scapegoat instead of trying to look for a solution.

A bit disappointed that there is no progress on this front,
Rhonda

Paul Sladen (sladen) on 2011-04-26
Changed in ubuntu-font-family-sources (Ubuntu):
status: New → Invalid
description: updated
Julian Andres Klode (juliank) wrote :

How about:

=== modified file 'ubuntu-font-licence-1.0.txt'
--- ubuntu-font-licence-1.0.txt 2011-04-26 13:55:39 +0000
+++ ubuntu-font-licence-1.0.txt 2011-04-26 15:37:33 +0000
@@ -56,10 +56,11 @@ readable metadata fields within text or
 fields can be easily viewed by the user.

 2) The font name complies with the following:
-(a) The Original Version must retain its name, unmodified.
-(b) Modified Versions which are Substantially Changed must be renamed to
-avoid use of the name of the Original Version or similar names entirely.
-(c) Modified Versions which are not Substantially Changed must be
+(a) The Original Version must retain its name, unmodified; or follow
+the same requirements as for Modified Versions.
+(b) Modified Versions must be renamed to avoid use of the name of
+the Original Version or similar names entirely.
+(c) Alternatively, Modified Versions which are not Substantially Changed may be
 renamed to both (i) retain the name of the Original Version and (ii) add
 additional naming elements to distinguish the Modified Version from the
 Original Version. The name of such Modified Versions must be the name of

Margarita Manterola (marga) wrote :

This was debated today for a number of hours on IRC, and we were requested to post comments here, so I'm doing it but only as a DD, not on behalf of Debian or anything like that, I hope you find this helpful.

The DFSG allows an author to require a name change when certain program is changed. It *doesn't* allow the author to say how the name should be changed, and most importantly, it *doesn't* allow the author to _PREVENT_ name changing.

Thus, the license should not prevent name changing for it to be considered free. As was suggested on IRC, replacing a must with a should on 2a) and 2c) might be enough for this.

The clarification of what is and what isn't a substantially changed version (https://bugs.launchpad.net/ubuntu-font-licence/+bug/655096) should also be addressed. Maybe changing the name is already a substantial change, thus allowing name changing without any further modification to the license?

BTW, I fail to see how this bug could be invalid. Naming restrictions *are* considered non-free. And will be considered non-free until fixed. How is this an invalid bug?

--
Regards,
Marga

Julian Andres Klode (juliank) wrote :

Or possibly even better:

=== modified file 'ubuntu-font-licence-1.0.txt'
--- ubuntu-font-licence-1.0.txt 2011-04-26 13:55:39 +0000
+++ ubuntu-font-licence-1.0.txt 2011-04-26 15:41:37 +0000
@@ -56,13 +56,14 @@ readable metadata fields within text or
 fields can be easily viewed by the user.

 2) The font name complies with the following:
-(a) The Original Version must retain its name, unmodified.
-(b) Modified Versions which are Substantially Changed must be renamed to
+(a) The Original Version must retain its name, unmodified;
+or follow the same requirements as for Modified Versions.
+(b) Modified Versions must be renamed to
 avoid use of the name of the Original Version or similar names entirely.
-(c) Modified Versions which are not Substantially Changed must be
+(c) Alternatively, Modified Versions which are not Substantially Changed may be
 renamed to both (i) retain the name of the Original Version and (ii) add
 additional naming elements to distinguish the Modified Version from the
-Original Version. The name of such Modified Versions must be the name of
+Original Version. The name of such Modified Versions may be the name of
 the Original Version, with "derivative X" where X represents the name of
 the new work, appended to that name.

Paul Sladen (sladen) on 2011-04-26
Changed in ubuntu-font-family:
status: Incomplete → Invalid
Adam Conrad (adconrad) wrote :

As I said on #debian-devel, I think the real problem here isn't the wording of the license (though changing the "musts" to "mays" certainly papers over the issue, and makes the license free again), it's that the entirety of section 2 is attempting to solve technical issues legally. This just plain isn't what distribution licenses are for.

IMO, section 2 should just be removed, and taken to a standards document which could, in turn, be fleshed out to be even more technical defining exactly how and when font name versioning should be done, etc. This is a problem not unlike library ABI versioning, and it definitely needs people steering a committee of folks to draw up proper standards, but those standards can not be enforced both legally and capital F freely.

To put this in perspective, if I distributed some shell scripts under a license that said "you may freely modify and distribute these scripts, provided your versions maintain POSIX compliance", that would be daft. New versions of the script no longer being POSIX compliant would certainly make them violate a standard, and would make them buggy in many people's minds, but it shouldn't make them illegal.

Changed in debian:
status: Unknown → Fix Committed
Paul Sladen (sladen) wrote :

Adam: a very interesting point. "Technical-solutions to social problems" etc. I've been thinking about codifying a "standard"; it would make regression testing easier.

Adam Conrad (adconrad) wrote :

To be clear, I wholeheartedly agree (based on my limited understanding of cross-platform font rendering and naming/versioning issues) that there is a technical issue here to be solved, and I support the fact that people are trying to solve it, I just disagree to the very core of my hippie free software being that it should be solved in a copyright license.

Bdale Garbee (bdale) wrote :

Given how font names are actually used and embedded, changing the name of a font is the *most significant change* you could ever make to a font.

Paul Sladen (sladen) wrote :

nb. to self (and others). I've been contacted by another DD you took the time to get an opinion from a lawyer over DFSG freeness/non-freeness, concluding that the UFL-1.0 text was 'non-free'. Neither the DD who took the time to make the enquiries, nor the lawyer involved, have been able to specifically highlight any sections or areas that lead to an opinion of non-freeness.

Julian Andres Klode (juliank) wrote :

Paul Sladen wrote:
> I've been contacted by another DD you took the time to get an opinion from a lawyer

That should be a "who", not a "you", right? Otherwise the sentence doesn't make sense.

Paul Sladen (sladen) wrote :

Juliank: yes, it should be s/you/who/.

Sorry for this being unclear. At the moment there is a lot of speculation, and very little clear fact, or "specificality". I'm hoping that by noting contact where it has been made it may encourage others to contribute to this bug report with specific points or concerns. A couple of days ago I emailed ftpmaster@d.o to try and ascertain further information about the discussion that is referred to have taken place: to keep people updated—I have not had an answer the Debian FTP Team yet.

Other people have also asked about comment #13. To clarify, the DD in question hasn't posted here, although it would be preferable than attempting to paraphase . The lawyer (again, I don't know who) apparently concluded that the text indicated DFSG non-freeness, but did not give a stated on-paper legal opinion or reasoning or further information or anything that would help to narrow-down any concern. (To have got such would apparently have required an official client-relationship between the DD and lawyer, which does not exist). At the moment that means there is nothing/little to go on or to investigate the (as-yet) unspecified concerns because it's hard to have a conversation without definites.

The latest comment on the Debian ITP is about an inability to rebuild the .deb package itself using only free-tools vs. whether the .ttfs are considered pure-data as in the case of many other libre (without source) fonts. There also has a bearing on which of Debian main/contrib/non-free the source could go into which depending on whether the preferred method of modification is the .ttf files or the .vfb (FontLab) files.

Supplmental braindump: A further query has been raised by another party was about BSD 4-clause paragraph 3 (considered DFSG-free) and how that fits with the interim UFL-1.0 Section 2a/2c on well-known-name preservation.

We regard .ttf as a binary distribution format. Editing it to make
modifications to a font (apart from the very lowest-level bit-flipping
in data tables) is pretty perverse and often unpleasant; you certainly
wouldn't want to edit the glyph outlines in a .ttf.

The lack of free tools capable of editing, building, and signing fonts
is something even we, as a commercial font foundry, lament.

Dave

Changed in debian:
status: Fix Committed → New
Ejectmail (ejectmail) wrote :

Not only that, the license is clearly not a free software license (as in freedom). Although the free software foundation hasn't said a word on it, I've conducted an analysis into it:

Suppose Mozilla Firefox were under this license. Forks like Iceweasel would have to be named "Firefox derivative Debian" or something similar. But the Mozilla trademark policy doesn't allow this, because the trademark and Firefox have both been modified. In this case, Canonical's trademark guidelines prohibit use of the Ubuntu name in commercial distributions. You must have the freedom to charge any price you want for free software.

In other words, the license grants no rights under trademark law, and yet it requires you to use the trademark if you make trivial changes. In virtually all other licenses, if the trademark policy doesn't work for you, you can just get rid of the trademark, but this license doesn't allow that.

For the freedoms of free software to be real, they must be permanent unless you do something wrong. In this case, one of your important freedoms can be taken away at will with a trademark, and therefore the license is non-free.

Paul Sladen (sladen) wrote :

Ejectmail, thank you for looking into it. Remember that the interim UFL has drawn up as a first take, with the hope to refine it, so input is appreciated, because out of it we can get a better libre font licence than the choices that were available at the time.

Obviously one must start somewhere. Ine must ensure that one always has the source code, the freedom to modify it, the freedom to give it to other people, and the freedom to sell it. The interim UFL has, as a minimum, all of these. I'm sure wording could be improved but it has a good foundation (note: the "propagation" wording is straight out of the GPLv3, various other sections come from SIL's OFL).

Onto trademarks, Trademarks, are about the point of use; and whether a consumer would be confused. It *is* possible to say (quite factually) "Iceweasel is based on Firefox", or "Iceweasel is Firefox with branding removed". What one cannot do is to say "Iceweasel is {insert huge big Firefox logo}". Indeed, free-software licences demand that attribution is made available and that the authorship is not misrepresented.

In the interim UFL text, one could potentially remove the (explicit) trademark sentence, and leave it simply (implicit). The net-effect would be the same (that you can't misrepresent to consumers that you are somebody, or something else).

The intention was to get existing type foundries working with a libre licence. I think the intention was to make it abundantly that people wouldn't be able to pick up MonoType FooBar Bold and sell it as genuine MonoType(tm) when they didn't have a trademark agreement to do so.

The bigger picture is what is important here. Making a libre font licence that *real type design companies* might actually be comfortable with using on a large-scale, and which caters to their concerns in terms of metrics-stability and not having a product passed off. For code, the industry with the GPLv2 and GPLv3. For fonts, it's not yet clear, and the hope was to try and solve that.

(nb. I know that the word "Ubuntu" here can be emotive, you're welcome to replace it with another word if it makes the discussion easier. Having "Ubuntu" there in the interim licence ensures that it won't be used elsewhere until it has been debugged. And that's where I would appreciate your assistance).

Ejectmail (ejectmail) wrote :

"Making a libre font licence that *real type design companies* might actually be comfortable with using on a large-scale, and which caters to their concerns in terms of metrics-stability and not having a product passed off."

But this license is NOT libre (yet). One of your important freedoms (to distribute trivial modifications) can be taken away at will if someone trademarks the font name, and therefore it is not a free software license. Also I'm not seeing it adopted by every proprietary foundry I see.

Here's how I would amend the license:

- I thought I should mention that there's an unintended consequence of the definition of "propagate". I wonder why it specifically includes "except executing it on a computer or modifying a private copy". The license only grants permission to Propagate the Font Software, so essentially it explicitly does not grant permission to use the fonts or modify a private copy. At least the preamble gives implicit permission to do those things, and I recall reading somewhere on the Ubuntu network of sites a note saying "feel free to use it in your documents".

- Additionally, it would be good to explicitly state that individuals do not have to rename modified private copies. The OFL doesn't do this.

- About section 2a: Why would you want to distribute a font with no changes other than the name? You would only lose the fame that the original version's name brings. You are prohibiting something that nobody would want to do, so there's no reason to retain that clause.

- Now to solve the problem of the naming restrictions. I took a while to think this over, because I know those restrictions were requested by the designers. Even if you remove "This license does not grant any rights under trademark law", the license is still non-free, because a trademark could still take away those freedoms at any time. I might suggest both removing that clause and granting the licensee an unlimited license (both within the conditions of the license and under trademark law) to use the font name in the "Y derivative X" name. For example, this could be appended to clause 2c(ii):

"Notwithstanding any other provision of this license, in the event that a modified version is not Substantially changed, permission is hereby granted to use the name of the Original Version solely in the context of meeting the requirements of this section."

Or something else that makes it clear that they may use the Original Version's name for any purpose in this context. That's what it would take to make this license free.

I listet bug #1167425 as duplicate of this one and then took it back. I was probaly to hasty since it was intentionally filed separately.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.