9:08 p.m.
[This message is supposed to continue the thread about licensing questions,
but I just subscribed to the mailing list, so I can't reply directly to
those messages.]
*
From*: Nicolas Mailhot <nicolas mailhot laposte net>*
Subject*: Re: Help with licensing questions*
Date*: Tue, 10 Feb 2009 22:39:47 +0100
12. The author thinking the metatype sources would require him to
use
some other license than the OFL because they look more software-ish is
just confusing things (pretty common occurrence unfortunately). GPL-ing
the build scripts would probably be more interesting, but a. they're
lost and b. this would not change the font licensing at all.
I'm confused by this comment. My font Aurulent Sans is created by MetaType1
programs that look like this:
%% \--------------------------------------------------------------------
%% The letter n
%% %
%% \PICT{n}
%% \--------------------------------------------------------------------
beginfontglyph("n",ASCII("n"),.83lowwidth,lowsp_vert,lowsp_vert,xht,lowdepth);
x0=x1=leftstemloc; y0=xht; y1=0;
x2=x0; y2=.4[xht,y1];
x4=x41=x5=rightstemloc; y4=.3[xht,y1]; y5=0;
x3=.76[rt x1,lft x4]; % we choose the point to make "hump" farther to the
right so the divot is big.
% However, we have to be careful about bold fonts, so that x3 doesn't go
farther right than the left edge of x4.
top y3=top y31=xht+low_overshoot;
x31=.6[x3,x4]; y41=.75[y4,y3]; % works because the point put in is 1.75
expand_font_stroke.leftstem
(butt_end(0,1))
(z0--z1);
pen_stroke_method:=1;
expand_font_stroke.rightstem
(cut(fix_nib(join_px,join_py,prot),170)(0);
cut(extreme_angle(x4,px,x3,py,x2,.5))(1);
butt_end(last))
(z2{curl .3}..z3{right}..controls z31 and z41..z4{down}--z5);
pen_stroke_method:=0;
path P; P:=rightstem;
P:=smooth_straight_to_curve(P,5);
P:=smooth_curve_to_straight(P,2);
Fill smooth_curve(P);
Fill leftstem;
I think this is a program and very different than the MetaType1 sources for
Latin Modern and similar fonts that contain mainly just tables of data
points. In that sense, the GPL for the MetaType1 sources seems very
reasonable to me. Why do you think that it is inappropriate?
10. Lastly, font sources in metatype format can be non-trivial to
build,
and seem to require specific build scripts tuned to the TEX variant the
distro ships. Building any font from metatype would probably require
help from TEX specialists such as Jonathan Underwood.
11. In your case the author has lost those scripts, and does not intend
to work from metatype anymore (preferring direct fontforge editing), so
it's probably no great loss to forget the original metatype source. Just
get him to publish an authoritative sfd version of his font, and use it
as your source.
I have not lost the source for the MetaType1 programs, but rather for the
build scripts. As you point out, it's tricky to build MetaType1 files, and
I had created files that were particularly tuned to work with teTeX. I
don't really feel that it is advantageous to recreate these files. I would
much prefer to work on rewriting the MetaType1 programs using FontForge's
Python scripting.
Best wishes,
Stephen
9:51 a.m.
New subject: Help with licensing questions
Le Jeu 12 février 2009 04:08, Stephen Hartke a écrit :
> 12. The author thinking the metatype sources would require him
to
> use
> some other license than the OFL because they look more software-ish
> is
> just confusing things (pretty common occurrence unfortunately).
> GPL-ing
> the build scripts would probably be more interesting, but a. they're
> lost and b. this would not change the font licensing at all.
I'm confused by this comment.
[...]
I think this is a program and very different than the MetaType1
sources for
Latin Modern and similar fonts that contain mainly just tables of data
points. In that sense, the GPL for the MetaType1 sources seems very
reasonable to me. Why do you think that it is inappropriate?
Basically, I don't think the format of your font should drive your
licensing decisions. If the GPL is appropriate for the metatype
version it's appropriate for the OTF version. Just "it looks more like
software as usual" is a weak reason.
Now, I do agree one of the OFL's main weakness is its refusal to admit
fonts may have sources (the other being the way it considers you want
your font renamed instead of making it an option), but the GPL has
other problems (embedding). But the differences in their licensing
model are only marginally linked to the format.
I have not lost the source for the MetaType1 programs, but rather
for
the
build scripts. As you point out, it's tricky to build MetaType1
files, and
I had created files that were particularly tuned to work with teTeX.
I
don't really feel that it is advantageous to recreate these files. I
would
much prefer to work on rewriting the MetaType1 programs using
FontForge's Python scripting.
It would be very nice if you could publish the files you intend to
work from in buildable form so the Fedora packager can make a srpm
that produces fonts from your sources.
--
Nicolas Mailhot
3:51 p.m.
New subject: Help with licensing questions
[...]
Now, I do agree one of the OFL's main weakness is its refusal to
admit
fonts may have sources (the other being the way it considers you want
your font renamed instead of making it an option), but the GPL has
other problems (embedding).
Hi Stephen and Nicolas,
Very interesting thread indeed, some crucial points have been explained
very clearly but I have to disagree with the little analysis snippet
above... (BTW, Nicolas, IIRC we already had conversations about this
wrt. the buildpath of Old Standard).
The OFL doesn't refuse to admit that font sources exist - rather the
contrary - it acknowledges the fact that beyond the binary font files
themselves, which you can already do something with, there are a lot of
different elements which can be used as extended font sources. It avoids
the problematic question of defining precise source requirements for
the "preferred form of modification" when there are various ways of
modifying and building a font: "preferred" for who exactly? A very
strict source requirement would alienate the vast majority of designers
we want to see joining our community!
Font Software is broadly defined in the license:
"Font Software" refers to the set of files released by the Copyright
Holder(s) under this license and clearly marked as such. This may
include source files, build scripts and documentation.
So the OFL model intentionally doesn't place strict requirements on
releasing these extended sources needed for a full build but at the same
time it *makes it possible and strongly encourages* (via the FAQ) the
author choosing this model to release everything that can be useful to
designers: data files, glyph databases, smart code, build scripts,
documentation and rendering samples.
See FAQ entry 2.6, 4.1, 4.2 and 7
http://scripts.sil.org/OFL-FAQ_web
So the idea is to recommend releasing as much extended source as
possible and turning that into best practises but *not making it
mandatory* which would result in a participation barrier.
The FAQ has more details and, as you probably know, there is a
foo-open-font-sources VCS template with all kind of different elements
to encourage release of as much source as possible:
http://svn.debian.org/wsvn/pkg-fonts/foo-open-font-sources/?rev=0&sc=0
BTW, your feedback on this is still welcome, it's intended as a
cross-distro, cross-OS recommendation.
And if you really don't want any kind of anti-collision / name
protection features the OFL does not require you to reserve a name:
FAQ entries 2.11 and 2.12 have more on this.
I agree with you that the GPL (even with the current font exception) has
various problems. If it worked perfectly for fonts everybody would be
using it... It needs fixing.
I'd recommend also investigating how to distribute your build scripts
separately under a "full-source-required" license (documentation on the
requirements of the build environment would be very useful too).
Alternatively you could work with the ones interested in an absolute
full source requirement model for all recipients (with corresponding
source redistribution offer) to create the licensing model you like and
then organise community review.
I do understand the packager's perspective of ideally having a
self-contained autobuilding source rpm for each open font family, but
the reality is that this rarely the case at this stage. We have also
seen that as fontforge and related tools make progress, automatic
building from sources does introduce regressions. (IMHO most packagers
don't have the experience to fully compare between a font build done by
the designer himself and an automated build).
Thankfully there are various efforts going in this direction, but let's
not get ahead of ourselves. A fully automated build would be nice to
have but we're not going to drop from our distros all open fonts not yet
providing such a build path, that would be rather silly.
HTH,
--
Nicolas Spalinger, NRSI volunteer
Debian/Ubuntu font team / OpenFontLibrary
http://planet.open-fonts.org
11:53 a.m.
New subject: Help with licensing questions
Nicolas (S),
Thanks for your contribution to the thread! More below.
On Sat, Feb 14, 2009 at 3:51 PM, Nicolas Spalinger <
nicolas_spalinger(a)sil.org> wrote:
The OFL doesn't refuse to admit that font sources exist - rather
the
contrary - it acknowledges the fact that beyond the binary font files
themselves, which you can already do something with, there are a lot of
different elements which can be used as extended font sources. It avoids
the problematic question of defining precise source requirements for
the "preferred form of modification" when there are various ways of
modifying and building a font: "preferred" for who exactly? A very
strict source requirement would alienate the vast majority of designers
we want to see joining our community!
I agree that the question of sources is very tricky, and probably for the
majority of fonts, it doesn't make sense. In that sense, I think the OFL is
a realistic license.
So the OFL model intentionally doesn't place strict requirements
on
releasing these extended sources needed for a full build but at the same
time it *makes it possible and strongly encourages* (via the FAQ) the
author choosing this model to release everything that can be useful to
designers: data files, glyph databases, smart code, build scripts,
documentation and rendering samples.
However, in the case that I actually have sources (and more than just build
scripts), I want those to be protected in the sense that modification of
those sources must also be redistributed along with the corresponding
modified font. I don't see that the OFL would require this, and so I don't
see the OFL as the right license for the sources.
Best wishes,
Stephen
3:38 a.m.
New subject: Help with licensing questions
Le Dim 15 février 2009 18:53, Stephen Hartke a écrit :
I agree that the question of sources is very tricky, and probably
for
the majority of fonts, it doesn't make sense.
This is complete confusion.
You don't see people argue scripts or interpreted python/perl/whatever
files can't be (L)GPL-ed because there is not separate source files do
you?
IMHO one of the great OFL failures was not acknowledging font files
can be their own sources when upstream edits them directly, and
perpetuating the « sources are strange dangerous stuff » urban myth.
Regards,
--
Nicolas Mailhot
3:24 a.m.
New subject: Help with licensing questions
Le Sam 14 février 2009 22:51, Nicolas Spalinger a écrit :
[...]
Oh, my little flamebait had its intended effect :p
> Now, I do agree one of the OFL's main weakness is its refusal
to
> admit
> fonts may have sources (the other being the way it considers you
> want
> your font renamed instead of making it an option), but the GPL has
> other problems (embedding).
Hi Stephen and Nicolas,
Hi all,
Very interesting thread indeed, some crucial points have been
explained
very clearly but I have to disagree with the little analysis snippet
above... (BTW, Nicolas, IIRC we already had conversations about this
wrt. the buildpath of Old Standard).
The OFL doesn't refuse to admit that font sources exist - rather the
contrary - it acknowledges the fact that beyond the binary font files
themselves, which you can already do something with, there are a lot
of
different elements which can be used as extended font sources. It
avoids
the problematic question of defining precise source requirements
This is what I mislike. « Avoiding » is not tackling problems, it's
hoping someone else will solve them for you (and someone else usually
doesn't).
for
the "preferred form of modification" when there are various ways of
modifying and building a font: "preferred" for who exactly?
Clearly, « preferred » for the upstreams of a release.
The basic objective of the GPL is to level the playing field and make
sure downstreams get their hands on the same source files upstreams
prefer to use. Maybe it could be rewritten in less software-oriented
speak but the basic requirement is very necessary for a sane
ecosystem.
A very
strict source requirement would alienate the vast majority of
designers we want to see joining our community!
You're trading short-term wins for long-term problems. I'm quite sure
the TEX people though lax licensing checks would be a win too.
IMHO Stephen's answers show not being clear on it is confusing to OFL
users.
Font Software is broadly defined in the license:
"Font Software" refers to the set of files released by the Copyright
Holder(s) under this license and clearly marked as such. This may
include source files, build scripts and documentation.
Which is a lax definition and pretty unlikely to result in source
releases for designers who do not understand the FLOSS yet.
So the OFL model intentionally doesn't place strict requirements
on
releasing these extended sources needed for a full build but at the
same
time it *makes it possible and strongly encourages* (via the FAQ) the
author choosing this model to release everything that can be useful to
designers: data files, glyph databases, smart code, build scripts,
documentation and rendering samples.
See FAQ entry 2.6, 4.1, 4.2 and 7
http://scripts.sil.org/OFL-FAQ_web
Not that FAQs are not good, I wrote a few of them myself, but it's
hard enough to have authors properly read the license text they use
without relying on external documents.
So the idea is to recommend releasing as much extended source as
possible and turning that into best practises but *not making it
mandatory* which would result in a participation barrier.
The FAQ has more details and, as you probably know, there is a
foo-open-font-sources VCS template with all kind of different elements
to encourage release of as much source as possible:
http://svn.debian.org/wsvn/pkg-fonts/foo-open-font-sources/?rev=0&sc=0
BTW, your feedback on this is still welcome, it's intended as a
cross-distro, cross-OS recommendation.
I must admit I still find it overly complex and too oriented towards
SIL tools and workflows. A simplified version for « normal »
fontforge-based FLOSS projects would do a lot more good IMHO.
I sort of hoped the Senecca font packaging project proposal would
result in someone giving a fresh eye to it but I was probably overly
ambitious.
And if you really don't want any kind of anti-collision / name
protection features the OFL does not require you to reserve a name:
FAQ entries 2.11 and 2.12 have more on this.
It's still not very clear and confusing both upstreams and
downstreams. It should be clearly stated that no name is reserved
unless stated explicitely in the license file bundled with the font
files.
I agree with you that the GPL (even with the current font exception)
has
various problems. If it worked perfectly for fonts everybody would be
using it... It needs fixing.
Really, SIL and FSF lawyers need to be walled in a room with only hard
bread and clear water till they can hash a satisfying FLOSS font
license :p The OFL is marginally better for fonts but has its own
problems.
I'm no lawyer, and not a native English speaker, but I don't find the
current licenses very satisfying.
[...]
I do understand the packager's perspective of ideally having a
self-contained autobuilding source rpm for each open font family, but
the reality is that this rarely the case at this stage.
It will only improve by trying to make it so.
We have also
seen that as fontforge and related tools make progress, automatic
building from sources does introduce regressions. (IMHO most packagers
don't have the experience to fully compare between a font build done
by the designer himself and an automated build).
IMHO the tools to do it are missing but they'll keep missing till
distros actually start regularly building fonts from sources and
expose the tooling needs. The years of doing nothing and hoping the
problem would solve itself didn't result in lots of advances.
If you want good floss fonts, you'll have to accept the failures with
the successes. If you refuse the failures you don't move at all.
Thankfully there are various efforts going in this direction, but
let's
not get ahead of ourselves. A fully automated build would be nice to
have but we're not going to drop from our distros all open fonts not
yet providing such a build path, that would be rather silly.
Not a requirement yet. But yet can be quite short-lived depending on
the pace of your distribution.
--
Nicolas Mailhot
11:47 a.m.
New subject: Help with licensing questions
Nicolas (M),
Thanks for your response to my email! More below.
On Thu, Feb 12, 2009 at 9:51 AM, Nicolas Mailhot
<nicolas.mailhot(a)gmail.com>wrote:
Basically, I don't think the format of your font should drive
your
licensing decisions. If the GPL is appropriate for the metatype
version it's appropriate for the OTF version. Just "it looks more like
software as usual" is a weak reason.
I think that the license of my font _should_ be driven by the format, or,
more specifically, by the information that is being released and reused for
making a derivative work.
Releasing MetaType1 sources under the GPL and the OTF file under the OFL
seems to accomplish exactly what I want:
If someone makes a derivative font by modifying the sources and distributes
it, then I want them to be required to distribute their modified sources,
just as the GPL requires. It doesn't seem to me that the OFL would require
this.
If however someone modifies the OTF file directly using FontForge, then
using the GPL is rather nonsensical since there is no source. In that case,
the OFL seems to be the perfect license.
I don't see how either license by itself accomplishes my goals. Licensing
the sources under the GPL (with font embedding exception) and the OTF file
under the OFL seems a reasonable compromise that accomplishes what I want.
Best wishes,
Stephen
3:38 a.m.
New subject: Help with licensing questions
Le Dim 15 février 2009 18:47, Stephen Hartke a écrit :
Nicolas (M),
Hi Stephen,
Thanks for your response to my email! More below.
Responses are free here :)
On Thu, Feb 12, 2009 at 9:51 AM, Nicolas Mailhot
<nicolas.mailhot(a)gmail.com>wrote:
> Basically, I don't think the format of your font should drive your
> licensing decisions. If the GPL is appropriate for the metatype
> version it's appropriate for the OTF version. Just "it looks more
> like
> software as usual" is a weak reason.
>
I think that the license of my font _should_ be driven by the format,
or,
more specifically, by the information that is being released and
reused for
making a derivative work.
Releasing MetaType1 sources under the GPL and the OTF file under the
OFL seems to accomplish exactly what I want:
Please consider that you are the only one who can do this, and any
downstream that will use your GPL sources will have no choice but to
have the produced fonts under the GPL too.
Which won't be embeddable if you forget the right clause.
-1 for the GPL
*This* is why I wrote your licensing decisions should not be driven by
your (source) format. Your downstreams do not have the luxury to
re-licence when they need to change the font format, they'll have to
use the same license as the sources they work from, so any licensing
model that is adherent to the produced format is broken by design.
If someone makes a derivative font by modifying the sources and
distributes
it, then I want them to be required to distribute their modified
sources,
just as the GPL requires. It doesn't seem to me that the OFL would
require this.
Well, I disagree with Nicolas S. the OFL is satisfying here :p
If however someone modifies the OTF file directly using FontForge,
then using the GPL is rather nonsensical since there is no source.
That is arguing only binary compiled files can be (L)GPLed, when the
evidence is lots of interpreted files authors are happy with this
license for their perl/python/js/shell scripts.
In that case, the OFL seems to be the perfect license.
Not really :(
BTW, had the source and build scripts been clearly identified as
necessary from the start on, they'd be mirrored today in all the
distros shipping your fonts and would not have been lost :(
-1 for the OFL.
Sincerely,
--
Nicolas Mailhot
7:36 p.m.
New subject: Help with licensing questions
2009/2/15 Stephen Hartke <hartke(a)gmail.com>:
I think that the license of my font _should_ be driven by the format,
It seems that when the format "source files" of a font are "source
code" then this triggers an automatic, hypnotic, response to use the
GPL.
However, licensing is really a political choice, not a technical one;
which is to say, license choices are driven by politics.
IMHO, AIUI, the OFL is intended for designers who don't want to deal
with the complexity of the GPL and are new to free software; but if
you are convinced that sources ought to be available and your font
ought to always remain free, and you don't mind providing sources,
then the OFL seems a strange choice to me. You get the ability to
remix the font with other OFL fonts, but I'm not sure how useful that
is in practice.
If someone makes a derivative font by modifying the sources and
distributes
it, then I want them to be required to distribute their modified sources,
just as the GPL requires. It doesn't seem to me that the OFL would require
this.
OFL doesn't require sources, it just recommends them.
This means OFL fonts can be proprietorised; for example, they can be
pushed through a program like superpolator.com (proprietary Mac OS X
tool) to extend them, but the interpolation masters are not required
to be distributed with the font, nor are formats required to be
transparent/freely available. GPLv3 fixes these problems.
If however someone modifies the OTF file directly using FontForge,
then
using the GPL is rather nonsensical since there is no source. In that case,
the OFL seems to be the perfect license.
I don't see how either license by itself accomplishes my goals.
Dual licensing is not very good for downstream users, because they
fork the project when a downstream only uses one of the licenses.
I think GPL+FontException (and a contact details so you can be
contacted when a better "Font GPL" is prepared) is the best thing for
this project.
--
Regards,
Dave
5540
days inactive
5545
days old
8 comments
4 participants
participants (4)
-
Dave Crossland -
Nicolas Mailhot -
Nicolas Spalinger -
Stephen Hartke