I maintain the easyrpg-player package [0]. Recently, it had a v0.7.0 release [1]. As it often happens, this release added some new dependencies.
One of those is the "ttyp0" font [2], which uses its own, custom license. Reading through, it seems to me that it's basically MIT with one extra clause:
If the design of any glyphs in the fonts that are contained in the Software or generated during the installation process is modified or if additional glyphs are added to the fonts, the fonts must be renamed. The new names may not contain the word "UW", irrespective of capitalisation; the new names may contain the word "ttyp0", irrespective of capitalisation, only if preceded by a foundry name different from "UW".
I'm posting here because I'd like to confirm that the license is OK with Fedora.
A.FI.
[0] https://src.fedoraproject.org/rpms/easyrpg-player [1] https://github.com/EasyRPG/Player/releases/tag/0.7.0 [2] https://people.mpi-inf.mpg.de/~uwe/misc/uw-ttyp0/
On Wed, Nov 3, 2021 at 8:10 AM Artur Frenszek-Iwicki suve@fedoraproject.org wrote:
I'm posting here because I'd like to confirm that the license is OK with Fedora.
I have added this to the list[1] of Good Font licenses. You can use "MIT" as the identifier, as it's now on the list of MIT variants[2].
[1] https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses_4 [2] https://fedoraproject.org/wiki/Licensing:MIT#ttyp0_variant
On Thu, Nov 11, 2021 at 11:48 AM Ben Cotton bcotton@redhat.com wrote:
On Wed, Nov 3, 2021 at 8:10 AM Artur Frenszek-Iwicki suve@fedoraproject.org wrote:
I'm posting here because I'd like to confirm that the license is OK with Fedora.
I have added this to the list[1] of Good Font licenses. You can use "MIT" as the identifier, as it's now on the list of MIT variants[2].
[1] https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses_4 [2] https://fedoraproject.org/wiki/Licensing:MIT#ttyp0_variant
Sorry, I meant to reply to this earlier.
I am not sure if this should be acceptable for Fedora. My concern is that the "UW" naming prohibition is unreasonably restrictive. Does anyone have thoughts on this?
Richard
On Thu, Nov 11, 2021 at 11:53 AM Richard Fontana rfontana@redhat.com wrote:
I am not sure if this should be acceptable for Fedora. My concern is that the "UW" naming prohibition is unreasonably restrictive. Does anyone have thoughts on this?
I read it as being similar to section 6 of ASL 2.0:
- Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.
On Thu, Nov 11, 2021 at 11:59 AM Ben Cotton bcotton@redhat.com wrote:
On Thu, Nov 11, 2021 at 11:53 AM Richard Fontana rfontana@redhat.com wrote:
I am not sure if this should be acceptable for Fedora. My concern is that the "UW" naming prohibition is unreasonably restrictive. Does anyone have thoughts on this?
I read it as being similar to section 6 of ASL 2.0:
- Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.
But this would be like the Apache License saying "derivative works can't have the consecutive letters 'AP' in their name". I'm not sure at what point such a restriction becomes problematic from a FLOSS standpoint but for example if it were one letter, like "U", that would obviously not be okay. Two letters doesn't seem too different.
The closest parallel I'm aware of might be the PHP license, which Fedora (following the FSF's view) treats as free but GPL-incompatible. The main reason for the GPL incompatibility, I believe, is this naming restriction:
"Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"".
Maybe that's the right call, as we've been assuming, but I wonder if a two-letter sequence restriction goes too far.
It could be that the traditional view has been that any arbitrarily restrictive renaming provision is okay from a libre standpoint. I'm not sure why that should be correct though.
Richard
On Thu, Nov 11, 2021 at 12:16 PM Richard Fontana rfontana@redhat.com wrote:
But this would be like the Apache License saying "derivative works can't have the consecutive letters 'AP' in their name".
I disagree. First "uw" is how the foundry is identified. The Apache Software Foundation doesn't use "AP" to identify itself, as far as I've seen. Second, the word "word" is meaningful here. If the University of Washington, as an example, used "UWash-ttyp0" as the name, that wouldn't violate the restriction. In other words, it's not that the letters u and w appear consecutively, but they're used as a word.
It could be that the traditional view has been that any arbitrarily restrictive renaming provision is okay from a libre standpoint. I'm not sure why that should be correct though.
I'm not sure this is a well-explored area, but I think authors have a fundamental right to disclaim association with derivative works. Just as a license can require attribution, we should be able to require dis-attribution (for lack of a better term). So I'm inclined to accept most "you can make derivatives so long as you don't try to make it sound like it's from or endorsed by me" scenarios. Where I'd draw the line is more arbitrary restrictions. Like if GNOME had a license that restricted calling a derivative work "dwarf" because Merriam-Webster says they're synonyms. But saying "you can't call it 'GNOME-ish'" would be acceptable because it uses the word "GNOME".
I'm not entirely sure that one-letter words are automatically out of bounds. I think there's some room for context. Like if I make a font called "c-font" that's part of a larger ecosystem of "c-*" packages, I think it's reasonable to say "you can't use 'c' alone in your derivative work" ("bc" would be fine, but "remade-c" wouldn't). On the other hand, if "c-font" is the only "c-" name package, then I agree that it's arbitrarily restrictive.
I hope this makes sense. It's a philosophy I've not hitherto given a lot of explicit thought, so the explanation is probably a bit rough. Maybe it'll be a conference proposal at some point?
On Thu, Nov 11, 2021 at 12:48 PM Ben Cotton bcotton@redhat.com wrote:
On Thu, Nov 11, 2021 at 12:16 PM Richard Fontana rfontana@redhat.com wrote:
But this would be like the Apache License saying "derivative works can't have the consecutive letters 'AP' in their name".
I disagree. First "uw" is how the foundry is identified. The Apache Software Foundation doesn't use "AP" to identify itself, as far as I've seen. Second, the word "word" is meaningful here. If the University of Washington, as an example, used "UWash-ttyp0" as the name, that wouldn't violate the restriction. In other words, it's not that the letters u and w appear consecutively, but they're used as a word.
But that implies that a word can't contain another word, I think?
"UWash" for example I would argue contains a number of words ("ash", "wash", "as", "a", for starters). Unless "word" has a special domain-specific meaning in the world of font foundry names (does it?) it is not clear to me that this developer would agree that "UWash" does not violate the restriction.
It could be that the traditional view has been that any arbitrarily restrictive renaming provision is okay from a libre standpoint. I'm not sure why that should be correct though.
I'm not sure this is a well-explored area, but I think authors have a fundamental right to disclaim association with derivative works. Just as a license can require attribution, we should be able to require dis-attribution (for lack of a better term). So I'm inclined to accept most "you can make derivatives so long as you don't try to make it sound like it's from or endorsed by me" scenarios. Where I'd draw the line is more arbitrary restrictions. Like if GNOME had a license that restricted calling a derivative work "dwarf" because Merriam-Webster says they're synonyms. But saying "you can't call it 'GNOME-ish'" would be acceptable because it uses the word "GNOME".
I'm not entirely sure that one-letter words are automatically out of bounds. I think there's some room for context. Like if I make a font called "c-font" that's part of a larger ecosystem of "c-*" packages, I think it's reasonable to say "you can't use 'c' alone in your derivative work" ("bc" would be fine, but "remade-c" wouldn't). On the other hand, if "c-font" is the only "c-" name package, then I agree that it's arbitrarily restrictive.
So then maybe the question is what does "word" mean in this license? If it has the narrow meaning that you are assuming, then maybe it is okay. I'm not sure.
Worth noting also, in FLOSS historically some restrictions have been tolerated in font licenses that weren't considered libre in software licenses. This is probably one of the reasons why Fedora, for example, has a separate category for acceptable font licenses. (Example: SIL OFL vs. SunRPC.) But that's not especially for some sort of admirable reason. It's because the community chose to "look the other way" out of a strong desire to see sort-of-free-ish fonts get released, as Dave Crossland explained to me a long time ago.
Richard
On Thu, Nov 11, 2021 at 1:51 PM Richard Fontana rfontana@redhat.com wrote:
But that implies that a word can't contain another word, I think?
Now we're having fun!
"UWash" for example I would argue contains a number of words ("ash", "wash", "as", "a", for starters). Unless "word" has a special domain-specific meaning in the world of font foundry names (does it?) it is not clear to me that this developer would agree that "UWash" does not violate the restriction.
The most reasonable interpretation in my view is that the context matters. So a word that is a variation of the form would be the same "word" for the purposes of the licence. For example, "ash" and "ashen". But if it's a string that happens to appear in another, unrelated word, they are separate words. For example, "ash" and "wash". In my original example, the fact that "UWash" is a name the University of Washington uses supports the "it's not the same word" argument. If I were to name a font "uwash-ttyp0", the "they're separate words" case is weaker, but not a slam dunk.
I don't think you're arguing against the general concept (e.g. ASL 2.0 section 6), so the question is really "what's the minimum length?" If General Electric released software under ASL 2.0 (replacing "Apache" with "General Electric"), section 6 would preclude using "GE" in the name of a derivative as that is a trademark of General Electric. So I think we have to be okay with two-letter names if we're okay with ASL, don't we? Similarly, calling a derivative work "stoneage", while it contains the consecutive letters "g" and "e", seems obviously acceptable under ASL 2.0 section 6.
I understand the philosophical issue with restricting renaming generally. But I think if we go down that road, that represents a significant policy shift from our past practice.
On Thu, Nov 11, 2021 at 2:59 PM Ben Cotton bcotton@redhat.com wrote:
On Thu, Nov 11, 2021 at 1:51 PM Richard Fontana rfontana@redhat.com wrote:
But that implies that a word can't contain another word, I think?
Now we're having fun!
"UWash" for example I would argue contains a number of words ("ash", "wash", "as", "a", for starters). Unless "word" has a special domain-specific meaning in the world of font foundry names (does it?) it is not clear to me that this developer would agree that "UWash" does not violate the restriction.
The most reasonable interpretation in my view is that the context matters. So a word that is a variation of the form would be the same "word" for the purposes of the licence. For example, "ash" and "ashen". But if it's a string that happens to appear in another, unrelated word, they are separate words. For example, "ash" and "wash". In my original example, the fact that "UWash" is a name the University of Washington uses supports the "it's not the same word" argument. If I were to name a font "uwash-ttyp0", the "they're separate words" case is weaker, but not a slam dunk.
I don't think you're arguing against the general concept (e.g. ASL 2.0 section 6), so the question is really "what's the minimum length?" If General Electric released software under ASL 2.0 (replacing "Apache" with "General Electric"), section 6 would preclude using "GE" in the name of a derivative as that is a trademark of General Electric. So I think we have to be okay with two-letter names if we're okay with ASL, don't we? Similarly, calling a derivative work "stoneage", while it contains the consecutive letters "g" and "e", seems obviously acceptable under ASL 2.0 section 6.
I understand the philosophical issue with restricting renaming generally. But I think if we go down that road, that represents a significant policy shift from our past practice.
OK, well I withdraw my objections to treating this as an acceptable Fedora license for fonts. I reserve the right to complain about a similar future non-font-oriented license. :-)
Richard
On 11/11/21 9:35 PM, Richard Fontana wrote:
On Thu, Nov 11, 2021 at 2:59 PM Ben Cotton bcotton@redhat.com wrote:
On Thu, Nov 11, 2021 at 1:51 PM Richard Fontana rfontana@redhat.com wrote:
But that implies that a word can't contain another word, I think?
Now we're having fun!
"UWash" for example I would argue contains a number of words ("ash", "wash", "as", "a", for starters). Unless "word" has a special domain-specific meaning in the world of font foundry names (does it?) it is not clear to me that this developer would agree that "UWash" does not violate the restriction.
The most reasonable interpretation in my view is that the context matters. So a word that is a variation of the form would be the same "word" for the purposes of the licence. For example, "ash" and "ashen". But if it's a string that happens to appear in another, unrelated word, they are separate words. For example, "ash" and "wash". In my original example, the fact that "UWash" is a name the University of Washington uses supports the "it's not the same word" argument. If I were to name a font "uwash-ttyp0", the "they're separate words" case is weaker, but not a slam dunk.
I don't think you're arguing against the general concept (e.g. ASL 2.0 section 6), so the question is really "what's the minimum length?" If General Electric released software under ASL 2.0 (replacing "Apache" with "General Electric"), section 6 would preclude using "GE" in the name of a derivative as that is a trademark of General Electric. So I think we have to be okay with two-letter names if we're okay with ASL, don't we? Similarly, calling a derivative work "stoneage", while it contains the consecutive letters "g" and "e", seems obviously acceptable under ASL 2.0 section 6.
I understand the philosophical issue with restricting renaming generally. But I think if we go down that road, that represents a significant policy shift from our past practice.
OK, well I withdraw my objections to treating this as an acceptable Fedora license for fonts. I reserve the right to complain about a similar future non-font-oriented license. :-)
Since you both are having so much fun... here's my two cents ;)
I agree this is ok for Fedora, but I also understand Richard's initial hesitation re: the naming issue.
I think the distinction is that - the clause in Apache 2.0 is explicitly consistent with trademark law. - whereas, this license sort of goes a step further and gives instructions on how to change the name enough to avoid a "likelihood of confusion" for the consumer (the standard for trademark infringement)
Stating you must rename a modified version (or derivative work) is pretty common, but generally still considered free/open as it is merely reflecting the reality of trademark law (at least that's they way I think of it).
Explaining how to rename it - goes a step further, which could be seen as too far, but in this case, it seems pretty reasonable.
I think the line gets crossed (and may be where Richard is reserving his right to complain) when a license actually requires the use of a specific name in a specific scenario, so-called "badgeware" licenses. Pam Chestek did a great talk on this at FOSDEM 2014, if anyone is interested :) https://archive.fosdem.org/2014/schedule/event/trademark_licenses/
Cheers, Jilayne
On Fri, Nov 12, 2021 at 11:52 AM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 11/11/21 9:35 PM, Richard Fontana wrote:
On Thu, Nov 11, 2021 at 2:59 PM Ben Cotton bcotton@redhat.com wrote:
I understand the philosophical issue with restricting renaming generally. But I think if we go down that road, that represents a significant policy shift from our past practice.
OK, well I withdraw my objections to treating this as an acceptable Fedora license for fonts. I reserve the right to complain about a similar future non-font-oriented license. :-)
Since you both are having so much fun... here's my two cents ;)
I agree this is ok for Fedora, but I also understand Richard's initial hesitation re: the naming issue.
I think the distinction is that
- the clause in Apache 2.0 is explicitly consistent with trademark law.
- whereas, this license sort of goes a step further and gives
instructions on how to change the name enough to avoid a "likelihood of confusion" for the consumer (the standard for trademark infringement)
Stating you must rename a modified version (or derivative work) is pretty common, but generally still considered free/open as it is merely reflecting the reality of trademark law (at least that's they way I think of it).
As I see it, there are plausibly-FLOSS licenses that attempt to contractualize/non-trademark-intellectual-property-license-ize policy concerns that have been traditionally associated with trademark law. This is not categorically problematic. For example the OSD says "The license may require derived works to carry a different name or version number from the original software" and broadly speaking that seems to be a correct distillation of how the community has looked at this issue. But the question for me is how far or how much further can such a license provision go than what we assume is the background trademark law default for there to be a concern that the license is now too restrictive to be considered free/open source. I don't believe there is *no* such point at which a line is crossed.
I think what makes me accept this license with some misgivings is (a) Ben's interpretation which is narrower than the one I initially had, and (b) it's a font license and there's a mostly unacknowledged lower standard applied to font licenses. So if this same provision appeared in a software license I am not sure it should be acceptable.
Richard
On Thu, Nov 11, 2021 at 12:48:22PM -0500, Ben Cotton wrote:
restricted calling a derivative work "dwarf" because Merriam-Webster says they're synonyms. But saying "you can't call it 'GNOME-ish'" would be acceptable because it uses the word "GNOME".
Ooh. I was with you right up until this example. To me, "GNOME-ish" means "reminiscent of GNOME but not GNOME", which seems like the kind of thing that _should_ be allowed. GNOME-erific or GNOME-improved or even GNOME-fork, yeah, I see. But I'd hate to see open source licenses getting into "that big foot-race that happens to be in capital of Massachusetts every year" or "I guess we'll just all say Superb Owl" territory.
Richard Fontana rfontana@redhat.com writes:
I am not sure if this should be acceptable for Fedora. My concern is that the "UW" naming prohibition is unreasonably restrictive. Does anyone have thoughts on this?
Naming can be difficult, but I believe we've long accepted clauses forcing renaming. A license saying "don't use our name in your new name" seems reasonable even if your name is just a few letters (like "IBM" or "UW"). It is technically restricting a freedom but not in any way that seems meaningful.
Where I think it gets sticky is if a license were to prevent renaming, or maybe to specify the name to be used for modified versions. A more difficult corner case would be something like "must not start with the letter 'a'" or "must sort higher alphabetically".
- J<
-
Artur Frenszek-Iwicki -
Ben Cotton -
Jason L Tibbitts III -
Jilayne Lovejoy -
Matthew Miller -
Richard Fontana