3:24 a.m.
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