Re: OFL license analysis
Mark Rafn [EMAIL PROTECTED] wrote: Mark Rafn [EMAIL PROTECTED] wrote: This discussion seems to have gone into the weeds about WHY someone would want to make a change and whether Debian is able to make such changes reasonably. On Mon, 30 Jan 2006, Frank Küster wrote: Well, only in part. A font that you can't rely on is mostly useless... I assume the you in this sentence is a hapless user of a system whose software she does not control/understand, not the person wishing to make and distribute changes to the font. Correct me if this is an incorrect reading. ACK. A license that tries to protect a user from an incompetent developer/distributor/sysadmin is going to be non-free. There's really no way around this. The only way to be free is to allow a true fork of the software, which means a dropin replacement, even if the licensor disapproves. Most existing forks *do* identify themselves as being something different. What ever happenened to the LaTex license, by the way? That had the same non-freeness. You seem to have a different opinion on this as the debian-legal people who negotiated with the LaTeX project and together developped the LPPL version 1.3. In this version, the requirement to change file names (or LaTeX package names) was dropped, probably because it was regarded as too non-free, whereas it was decided that any changed version should indicate that it was changed in the version string that is (or to some degree only will be) part of the API. Hmm. I claim that it is a mistake for Debian to consider something free if it requires binary incompatibility to distribute a modified version. Version strings are a funny edge-case, where if they're normally just human-readable information with no programmatic effect I can live with it, but when it becomes common to programmatically read them and behave differently, then it's part of the API and must be modifiable (or not) without restriction. The revised LPPL says: a. If a component of this Derived Work can be a direct replacement for a component of the Work when that component is used with the Base Interpreter, then, wherever this component of the Work identifies itself to the user when used interactively with that Base Interpreter, the replacement component of this Derived Work clearly and unambiguously identifies itself as a modified version of this component to the user when used interactively with that Base Interpreter In practice, this means that the version string displayed in the file log of a LaTeX run will be different, and that the user, or a developer of a package that uses the work, has the possibility to check for the version and act accordingly; it does of course not mean that he must do such a check. It's possible that Debian made a mistake if that's what LaTeX does with these strings. Wouldn't be the first time. I guess before we continue discussing this, we both should look up in the archives the discussion that has taken place between the LaTeX team and Debian people. It seems a clear test: if I can't distribute a changed version that can be dropped into a system without changing other software, it ain't free. You can never distribute a bugfixed version of a font with the same name (identifiers, ...) and, without changing other software, get the same system behavior. That's not a question of freeness, it's a technical problem. No, the intent is to get DIFFERENT system behavior by changing the free component, without changing other software or documents. That's the freedom I'm worried about here. Though the ability to get the same behavior is there too (perhaps a performance fix or other result-compatible implementation change), it's just a special case of the real freedom to make changes. I know, the freedom to shoot yourself into the foot. But I think it's not unreasonable to require that the user is at least notified what happened, and that can only be done by changing the identifier in an interactive dialog, or by issuing font substitution warnings in a batch run. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: OFL license analysis
On Tue, 31 Jan 2006, Frank Küster wrote: In practice, this means that the version string displayed in the file log of a LaTeX run will be different, and that the user, or a developer of a package that uses the work, has the possibility to check for the version and act accordingly; it does of course not mean that he must do such a check. Ok, that seems reasonable to me. Much like the human-readable version info when running a program with -v or whatnot. A human can tell the difference if he bothers to look. System software does not change behavior based on this human identification. I know, the freedom to shoot yourself into the foot. But I think it's not unreasonable to require that the user is at least notified what happened, and that can only be done by changing the identifier in an interactive dialog, or by issuing font substitution warnings in a batch run. I think our disagreement is that you think the licensor may require the software to actively notify some user, where I think the licensor may require that it be identifiable if the recipient of the software package cares to look for such identification. Is this a fair summary? I can see no way to force notification in most systems that does not interfere with the fundamental freedom to make changes. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: OFL license analysis
Frank Küster [EMAIL PROTECTED] wrote: In practice, this means that the version string displayed in the file log of a LaTeX run will be different, and that the user, or a developer of a package that uses the work, has the possibility to check for the version and act accordingly; it does of course not mean that he must do such a check. Also note that due to the way TeX works this can, in principle, be done even without that. If you think your document should only be processed with an unchanged version of foo.sty, you can look at every macro provided *and*used*internally* by foo.sty and check whether it has been changed. Having the version number available is just more convenient... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: OFL license analysis
On Tue, Jan 31, 2006 at 01:15:06AM -0800, Mark Rafn wrote: A human can tell the difference if he bothers to look. System software does not change behavior based on this human identification. Well, it might: if the software uses the human identification to select which font to use when rendering a document, it's no longer merely human identification--it's functional, too. That raises an odd (tangental) question, though. What if third-party software scanned output intended for the user; for example, refusing to run or changing behavior if the name of the software it prints isn't foo? Now it's impossible to make a functional drop-in equivalent without identifying differently. Same problem with any number of things required under the assumption that they're not functional: you could scan strings output for (c) Glenn Maynard if you don't like my code, or refuse to run if the GPL blurb is detected if you want to hinder GPL software. In practice, the only reasonable approach is probably intent. It's pretty clear that font licensors actually do want to prohibit me from modifying a font, distributing it, and having it drop-in over the original. That's a non-free goal. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OFL license analysis
Mark Rafn [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Debian decides to distribute works containing your font. The original upstream disappears. A bug is discovered in the font, and Debian needs to fix it. On Sun, 29 Jan 2006, Marco d'Itri wrote: Yes, and this is considered a feature. Usually existing documents should not break because a font is changed, even if this fixes a bug. On Sun, 29 Jan 2006, Don Armstrong wrote: The same argument applies equally well to programs. We should be intelligent enough in our fixing of bugs in fonts not to break existing documents, That's plain impossible. A bug in a font could be a wrong kerning. Kerning means the hints in the fonts that indicate that in a particular combination of letters, two adjacent letters need less (or more) space between them than their size would dictate. For example the letters VA must be shifted a little towards each other, otherwise it will look nearly like a whitespace between them. If there is such a bug in a font, changing it implies that the word-wrapping algorithm has a high chance of finding a different solution, and thus change existing documents. There's simply no solution that allows both for stable docments and for bug fixing. The lmodern fonts, for example, are still under development, and they warn the user and reserve themselves the option to change things like the kerning. But if you've got a font that is in wide use and regarded as stable, changing the kerning is a design decision and should in fact change the name under which the font is available to the user and to documents. just like we should be intelligent enough in our fixing of bugs in programs not to break existing scripts. This discussion seems to have gone into the weeds about WHY someone would want to make a change and whether Debian is able to make such changes reasonably. Well, only in part. A font that you can't rely on is mostly useless... Name-change requirements are acceptible (barely) on the package name, but not API identifiers, and that includes filenames that are part of an API. [...] What ever happenened to the LaTex license, by the way? That had the same non-freeness. You seem to have a different opinion on this as the debian-legal people who negotiated with the LaTeX project and together developped the LPPL version 1.3. In this version, the requirement to change file names (or LaTeX package names) was dropped, probably because it was regarded as too non-free, whereas it was decided that any changed version should indicate that it was changed in the version string that is (or to some degree only will be) part of the API. It seems a clear test: if I can't distribute a changed version that can be dropped into a system without changing other software, it ain't free. You can never distribute a bugfixed version of a font with the same name (identifiers, ...) and, without changing other software, get the same system behavior. That's not a question of freeness, it's a technical problem. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: OFL license analysis
On Mon, 30 Jan 2006, Frank Küster wrote: On Sun, 29 Jan 2006, Don Armstrong wrote: The same argument applies equally well to programs. We should be intelligent enough in our fixing of bugs in fonts not to break existing documents, That's plain impossible. A bug in a font could be a wrong kerning. [...] There's simply no solution that allows both for stable docments and for bug fixing. There are clearly some classes of bugs which entail breaking compatibility with existing programs or existing documents. To whit: [When we're not, we have the ability to determine which is the proper course of action: breaking compatibility or living with the bug.] [1] if you've got a font that is in wide use and regarded as stable, changing the kerning is a design decision and should in fact change the name under which the font is available to the user and to documents. This exact argument can be made to apply to programs. We as distributors (or our users as users) should be able to make the determination whether it's appropriate to break compatibility to fix the bug, or keep compatibility and live with the bug. A license really has no business forcing technical decisions like that on us or our users. We've allowed a very narrow compromise to require that the name of the work itself (or its version) change, but that's it; a requirement that other parts of the work change beyond its name goes beyond DFSG §4. Don Armstrong 1: [EMAIL PROTECTED] -- Frankly, if ignoring inane opinions and noisy people and not flaming them to crisp is bad behaviour, I have not yet achieved a state of nirvana. -- Manoj Srivastava in [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu
Re: OFL license analysis
Don Armstrong [EMAIL PROTECTED] wrote: This exact argument can be made to apply to programs. We as distributors (or our users as users) should be able to make the determination whether it's appropriate to break compatibility to fix the bug, or keep compatibility and live with the bug. A license really has no business forcing technical decisions like that on us or our users. We've allowed a very narrow compromise to require that the name of the work itself (or its version) change, but that's it; a requirement that other parts of the work change beyond its name goes beyond DFSG §4. Well, in a sense every font file (the standard version, the italic, bold, small caps, etc versions) is a work of its own, and the complete distribution is only an aggregate work. For commercial fonts it is common that you buy each separately. Anyway: would, in your opinion, a restriction be acceptable to change either the version or, as long as there's no technical solution yet that includes this version in the API, the font name? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: OFL license analysis
On Mon, 30 Jan 2006 02:25:34 -0800 Don Armstrong wrote: On Mon, 30 Jan 2006, Frank Küster wrote: [...] if you've got a font that is in wide use and regarded as stable, changing the kerning is a design decision and should in fact change the name under which the font is available to the user and to documents. This exact argument can be made to apply to programs. We as distributors (or our users as users) should be able to make the determination whether it's appropriate to break compatibility to fix the bug, or keep compatibility and live with the bug. A license really has no business forcing technical decisions like that on us or our users. We've allowed a very narrow compromise to require that the name of the work itself (or its version) change, but that's it; a requirement that other parts of the work change beyond its name goes beyond DFSG §4. Exactly! Agreed entirely. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpv1K1YwTbhz.pgp Description: PGP signature
Re: OFL license analysis
Mark Rafn [EMAIL PROTECTED] wrote: This discussion seems to have gone into the weeds about WHY someone would want to make a change and whether Debian is able to make such changes reasonably. On Mon, 30 Jan 2006, Frank Küster wrote: Well, only in part. A font that you can't rely on is mostly useless... I assume the you in this sentence is a hapless user of a system whose software she does not control/understand, not the person wishing to make and distribute changes to the font. Correct me if this is an incorrect reading. A license that tries to protect a user from an incompetent developer/distributor/sysadmin is going to be non-free. There's really no way around this. The only way to be free is to allow a true fork of the software, which means a dropin replacement, even if the licensor disapproves. What ever happenened to the LaTex license, by the way? That had the same non-freeness. You seem to have a different opinion on this as the debian-legal people who negotiated with the LaTeX project and together developped the LPPL version 1.3. In this version, the requirement to change file names (or LaTeX package names) was dropped, probably because it was regarded as too non-free, whereas it was decided that any changed version should indicate that it was changed in the version string that is (or to some degree only will be) part of the API. Hmm. I claim that it is a mistake for Debian to consider something free if it requires binary incompatibility to distribute a modified version. Version strings are a funny edge-case, where if they're normally just human-readable information with no programmatic effect I can live with it, but when it becomes common to programmatically read them and behave differently, then it's part of the API and must be modifiable (or not) without restriction. It's possible that Debian made a mistake if that's what LaTeX does with these strings. Wouldn't be the first time. It seems a clear test: if I can't distribute a changed version that can be dropped into a system without changing other software, it ain't free. You can never distribute a bugfixed version of a font with the same name (identifiers, ...) and, without changing other software, get the same system behavior. That's not a question of freeness, it's a technical problem. No, the intent is to get DIFFERENT system behavior by changing the free component, without changing other software or documents. That's the freedom I'm worried about here. Though the ability to get the same behavior is there too (perhaps a performance fix or other result-compatible implementation change), it's just a special case of the real freedom to make changes. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: OFL license analysis
[EMAIL PROTECTED] wrote: Anyway, as you can see there is basically one problematic clause for inclusion in Debian, and a few other minor issues that should probably be resolved before font authors start using this license. Are you sure the naming clause is really that problematic for inclusion in Debian? I see no reason to believe that DFSG #4 forbids such a clause. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OFL license analysis
[EMAIL PROTECTED] wrote: What you're trying to prevent is clear, it's just not necessary to use a license to do this. Consider the following: Debian decides to distribute works containing your font. The original upstream disappears. A bug is discovered in the font, and Debian needs to fix it. We can no longer distribute a fixed version of the font that interoperates seamlessly with existing user's documents because we're required to change the name of the font. Yes, and this is considered a feature. Usually existing documents should not break because a font is changed, even if this fixes a bug. In the case where we introduce a change that breaks the end-user documents, end-users are (hopefully) intelligent enough to realize that they've gotten a version that is broken, and go about tracking down the version that they actually want. You cannot install at the same time two fonts with the same name, and anyway you should not force users to do this. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OFL license analysis
On Sun, 29 Jan 2006, Marco d'Itri wrote: [EMAIL PROTECTED] wrote: Debian decides to distribute works containing your font. The original upstream disappears. A bug is discovered in the font, and Debian needs to fix it. Yes, and this is considered a feature. Usually existing documents should not break because a font is changed, even if this fixes a bug. The same argument applies equally well to programs. We should be intelligent enough in our fixing of bugs in fonts not to break existing documents, just like we should be intelligent enough in our fixing of bugs in programs not to break existing scripts. We've proven in the past to be quite capable of doing that, at least in most cases. [When we're not, we have the ability to determine which is the proper course of action: breaking compatibility or living with the bug.] In the case where we introduce a change that breaks the end-user documents, end-users are (hopefully) intelligent enough to realize that they've gotten a version that is broken, and go about tracking down the version that they actually want. You cannot install at the same time two fonts with the same name, and anyway you should not force users to do this. You can't install two programs with the same name either. [Before anyone bothers to tell me about $PATH, the same argument applies to fonts as well.] In any event, we're not just talking about the mere renaming of a file that DFSG #4 allows; the clause in question goes much farther than that. Don Armstrong -- DIE! -- Maritza Campos http://www.crfh.net/d/20020601.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OFL license analysis
[EMAIL PROTECTED] wrote: Debian decides to distribute works containing your font. The original upstream disappears. A bug is discovered in the font, and Debian needs to fix it. On Sun, 29 Jan 2006, Marco d'Itri wrote: Yes, and this is considered a feature. Usually existing documents should not break because a font is changed, even if this fixes a bug. On Sun, 29 Jan 2006, Don Armstrong wrote: The same argument applies equally well to programs. We should be intelligent enough in our fixing of bugs in fonts not to break existing documents, just like we should be intelligent enough in our fixing of bugs in programs not to break existing scripts. This discussion seems to have gone into the weeds about WHY someone would want to make a change and whether Debian is able to make such changes reasonably. It doesn't matter to the free-ness of a package licensed this way whether Debian can or will be a good citizen. If I can't make any changes I like, including nasty, stupid, ugly breakages, and distribute the result, it's non-free. Name-change requirements are acceptible (barely) on the package name, but not API identifiers, and that includes filenames that are part of an API. It seems a clear test: if I can't distribute a changed version that can be dropped into a system without changing other software, it ain't free. What ever happenened to the LaTex license, by the way? That had the same non-freeness. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OFL license analysis
On Sun, Jan 29, 2006 at 04:04:44PM -0800, Mark Rafn wrote: It seems a clear test: if I can't distribute a changed version that can be dropped into a system without changing other software, it ain't free. I'd take this just a little further, in that the user shouldn't have to change his behavior, either. Filenames are part of the interface to the user, when they're binaries in the path (or symlinks to them, eg. alternatives). I seem to recall some renaming clauses that said don't name the binary 'foo', which went too far. (It's always a danger sign when licenses start talking at so technical a level as to mention things like filenames at all.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OFL license analysis
[snip] First off; while I am a Debian Developer, and do have some experience in auditing licenses for DFSG compliance, I can't make any claims one way or another as to whether software licensed under such a license will be acceptable for inclusion in main (main being the part of the Debian archive where software that is actually a part of the Debian distribution is kept; contrib and non-free are distributed by Debian, but are not part of the distribution. All works in main are believed to satisfy the DFSG.) That responsibility lies with the ftp-masters, a group of Debian Developers who are responsible for the content of the archive. Hi Don, Thanks for your feedback on the Open Font License. Permission is hereby granted, free of charge, to any person obtaining a copy of the Font Software, to use, study, copy, merge, embed, modify, redistribute, and sell modified and unmodified copies of the Font Software, subject to the following conditions: 1) Neither the Font Software nor any of its individual components, in Standard or Modified Versions, may be sold by itself. This is likely to be DFSG free, as anyone can trivially bundle the font with something else that can be sold and sell it. However, adding this sort of clause to the license, especially in light of the clause above, where we are granted Permission [..] to [...] sell modified and unmodified copies of the font software. This dissonance is rather peculiar. This small restriction is needed for cultural reasons within the typography community but is designed to be easily circumventable to allow wide packaging and distribution so Debian and other distros can include the fonts in offline or online repositories. It's really no different than the terms used for the Vera font family which have been deemed DFSG-free, included in main and used by default for some time now. It satisfies the requirements of DFSG #1. 3) No Modified Version of the Font Software may use the Reserved Font Name(s), in part or in whole, unless explicit written permission is granted by the Copyright Holder. This restriction applies to all references stored in the Font Software, such as the font menu name and other font description fields, which are used to differentiate the font from others. Limited naming restrictions are permitted by DFSG §4. However, the naming restriction above is significantly more broad than the naming restriction that DFSG §4 was written to allow. (Earlier versions of the LaTeX Project Public License required renaming the filenames of modified versions so that they wouldn't conflict; that restriction has since been removed.) As such, it's likely that this clause will restrict the inclusion of works which have Reserved Font Names in Debian. This restriction only concerns the name of the font as it appears in a font menu and not the actual names of the files like in the older LPPL requirement you are referring to. The goal of the OFL is to avoid naming conflicts so that documents actually render as expected but it doesn't impose any of the special requirements of the Latex License. Here's what OFL FAQ entry 2.8 says: Users who install derivatives (Modified Versions) on their systems should not see any of the original names (Reserved Font Names) in their font menus, font properties dialogs, PostScript streams, documents that refer to a particular font name, etc. Again, this is to ensure that users are not confused and do not mistake a font for another and so expect features only another derivative or the Standard Version can actually offer. Ultimately, creating name conflicts will cause many problems for the users as well as for the designer of both the Standard and derivative versions, so please think ahead and find a good name for your own derivative. Font substitution systems like fontconfig, OpenOffice.org or Scribus will also get very confused if the name of the font they are configured to substitute to actually refers to another physical font on the user's hard drive. It will help everyone if Standard and derivative fonts can easily be distinguished from one another, and from other derivatives. Basically, it's about keeping the namespace sane while allowing branching and merging for font designers and - more importantly - avoiding a big messy breakage of end-user documents. Beyond the mere DFSG Freeness issues of this clause, it also has a few practical problems, as in part or in whole appears to preclude the use of any part of the font name in a derivative version. [Taken to an insane extreme, if the font was named 'abc', a derivative 'bad' would contain the name in part, thus violating the license.] Nathanael Nerode pointed this out as well in the discussion on debian-legal in December.[1] Yes, this is an area of possible ambiguity - indeed an extreme case - that we're looking at clarifying in future refinements of the
Re: OFL license analysis
On Sat, 28 Jan 2006, Nicolas Spalinger wrote: Permission is hereby granted, free of charge, to any person obtaining a copy of the Font Software, to use, study, copy, merge, embed, modify, redistribute, and sell modified and unmodified copies of the Font Software, subject to the following conditions: 1) Neither the Font Software nor any of its individual components, in Standard or Modified Versions, may be sold by itself. This is likely to be DFSG free, as anyone can trivially bundle the font with something else that can be sold and sell it. However, adding this sort of clause to the license, especially in light of the clause above, where we are granted Permission [..] to [...] sell modified and unmodified copies of the font software. This dissonance is rather peculiar. This small restriction is needed for cultural reasons within the typography community but is designed to be easily circumventable to allow wide packaging and distribution so Debian and other distros can include the fonts in offline or online repositories. It's really no different than the terms used for the Vera font family which have been deemed DFSG-free, included in main and used by default for some time now. It satisfies the requirements of DFSG #1. The DFSG freeness of the clause isn't the point of my comment; the point was that the restriction was almost useless, as it could be bundled with a README file and then sold. From this is seems clear that the typography community isn't too interested in restricting their work's sale, which is why I questioned the clause's inclusion on general grounds. Furthermore, it also conflicts with the language immediately preceeding this clause, where we are granted Permission [..] to [...] sell modified and unmodified copies of the font software, as we aren't actually allowed to sell them. 3) No Modified Version of the Font Software may use the Reserved Font Name(s), in part or in whole, unless explicit written permission is granted by the Copyright Holder. This restriction applies to all references stored in the Font Software, such as the font menu name and other font description fields, which are used to differentiate the font from others. Limited naming restrictions are permitted by DFSG §4. However, the naming restriction above is significantly more broad than the naming restriction that DFSG §4 was written to allow. [...] As such, it's likely that this clause will restrict the inclusion of works which have Reserved Font Names in Debian. This restriction only concerns the name of the font as it appears in a font menu and not the actual names of the files [...]. The goal of the OFL is to avoid naming conflicts so that documents actually render as expected but it doesn't impose any of the special requirements of the Latex License. That may be the intent, but the way the clause is written makes it read as I have indicated, as the filenames of the fonts themselves are references stored in the Font Software; indeed any mention of the Reserved Font Name(s) in part or in whole in the Font Software appears to be verboten by this clause. Here's what OFL FAQ entry 2.8 says: [...] The OFL FAQ explains the intentions of the drafter of the license; unfortunatly, the drafters of the OFL are not necessarily the copyright holders who will be enforcing the licence. As such, the FAQ is basically useless in terms of -legal's analysis of works under such a license. Basically, it's about keeping the namespace sane while allowing branching and merging for font designers and - more importantly - avoiding a big messy breakage of end-user documents. What you're trying to prevent is clear, it's just not necessary to use a license to do this. Consider the following: Debian decides to distribute works containing your font. The original upstream disappears. A bug is discovered in the font, and Debian needs to fix it. We can no longer distribute a fixed version of the font that interoperates seamlessly with existing user's documents because we're required to change the name of the font. In the case where we introduce a change that breaks the end-user documents, end-users are (hopefully) intelligent enough to realize that they've gotten a version that is broken, and go about tracking down the version that they actually want. Beyond the mere DFSG Freeness issues of this clause, it also has a few practical problems, as in part or in whole appears to preclude the use of any part of the font name in a derivative version. [Taken to an insane extreme, if the font was named 'abc', a derivative 'bad' would contain the name in part, thus violating the license.] Nathanael Nerode pointed this out as well in the discussion on debian-legal in December.[1] Yes, this is an area of possible ambiguity - indeed an extreme case - that we're looking at clarifying in
Re: OFL license analysis
On Sat, Jan 28, 2006 at 09:35:33PM +0100, Nicolas Spalinger wrote: 3) No Modified Version of the Font Software may use the Reserved Font Name(s), in part or in whole, unless explicit written permission is granted by the Copyright Holder. This restriction applies to all references stored in the Font Software, such as the font menu name and other font description fields, which are used to differentiate the font from others. Limited naming restrictions are permitted by DFSG §4. However, the naming restriction above is significantly more broad than the naming restriction that DFSG §4 was written to allow. (Earlier versions of the LaTeX Project Public License required renaming the filenames of modified versions so that they wouldn't conflict; that restriction has since been removed.) As such, it's likely that this clause will restrict the inclusion of works which have Reserved Font Names in Debian. This restriction only concerns the name of the font as it appears in a font menu and not the actual names of the files like in the older LPPL requirement you are referring to. The goal of the OFL is to avoid naming conflicts so that documents actually render as expected That's impossible to accomplish in a copyright license. I can take a completely unrelated font, rename it to your font name, and release it. Your copyright license can do nothing, since the font I'm using is not under that license. It takes a trademark to do this; copyright is ill-suited for it. (But, copyright licenses are free to try--within reasonable limits.) Users who install derivatives (Modified Versions) on their systems should not see any of the original names (Reserved Font Names) in their font menus, font properties dialogs, PostScript streams, documents that refer to a particular font name, etc. Again, this is to ensure that Font metadata might list similar fonts, to show in a dialog Fonts that look similar to This license prohibits this, since it says I can't use the original name *at all* in the derived version. It might also have metadata that says if you need a glyph that isn't present here, try getting it from the font named The license also prohibits this. (This isn't contrived; I've implemented a simple bitmap font system that did this.) I believe restricting these things is beyond what DFSG#4 allows. The in part is really meant to cover the case when there are various words used in reserved font names. If Foo and Org are both are RFN for the font Foo Org, any designer can branch and create his derivative but calling it Bar Org or Foo Inc is not allowed. The unit to consider here is the word and not the letter. If a font name is Times Roman, I can't create a derivative named Glenn Roman; worse, if it's Times New Roman, I can't name it Glenn's New Font? Again, trademark handles this much more gracefully, since it already has well-established mechanisms in place for determining things like confusingly similar. Trying to replicate this in a copyright license really isn't going to work. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
