Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove RFN #1

Closed
davelab6 opened this issue Feb 3, 2016 · 5 comments
Closed

Remove RFN #1

davelab6 opened this issue Feb 3, 2016 · 5 comments

Comments

@davelab6
Copy link
Contributor

davelab6 commented Feb 3, 2016

https://github.com/simoncozens/silson/blob/master/LICENSE#L2

Please don't use RFNs on Github, it makes forking and modifying the fonts infringing; it also means web font users must rename the fonts if they subset them, which sucks

@n7s
Copy link

n7s commented Feb 3, 2016

I suggest reading through the FAQ and the Web Fonts and Reserved Font Names paper to make your own decision with all the facts and rationale about RFNs: http://scripts.sil.org/OFL-FAQ_web

RFNs are optional but they actually serve a purpose in various cases. (Document reflow issues, changes in coverage and features, unexpected bugs and support burdens coming from derivative versions are then clearly distinct from the canonical version because they have different unique names.)

Some people argue that uncontrolled forking, redistribution and publication of end-user facing fonts under the exact same name as the original is less than ideal. IOW breaking the namespace for end-users and other designers (or the Knuthian adage: you can modify it but please don't create chaos).

Having webfont services publish truncated subsets of a font (or with broken smarts) under the exact same name as the original for "optimization" purposes is also less than ideal.

When developing an open font collaboratively in a public repository, you can also use a development name that is different from the release name which users expect to be stable.

(Documenting changes in a FONTLOG.txt file is recommended but not required).

@davelab6
Copy link
Contributor Author

davelab6 commented Feb 3, 2016

When developing an open font collaboratively in a public repository, you can also use a development name that is different from the release name which users expect to be stable.

For people keen on RFNs, I think this is essential :)

@simoncozens
Copy link
Owner

The web fonts / RFN paper says that I can give any webfont service a written agreement to use the RFN in subsets (should I ever get to that stage). But I would rather forks not have the same name. That suggests to me that an RFN is what I want.

I don't understand the benefits of a different development/release name - could you explain?

@davelab6
Copy link
Contributor Author

davelab6 commented Feb 3, 2016 via email

@davelab6
Copy link
Contributor Author

davelab6 commented Feb 4, 2016 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants