DFSG + Hack typeface license with transition to proposed new source file build in Debian package
Our fonts (Hack - https://github.com/source-foundry/Hack) are currently released through the Debian package manager (package maintainer Paride Legovini) from our Github repository as binaries that are compiled + hinted by the project author team. As of our upcoming v3.0 release of the fonts, we are transitioning to a new scripted compilation process that will allow redistribution of these binaries as built directly from the source files by redistribution teams. There are multiple reasons for this, but one has been a request by a number of Linux distro package maintainers to abide by guidelines that include the DFSG. Paride asked me if there will be an issue with the release of the Hack font files through this scripted source compilation process on Debian and Ubuntu distros based upon the language in our dual license structure (admittedly complex due to the fact that these fonts are a fork from Bitstream Vera Sans Mono that had a license which predates the current FLOSS licenses in use for typefaces). I believe that his concern is with the Reserved Font Name stipulation in our Hack Open Font License and whether there are conflicts for your group. I received a request from a user to contact this mailing list for further information and to clarify the language in our license against your guidelines for software redistribution. We fully support and encourage this form of redistribution of our fonts so long as the packages are compiled with the validated build tooling (including appropriate dependency versioning) that we use in the repository builds that are intended for release to the end user. If there is license language that seems to indicate otherwise or prohibits your capacity to distribute the font files in this fashion, I would greatly appreciate any feedback that you would be willing to provide about how we can modify the licensing so that this is no longer the case. Our license is available here: https://github.com/source-foundry/Hack/blob/master/LICENSE.md The original issue report thread where this was raised by Paride is here: https://github.com/source-foundry/Hack/issues/255#issuecomment-316414866 It would be ideal to have this conversation in a Github issue report on the repository (the above report or a new one if appropriate) if you are willing. Assuming that is not possible given the size of this list, I will try to summarize the outcome of the conversation for Paride and our users, then point a link to the debian-legal archives so that we have a record of the discussion. Thanks in advance for your help. I greatly appreciate your assistance. Chris Simpkins
Re: DFSG + Hack typeface license with transition to proposed new source file build in Debian package
Thank you Jeff. The Hack Open Font License was modeled on the Bitstream Vera license and SIL OFL. Downstream open source project font licensing from the days prior to SIL OFL (and to some degree even after that period) is a bit of a quagmire. Item 2 is where the reserved font name declaration is located. I have been considering modification of the language here to permit forks to use “Hack” in the name, but not “Hack” alone for a forked typeface. We have bound our own hands in this language and would like to make/release some derivative typefaces from the Hack source with names such as “Hack Ligature”, “Hack ASCII”, “Hack ZeroSlash”, etc. This will also support other project teams who would like to associate their fork with the Hack upstream source by using Hack followed by a string that distinguishes it from the upstream source. The impetus for the reserved font name issue is simply QA. We perform a great deal of manual testing prior to releases that cannot be fully automated in the current era of font development software. The exact build process that we use is the one that we have validated and want to support. One of my worries if we loosen this requirement (i.e. fully remove the reserved font name) is that we will be approached on the repository about all build issues assuming that we will be able to troubleshoot the issue for teams that elect to build with a different approach. There are numerous other ways to compile the fonts out there and the OpenType tables as well as the hinting on the fonts can, and in many cases likely will, change for those who do not appreciate these issues. It is a downside in the typeface software development area that is in need of repair. But it is a reality that we face. Will wait for more feedback and then weigh in further. On Aug 16, 2017, 8:23 AM -0400, wrote: > > This License becomes null and void to the extent applicable to Fonts or Font > Software that has been modified and is distributed under the "Bitstream Vera" > names
Re: DFSG + Hack typeface license with transition to proposed new source file build in Debian package
> I personally think that technical issues should not be worked around by imposing licensing restrictions. If typeface development tools need to be improved in order to get better QA, then I hope they can be enhanced from a *technical* point of view. In the meanwhile, licensing restrictions should not be introduced to compensate for technical limitations. A very valid point and well taken. On Aug 16, 2017, 11:02 AM -0400, wrote: > > I personally think that technical issues should not be worked around by > imposing licensing restrictions. > If typeface development tools need to be improved in order to get > better QA, then I hope they can be enhanced from a *technical* point of > view. In the meanwhile, licensing restrictions should not be introduced > to compensate for technical limitations.
Re: DFSG + Hack typeface license with transition to proposed new source file build in Debian package
We created a new thread for our license discussions for anyone who is interested in participating on the repository: https://github.com/source-foundry/Hack/issues/271 One possibility for us would be to eliminate the dual license structure and simply revert to the Bitstream Vera license with public domain contribution of our changes in the same fashion that the DejaVu group used for their modifications to Bitstream Vera Sans Mono. This sounded ‘benign' to me but Dave Crossland informed me that public domain contributions to the public domaining of these source contributions led to additional problems with distribution. My understanding is that there were legal issues that arose in some European countries and that this is (at least in part) why DejaVu Sans Mono has never been included as part of the Google Fonts collection. I am hoping not to trade one set of problems for another and would be interested in your feedback about any potential DFSG issues associated with commitment of source modifications to the public domain if we moved towards this strategy. On Aug 16, 2017, 11:02 AM -0400, Francesco Poli , wrote: > On Wed, 16 Aug 2017 08:40:00 -0400 Chris Simpkins wrote: > > > [...] Downstream open source project font licensing from the days > > prior to SIL OFL (and to some degree even after that period) is a > > bit of a quagmire. > > Hello, > I agree that font licensing is a quagmire. > > Well, I even go further and personally think that it is a real mess: > I wish more fonts were simply released under the terms of wide-spread > and well understood licenses (such as the Expat/MIT license or the GNU > GPL v2 + font exception)... Doing so would spare a good number of > headaches to many people! > > > > > Item 2 is where the reserved font name declaration is located. > > I have been considering modification of the language here to permit > > forks to use “Hack” in the name, but not “Hack” alone for a forked > > typeface. > [...] > > Personally speaking, I would encourage you to at least relax this > restriction (or, even better, to drop it entirely). > That way, only one name (or no name) would be forbidden for derivative > fonts and everything would be simpler... > > [...] > > It is a downside in the typeface software development area that > > is in need of repair. But it is a reality that we face. > > I personally think that technical issues should not be worked around by > imposing licensing restrictions. > If typeface development tools need to be improved in order to get > better QA, then I hope they can be enhanced from a *technical* point of > view. In the meanwhile, licensing restrictions should not be introduced > to compensate for technical limitations. > This is my personal opinion. > > I hope this helps. > Bye. > > > -- > http://www.inventati.org/frx/ > There's not a second to spare! To the laboratory! > . Francesco Poli . > GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Re: DFSG + Hack typeface license with transition to proposed new source file build in Debian package
This is very helpful Ian and I really do appreciate your feedback. I think that we are in agreement on our end that elimination of the reserved font name will be the best approach for all involved. This will likely come along with licensing of all changes that we have made to the upstream source under a MIT license. How to approach the license for our changes remains under discussion by our project authors and the community around the project but this is the direction that we are leaning. This means that you can perform source and post-compilation modifications on the fonts derived from our released source and maintain the name Hack on these fonts. Ultimately, we want the fonts to be as free as possible given the upstream licensing restrictions that are in place and the pros of the RFN removal move for us seem to outweigh the cons. A large part of our current move to release the source as UFO only with only free OS build tools is to encourage its use as an upstream for modifications and new derivatives. A number of authors have expressed an interest in using “Hack” in the name of their derivative projects, something that is not permitted under the current license (including for the authors of Hack should we choose to release a derivative!). The move is, I think, a good one for the project and the Debian community has been a large part of the push for us to better understand these licensing issues and take action. Thanks to all in this thread for your feedback and assistance. Your time is greatly appreciated! Thanks again, Chris On Aug 30, 2017, 10:33 AM -0400, wrote: > > From Debian's point of view, the licence you provide is adequate for > us to be able to include the fonts in Debian. However, the reserved > font name restriction would almost certainly mean that we would have > to rename the fonts. > > Debian has a long history of dealing with upstreams who restrict the > ability of Debian to distribute a modified version under the usual > name. For example, for many years, Debian's Firefox package was > called `iceweasel' (and all the Firefox branding was removed), because > the Mozilla Foundation (who own the trademark "Firefox") insisted on > prior approval of all changes. > > Debian is not likely to accept a restriction on modifying glyphs. We > consider that Debian (and its downstreams and users) must be free to > make changes - even changes that upstreams disapprove of. For fonts, > the need to change glyphs is not theoretical: when I was an Ubuntu > developer I personally modified a font in order to correct an > erroneous glyph in some Georgian character, in response to a bug > report from a user.) > > So, if you would like Debian to distribute your fonts under names > which advertise your project as the origin, then you should grant > Debian permission to do so. > > I hope this has been a useful perspective. > > Regards, > Ian. > > NB: I am not the person in Debian who makes these decisions. But I > think the views I have attributed above to the project as a whole will > be very uncontroversial.
