Re: Added RFN-violation bug template to wiki
On Tue, Mar 20, 2018 at 9:55 PM, Dave Crossland wrote:
> I would say, projects with a single copyright holder.
That covers fonts produced and tinkered about with by a hobbyist on
their own time. RFNs don't seem appropriate in that situation to me,
unless the hobbyist is really precious about their work perhaps.
> I have advocated for years to avoid them in general, because the copyleft in
> the license incentivizes upstream contribution aka forming a community; this
> is also incentivized by GitHub style version control development.
Are you referring to the OFL here or other copyleft licenses like the
GNU GPL? Personally, I prefer GNU GPL plus font exception for font
licensing. Definitely agree with the raw statements except I would
drop the word GitHub from there, the trend towards
me want to quit working on FLOSS altogether.
>> * leave the RFN out of the source
> If this can be rephrased as "use a codename instead of the rfn in source"
> then I like it, but in your example below then one if the reserved names is
> kept, so I'm confused about what you mean here; do you mean, leave it out of
> the copyright notice? If so I can't imagine that flying with anyone who
> intentionally applied an rfn, because then anyone could derive from source
> without the rfn obligation....
I mean leave the RFN out of the source as much as possible, including
the font name, copyright, everything. Of course, the foundry/designer
will be the copyright holder so the foundry/designer name will be
present but the juxtaposition of "foundry/designer fontname" (eg SIL
Gentium), which is usually how the RFN is composed, will not be
>> * leave the designer/foundry name out of the font name in the source
> I generally require this for Google Fonts anyway, and even deny initials,
> with a few exceptions for sil and Paratype (pt sans) etc, although I may end
> up renaming them if the upstream ceases development.
Is Google distributing binary fonts built by SIL/Paratype or have
SIL/Paratype given Google an exception to their RFN clauses? If not,
this sounds like a license violation.
>> * add a note to the source encouraging people to rename for major forks
> Always good to do :)
Not sure I would agree with this in the general case, forks that are
really just a continuation of the same project should just use the
same name. I would only change a font name when doing a fork that
completely changes the style of the font.
> Aliasing has to be done in fontconfig; I believe Debian font packages can
> supply a fontconfig rule, if so then yes
Ok, that part of the proposal isn't really feasible then, since it
doesn't work outside operating systems that use fontconfig.