Nicolas, Karl, and Victor,<br><br>Thanks for responding to my message!&nbsp; I&#39;m leaving for a conference in an hour, so I don&#39;t have much time to reply.&nbsp; However, I would like to give my initial thoughts.<br><br>First, let me explain the two main sources of my objection to the OFL. The first is that my font Aurulent Sans is made primarily with MetaType1 scripts, with some gluing and polishing with FontForge scripts. No direct or graphical editing of the splines is done. Thus, to me it feels very much like software: I have source code that I compile to produce an object file (the font file). As it currently stands, if I release the font under the OFL and someone modifies the scripts and releases a derivative font, they are not required to also release the modified scripts. Maybe a solution is to release the source code under the GPL and the font file under the OFL, though I&#39;m not sure this can legally be done (as the GPL usually refers to the whole program).
<br><br>The second source is my attempt to modify Charis SIL to include Greek.&nbsp; I agree with Victor that there is very little difference in appearance of quadratic and cubic splines. However, I think that there is a huge expressive difference when editing.&nbsp; I personally prefer to use cubic splines when editing. It&#39;s trivial to convert Charis SIL from quadratic to cubic splines, but the _original_ cubic splines are not recovered.&nbsp; For instance, I highly doubt that the lowercase Latin o is designed with 32 on-curve points.&nbsp; It&#39;s much easier to edit the spline if there are fewer points, but to recover that simpler form requires deciding to eliminate some points. Perhaps there is an automatic way to recover the original cubic splines from quadratic splines if it&#39;s known that the quadratic splines were converted from cubic splines, but I do not know of any program that does this. However, my point is not that this _could_ be done, but that it shouldn&#39;t need to be done (for a FLOSS font). It feels to me too much like disassembling object code and guessing what the source code looked like.
<br><br>I think there is a fine line for what &quot;source material&quot; (in a broad sense) should be required by a FLOSS license.&nbsp; The GPL defines &quot;source code&quot; as &quot;the preferred form of the work
for making modifications to it&quot;. However, this has ambiguity: If I embed tables of data in my C source code, do I need to release the scripts that generated the data?&nbsp; Do I need to keep the comments in my source code that explain what is going on? 
<br><br>I think that Nicolas&#39;s point about encouraging the release of everything that was used to generate the final product is quite salient, and this culture is certainly present in most FLOSS communities centered around GPL projects (and so they release more than the GPL technically requires). However, the GPL does require that everything is released needed to generate, install, run, and modify the work. Thus, the legal contract tries to capture the spirit of the culture above.&nbsp; The OFL, however, does not have any stipulation (however weak) to release any of the material used to produce the font.
<br><br>I don&#39;t think that the OFL is a bad license, and I&#39;m happy that designers are releasing fonts under the OFL rather than not at all.&nbsp; I understand Victor&#39;s point that the OFL is better than the legalistic GPL for designers unfamiliar with the FLOSS world. However, it still feels to me that it&#39;s missing an essential component---Victor&#39;s examples of OpenType features and hinting are even better example that I hadn&#39;t even thought about yet.
<br><br>More below.<br><br><div class="gmail_quote">On Jan 5, 2008 6:48 AM, Victor Gaultney &lt;<a href="mailto:vtype@gaultney.org">vtype@gaultney.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">&gt; For example, the nice Charis SIL is released under the OFL by SIL in TTF<br>&gt; format with quadratic curves. Internally, SIL works on the font as cubic<br>&gt; splines. They even request that patches be submitted as cubic splines!
<br>&gt; However, when I contacted them, they refused to release the cubic curves that<br>&gt; they internally use to produce the font.<br><br></div>I don&#39;t think that&#39;s a complete and fair statement, but I will publicly
<br>apologize to you for having your most recent request in my inbox for far far<br>too long.<br></blockquote><div><br>I apologize if I misrepresented the situation.&nbsp; Our email correspondence had left me with the impression that you would not release the cubic splines, not that it would just take awhile.&nbsp; I can understand that things often take a lot of time (see how long it&#39;s been since I&#39;ve made a font release!). This question is out of curiousity, and not to be snarky: Why do you request that patches be submitted in cubic form, if it is so easy to convert from quadratics?
<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>&gt; For this reason, I am planning my future font releases (those created solely
<br>&gt; by me) under the GPL+font exception.<br><br></div>As I mentioned before, I think that option has some problems, and I<br>certainly wouldn&#39;t recommend it. If we felt it was an adequate solution<br>there would be no need for the OFL. :-)
<br></blockquote></div><br>I agree that the GPL+exception has some problems, mainly because the GPL was designed for software.&nbsp; However, as I described above, my method of creating fonts is much closer to creating software than I think it is for many other designers.&nbsp; I am unhappy about the fact that future derivatives can discard the font embedding exception.
<br><br>Thanks for your messages!&nbsp; I am finding this discussion to be quite illuminating.<br><br>Best wishes,<br>Stephen<br><br>