https://bugzilla.redhat.com/show_bug.cgi?id=1619530
--- Comment #31 from Nicolas Mailhot <[email protected]> --- @George Machitidze ### Legal aspects Much as I love the GPL and use it for my own projects it does not translate well to font files. From a legal point of view, software is derived into other software, so a license that propagates to derived works like the GPL does, works well. It’s software both parts of the equation. However, fonts can be derived into documents due to how document formats embed fonts (fully or via subsetting). Therefore, the GPL and software licenses in general are completely inadequate for font files. Most people do not want their documents GPLed just because they used a Free and Open font in them. Because the GPL is inadequate, there was quite a lot of experimenting at the start of the century to find a working license for Free and Open fonts. Some proposed font-specific GPL legal extensions. Others wrote brand new experimental licenses. In the end most everyone agreed to use the OFL, which is the font license of most Google fonts today, and the font license Fedora recommends for new font projects. DejaVu antedates all of this however. It is a direct derivative of Bitstream Vera, which was released under one of licenses people experimented with before settling on the OFL. Vera/DejaVu licensing is unlikely to change today because that would require Bitstream cooperation and probably quite a lot of money to motivate the Bistream legal department to look at it. When adding to or modifying Vera or DejaVu, you should strive to keep things simple and integrate the original Vera/DejaVu legal framework. DejaVu licensing is complex and one-of-a-kind due to the inadequacies of the original experimental Bitstream licensing. It’s not as simple as using vanilla GPL for software or the OFL for new font projects. https://github.com/dejavu-fonts/dejavu-fonts/blob/master/LICENSE When the DejaVu project was active it served as legal clearing house and made sure contributors understood and and agreed with those legal clauses. Now it is dormant, people that release DejaVu derivatives must do this work themselves. ### Font coverage aspect From a font file point of view the only thing we can do is try to integrate fonts with correct opentype metadata and correct unicode coverage. It is no use, as you wrote, to remove coverage from font files. Software that wants to use specific code-points will just fall back to fonts that include this coverage. If you want to prevent those fallbacks the only reliable way is to integrate good coverage in your font file so the fallback need not happen. If things still do not work after a font with good unicode coverage was deployed, then that means: 1. some piece or text rendering is making mistakes when applying the unicode standard. No use work-arrounding the standard by using incomplete or non-compliant font files here, you need to identify which part is misapplying the standard and get it fixed 2. the Unicode standard is wrong. Well, I sort of doubt this is the case here, but human creations are imperfect by nature. If the standard is wrong then you need to get it fixed because software implementers are applying the standard and do not have time to waste sifting through all the pseudo-standards people keep inventing all over the world. That’s the sole reason people use Unicode today. It is horribly complex, and not ideal, but having to deal with multiple conflicting encoding rules would be way worse. Chinese/Japanese/Korean people yelled for a decade Unicode made the wrong decisions for their scripts. They are using Unicode like everyone else today anyway, because the alternative to Unicode, are way worse from a software interoperability point of view. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ fonts-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
