>> I see that the copyright notice says, "Copyright 2011 Red Hat, Inc., >> with Reserved Font Name OVERPASS." >> >> Anyone serving the fonts as web fonts under the OFL will need >> additional permission to distribute it with the RFN because >> modifications are required in order to convert formats for wide >> browser compatibility, offer subsets to reduce latency, and so on. My time is limited but I feel I need to contribute to this thread: I personally think this is a blanket statement which minimizes the complexity of the issues and conveniently ignores a lot of the thinking behind the Reserved Font Names features which is an integral part of the OFL model. This topic deserve more attention and careful analysis. Consider some of the following goals that designers have: - Avoiding collisions - it greatly reduces the likelihood that a Modified Version would get confused with the Original Version, whether by an end user, someone bundling the font into a separate app or collection, or an application attempting to render a document that specifies a particular font. - Protecting authors - it requires any font that bears the RFNs to retain the functionality and quality of the Original Version which protects the author's reputation - Minimizing support - it enables authors to adequately support their fonts without the burden of troubleshooting fonts bearing the same name that might have been poorly modified. - Encouraging derivatives - it encourages separately-named branches to exist and be properly identified so that new, interesting enhancements can get reviewed and eventually merged back into the main project. It's quite understandable that the perspective of a commercial webfont hosting service is that they want full control, with a plentiful supply of fonts but whithout having to deal with the designer's requirements too much... Please don't assume this perspective is the one everyone shares :-D I suspect many designers and copyright holders probably think differently and the RFN mechanism exists to give them more choice and control. It's one of their bargaining advantages. The RFN mechanism is what provides designers with enough trust to relinquish modification rights to their creation and to allow other modified versions to exist as long as they don't thread upon the master, the canonical version, the original. Getting rid of that trust is no easy matter. Should speed-related optimizations or subsetting really come at the price of a big number of derivative fonts colliding with the canonical version and increasing the support burden of the authors and sponsoring organisation? How would designers feel when they receive complaints that plenty of broken webfonts called Overpass or Lohit $something appear on website but don't work as expected? One person's convenience is another person's loss of value. IMHO the option of sending those improvements back to master, back to the original author instead of just forking them for webfonts is a solution that should not be ignored. (I thought Fedora has the brilliant approach of upstream first ?) Also some target formats have inherent limitations that do not capture the full coverage and smart behaviours of the original font and so even with the best intentions it creates a derivative that can't be on par with the original (.i.e SVG). I think that having a lot of fonts which are "similar but not quite entirely unlike" the original is rather #disturbing. >> The Apache license doesn't have such requirements. >> Therefore I personally suggest removing the RFN notice. >> >> If 'Overpass' is considered a valuable Red Hat trademark, I'd >> personally suggest declaring trademark notices alongside copyright >> notices for both licenses. > > That may make good sense; let me think about this. I'd recommend the perspective of designers are also taken into account in this discussion and not just the perspective of hosting services. Looking at the Overpass git repository, I notice that various fonts in webfont formats "optimized" by fontsquirrel are currently stored in a Webfonts/ folder. Having the original author prepare the webfonts format directly to control how they are optimized without going through such separate service is probably a much better idea. Beyond what such "optimisation" does to the original font, there are also changes to the metadata done to mangle the font name so that the font is uninstallable and adds this restriction notice: "This is a protected webfont and is intended for CSS @font-face use ONLY. Reverse engineering this font is strictly prohibited." This restriction goes against the spirit and purpose of open fonts (in breach of the OFL's mild copyleft) and is quite revealling of a process that is geared towards restricted fonts that are probably optimized against their original author's desires. IMHO probably not what the font author and Redhat as a sponsor of such an open font have in mind... Not reserving any names is certainly an option thas is built into the OFL but you have to be fully aware of the advantages you are choosing to give up and the consequences this will have. > Essentially I think you are saying that the 'Reserved Font Name' > feature of the SIL OFL is a flaw in practice. AFAICT it seems Dave Crossland's position on this has fluctuated. From the article about the OFL's features in Libre Graphics Magazine 1.4 to the commissioning policies of Google Web Fonts... SIL is currently writing a paper on the topic of Reserved Font Names and the webfont optimization processes and we intend to have a future update of the OFL FAQ reflect that. >> Personally I don't like Apache for fonts, so I wonder if you might >> explain about the thinking behind using both licenses. > > The reason to continue using SIL OFL is, well, because we've been > using it (before I joined Red Hat nearly 5 years ago Fedora had > already declared OFL its recommended font license). And indeed we > rejoiced in the opportunity to use it in certain cases, Lohit fonts > and Liberation Fonts 2.0. The latter license change was something I > personally regarded as a 'liberation', if you will. It is too soon to > question the legitimacy of such rejoicing. However: > > The developer in question, not being previously familiar with the SIL > OFL, read it and stumbled across the "you may not sell these fonts by > themselves" clause. He realized the awful truth (although he didn't > put it this way): there is no way to reconcile SIL OFL being "free" > and the principle, established by such matters as SunRPC, that a "you > may not sell this material in isolation" clause is nonfree for a > software license, unless you either come to an understanding that the > free software world applies a double standard when it comes to fonts > vs. software, or you adopt the FSF's "hello world" conceptual trick, > which I am not entirely comfortable with given that we don't seem to > have any clear understanding that SIL or the body of SIL licensors > would see the 'hello world' trick as compliant with the OFL. Reading through the OFL FAQ (along with previous public discussion on the topic) should help make it clear that what can be seen as the OFL "hello world" trick is actually a feature of the license and not a bug. We have been in discussion with the FSF on this and we agree with their views on this and how they present the license on their list of approved licenses. The not-selling-by-itself clause is social signalling that you can easily circumvent but that makes a useful point to people who receive the bundle while still being compliant with FSF values and the OSD. I haven't seen any Libre Software projects reject Vera/Dejavu/etc because of such a clause. Why should it be different now? BTW, I notice that Cantarell still has discrepancies in its licensing metadata. (pointed out earlier http://lists.fedoraproject.org/pipermail/fonts/2010-November/001276.html) The usual disclaimers: TINLA, IANAL -- Nicolas Spalinger _______________________________________________ fonts mailing list fonts@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/fonts http://fonts.fedoraproject.org/
