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 <invernom...@paranoici.org>, 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
