<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"
	>
<channel>
	<title>Comments on: The Effects of Weak Copyleft</title>
	<atom:link href="http://understandinglimited.com/2008/09/01/ofl-eot-doomsday-scenario/feed/" rel="self" type="application/rss+xml" />
	<link>http://understandinglimited.com/2008/09/01/ofl-eot-doomsday-scenario/</link>
	<description>design &#38; software freedom</description>
	<lastBuildDate>Sun, 07 Mar 2010 12:19:18 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: yosch</title>
		<link>http://understandinglimited.com/2008/09/01/ofl-eot-doomsday-scenario/comment-page-1/#comment-14759</link>
		<dc:creator>yosch</dc:creator>
		<pubDate>Tue, 02 Sep 2008 10:17:27 +0000</pubDate>
		<guid isPermaLink="false">http://understandinglimited.com/?p=496#comment-14759</guid>
		<description>&lt;p&gt;Well, what you call a danger, many would call a welcome clarification feature. Exploring &quot;stronger copyleft&quot; models still faces a number of issues...&lt;/p&gt;

&lt;p&gt;I seems to me there are a few misunderstandings here on which your scenarios are constructed... Maybe I don&#039;t understand what you&#039;re trying to say (or your thought experiment) but I don&#039;t see how you go from 
    &quot;The requirement for fonts to remain under the OFL does not apply to any document created using the fonts and their derivatives.&quot; 
to &quot;if the fonts do not remain under the OFL...&quot;&lt;/p&gt;

&lt;p&gt;Also PDF extraction and the use of DRM or opaque formats is outside the scope of the OFL.&lt;/p&gt;

&lt;p&gt;The purpose of the clause you quote (and its corresponding FAQ item) is to make it clear that while the font and its sources stay under the same licensing - which means branches inherit that licensing and sources/patches can flow freely between the various branches and the trunk - any document or outline made from that open font can have any license you want and that license may change. In short, using an open font does not influence the license and distribution rights of your document.&lt;/p&gt;

&lt;p&gt;And really no software license should influence the output! I seriously doubt that you&#039;d accept a text editor forcing you to publish everything you wrote/typed with it under a particular license only. This would really be going too far. (See the definition of output in the GPL itself and also the earlier yacc problems).&lt;/p&gt;

&lt;p&gt;Not a lot of licenses make that explicitly clear but it&#039;s really needed for the font-specific environment. IMHO the nexus lies between allowing embedding but clarifying what the status of the embedded document is.&lt;/p&gt;

&lt;p&gt;In your example, the Lady.pdf document containing an embedded version of a derivative of Gentleman  is still just a document, and not really the font source of a derivative. I remember George Williams indicating on the fontforge user list that only some outlines can be retrieved from a pdf anyways, I doubt retrieving the smart code is doable. (But reusing glyphs you&#039;d want to respect the licensing model chosen by the author).&lt;/p&gt;

&lt;p&gt;Also AFAICT the proposed EOT format restrictions are linked to a domain and not a document as such...&lt;/p&gt;

&lt;p&gt;As for not being able to integrate derivatives back into your trunk, I&#039;d say that the OFL model encourages releasing of as much useful source as possible but does not make it a requirement. Some branches you will get the source back whereas others may choose not to.&lt;/p&gt;

&lt;p&gt;BTW, we&#039;re working on a update to the OFL FAQ concerning webfonts / font linking. I can send you the ideas we&#039;re looking at.&lt;/p&gt;

&lt;p&gt;There are probably things we can do to make it easier for open fonts to be used by @font-face user agents...&lt;/p&gt;

&lt;p&gt;@John Hudson&lt;/p&gt;

&lt;p&gt;AFAICT Dave&#039;s exploring stronger copyleft models in the context of open fonts, and while the MIT/X11/Expat is a brilliant license, it really goes in the opposite direction.&lt;/p&gt;

&lt;p&gt;BTW thanks for releasing your impressive work on Hebrew smarts :-)  (Ezra is now available on Debian and Ubuntu among other platforms: http://packages.debian.org/sid/ttf-sil-ezra http://packages.ubuntu.com/intrepid/ttf-sil-ezra)&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Well, what you call a danger, many would call a welcome clarification feature. Exploring &#8220;stronger copyleft&#8221; models still faces a number of issues&#8230;</p>
<p>I seems to me there are a few misunderstandings here on which your scenarios are constructed&#8230; Maybe I don&#8217;t understand what you&#8217;re trying to say (or your thought experiment) but I don&#8217;t see how you go from<br />
    &#8220;The requirement for fonts to remain under the OFL does not apply to any document created using the fonts and their derivatives.&#8221;<br />
to &#8220;if the fonts do not remain under the OFL&#8230;&#8221;</p>
<p>Also PDF extraction and the use of DRM or opaque formats is outside the scope of the OFL.</p>
<p>The purpose of the clause you quote (and its corresponding FAQ item) is to make it clear that while the font and its sources stay under the same licensing - which means branches inherit that licensing and sources/patches can flow freely between the various branches and the trunk - any document or outline made from that open font can have any license you want and that license may change. In short, using an open font does not influence the license and distribution rights of your document.</p>
<p>And really no software license should influence the output! I seriously doubt that you&#8217;d accept a text editor forcing you to publish everything you wrote/typed with it under a particular license only. This would really be going too far. (See the definition of output in the GPL itself and also the earlier yacc problems).</p>
<p>Not a lot of licenses make that explicitly clear but it&#8217;s really needed for the font-specific environment. IMHO the nexus lies between allowing embedding but clarifying what the status of the embedded document is.</p>
<p>In your example, the Lady.pdf document containing an embedded version of a derivative of Gentleman  is still just a document, and not really the font source of a derivative. I remember George Williams indicating on the fontforge user list that only some outlines can be retrieved from a pdf anyways, I doubt retrieving the smart code is doable. (But reusing glyphs you&#8217;d want to respect the licensing model chosen by the author).</p>
<p>Also AFAICT the proposed EOT format restrictions are linked to a domain and not a document as such&#8230;</p>
<p>As for not being able to integrate derivatives back into your trunk, I&#8217;d say that the OFL model encourages releasing of as much useful source as possible but does not make it a requirement. Some branches you will get the source back whereas others may choose not to.</p>
<p>BTW, we&#8217;re working on a update to the OFL FAQ concerning webfonts / font linking. I can send you the ideas we&#8217;re looking at.</p>
<p>There are probably things we can do to make it easier for open fonts to be used by @font-face user agents&#8230;</p>
<p>@John Hudson</p>
<p>AFAICT Dave&#8217;s exploring stronger copyleft models in the context of open fonts, and while the MIT/X11/Expat is a brilliant license, it really goes in the opposite direction.</p>
<p>BTW thanks for releasing your impressive work on Hebrew smarts :-)  (Ezra is now available on Debian and Ubuntu among other platforms: <a href="http://packages.debian.org/sid/ttf-sil-ezra" rel="nofollow">http://packages.debian.org/sid/ttf-sil-ezra</a> <a href="http://packages.ubuntu.com/intrepid/ttf-sil-ezra)" rel="nofollow">http://packages.ubuntu.com/intrepid/ttf-sil-ezra)</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Hudson</title>
		<link>http://understandinglimited.com/2008/09/01/ofl-eot-doomsday-scenario/comment-page-1/#comment-14757</link>
		<dc:creator>John Hudson</dc:creator>
		<pubDate>Tue, 02 Sep 2008 02:46:16 +0000</pubDate>
		<guid isPermaLink="false">http://understandinglimited.com/?p=496#comment-14757</guid>
		<description>&lt;p&gt;I&#039;m not going to comment on the legality, under the license, but it seems to me that open source implies access to a font independent of extracting it from a document. What is important seems to me that access be available, not that every means of getting at a font should be equally open.&lt;/p&gt;

&lt;p&gt;Last year, I came at this issue from the other side: Ralph Hancock and I found the OFL license too restrictive because we didn&#039;t want to limit use of our Biblical Hebrew layout intelligence to open source projects. So we opted for the MIT license. SIL releases some fonts with derivative layout under OFL, which of course they are free to do according to the terms of our MIT license. What this means is that people have different rights to the data depending on what source they use for it. So long as the less restrictive of two sources is available, the existence of more restrictive sources doesn&#039;t seem to me a problem.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I&#8217;m not going to comment on the legality, under the license, but it seems to me that open source implies access to a font independent of extracting it from a document. What is important seems to me that access be available, not that every means of getting at a font should be equally open.</p>
<p>Last year, I came at this issue from the other side: Ralph Hancock and I found the OFL license too restrictive because we didn&#8217;t want to limit use of our Biblical Hebrew layout intelligence to open source projects. So we opted for the MIT license. SIL releases some fonts with derivative layout under OFL, which of course they are free to do according to the terms of our MIT license. What this means is that people have different rights to the data depending on what source they use for it. So long as the less restrictive of two sources is available, the existence of more restrictive sources doesn&#8217;t seem to me a problem.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
