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 _______________________________________________ Fedora-fonts-list mailing list Fedora-fonts-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-fonts-list
