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

Downstream / distribution preparation for repository transition to Source Foundry organization #255

Closed
6 of 9 tasks
chrissimpkins opened this issue Jul 19, 2017 · 34 comments

Comments

@chrissimpkins
Copy link
Member

chrissimpkins commented Jul 19, 2017

We intend to transition the Hack repository to our Source Foundry organization in order to facilitate collaboration by the development team.

This is a request for all downstream projects and primary contacts for font distribution to weigh in on the impact that this will have on your current approach / the time that may be required to address this on your end before we make the transition. The Github support team assures me that all URL will be forwarded to the new repository for git and curl requests. I have not reviewed any of your approaches to redistribution of the fonts and want to try to make this as seamless of a transition as possible for all of us.

For those distributing the fonts, please note that the v3.0 release will include a new build toolchain with FLOSS build/hinting/subsetting tools using UFO source files in the repository. This approach should meet requirements/guidelines on some Linux distros for source based builds and we will provide start to end implementation of the entire process for you in one or more build shell scripts. You should only need to confirm that these build dependencies are installed, pull the Hack source files, and the remainder will be automated for end users. The pieces of this process are being pulled together and QA'd now. If you would like to assist with QA on your distro / re-distribution approach, we are more than happy to pitch in on our end and look forward to your feedback.

Other changes include a tentative decision to convert to ttf releases for the desktop (elimination of otf builds) and elimination of unnecessary web font build types that existed in the v2.x releases. We will provide additional information as we get a bit further down the road with the build tool chain development. This work is in progress and you can stay current in this thread.

Github documentation on repository transfers: https://help.github.com/articles/about-repository-transfers/

Contact checklist:

  • Arch
  • Chocolatey - OK
  • Debian - OK
  • Fedora - OK
  • Gentoo - OK
  • Homebrew - OK
  • OpenSUSE
  • Ubuntu - OK
  • Visual Studio package manager

cc:
@amadio (Gentoo)
@heliocastro + @spstarr (Fedora)
@texhex (Windows)
@coderbyheart (Arch)
@alerque (Arch + Homebrew)
@GianniTM (Homebrew)
@paride (Debian + Ubuntu)
@mtelesha (openSUSE)

@paride
Copy link

paride commented Jul 19, 2017

Thanks @chrissimpkins for the work being done and for letting us know about the ongoing changes. My plan for the Debian package is start over taking into account the fact that now the font can be built from source, so there will be a proper source package, a build process, and a binary package. Sure it will get more complex, but I think it's worth the effort and will consolidate Hack's position as a FLOSS friendly font for code. The only requirement for me is that releases are properly tagged in a git repository.

I have just one doubt: does the current license allow the redistribution of rebuilt fonts under the reserved font name "Hack"? Is there any condition for this? I think the license should be more explicit on this point.

(Dropping the whole reserved font name thing would remove any doubt on the redistribution, but I'm not sure if you'll consider this option...)

@chrissimpkins
Copy link
Member Author

I have just one doubt: does the current license allow the redistribution of rebuilt fonts under the reserved font name "Hack"? Is there any condition for this? I think the license should be more explicit on this point.

Let me look into this and let you know Paride.

My plan for the Debian package is start over taking into account the fact that now the font can be built from source, so there will be a proper source package, a build process, and a binary package.

We intend to transfer the repository for work prior to the v3.0 release at which time build tools will be available to you. Will this disrupt your current distribution approach?

@chrissimpkins
Copy link
Member Author

chrissimpkins commented Jul 19, 2017

@paride are there are any individuals associated with the Debian project who might be able to provide legal advice? I've approached the SIL team for assistance with this licensing quagmire and while helpful it was not of top priority for them...

Issue for another IR thread if you would like to have a conversation or feel free to email me.

@paride
Copy link

paride commented Jul 19, 2017

@chrissimpkins There won't be any disruption, no problem for the change on my side.

On the licensing issue I'll ask and let you know.

@chrissimpkins
Copy link
Member Author

On the licensing issue I'll ask and let you know.

Thanks! The intent on our end is absolutely not to disrupt your ability to release the fonts in this way. If the legal language in the license suggests otherwise I am very open to modifications so that you can build directly from the source using our build approach. The goal with the Hack reserved name has simply been to preserve our team's QA process on the fonts released with the name "Hack" (of which there is a tremendous amount in the background prior to releases). In part, this is to ensure that your users receive the Hack that we intended for them to view and in part to avoid issue reports landing here as a result of projects that choose to build in alternative ways. We simply don't have the time to diagnose and troubleshoot these issues and users don't know better as these build issues are not readily apparent. It is difficult for us to even identify who the proper contact is for such issues in some cases so there is frustration for all involved.

@chrissimpkins
Copy link
Member Author

@paride you are listed as a maintainer of the Ubuntu package as well. Can I assume that the above applies on that distro too?

@amadio
Copy link
Contributor

amadio commented Jul 19, 2017

There should be no problem for Gentoo either.

@paride
Copy link

paride commented Jul 19, 2017

@chrissimpkins Ubuntu inherits the package from Debian, so the short answer is yes.

Anyway in this case the limitation is given by Hack's license. If the license forbids the distribution of rebuilt versions, with no exception, there's nothing we can do. (Of course we will keep distributing the officially built version, but we'll all miss an opportunity I think.)

I think the right compromise could be explicitly allowing the distribution of rebuilt versions provided that a specific built process has been used.

@spstarr
Copy link

spstarr commented Jul 19, 2017

@chrissimpkins No issues with this at all

@chrissimpkins
Copy link
Member Author

chrissimpkins commented Jul 19, 2017

@amadio ty!

@spstarr ty! have you and @heliocastro spoken about the new package on Fedora? He currently maintains dnf-plugins-core :: heliocastro/hack-fonts :: hack-fonts. Should this be deprecated in favor of what you are working on once it is available?

@paride that all sounds great. If you wouldn't mind putting me in touch with the legal team there, I can make sure that we have the language correct to support this.

If the license forbids the distribution of rebuilt versions, with no exception, there's nothing we can do.

To reiterate, that is not the intent. I just need to understand how to specify these permissions in 'legalese'. We are going to provide a standardized process from source to final fonts and I am more than willing to remove/modify any limiting language that interferes with your capacity to replicate this build for end users on Debian/Ubuntu.

@chrissimpkins
Copy link
Member Author

I reached out to the manager of the Chocolatey package through the Chocolatey page for Hack fonts. Await reply.

https://chocolatey.org/packages/hackfont

@gtmgianni
Copy link

I don't think this will be an issue for Homebrew-Cask, but pinging @vitorgalvao just to confirm this.

@chrissimpkins
Copy link
Member Author

@GianniTM thank you! Please note that we will be switching to ttf files as our default release and plan to eliminate the otf builds. This may require a slight modification in the Homebrew scripts. We will have updated documentation on this as we get closer to the first v3 release.

@vitorgalvao
Copy link

Thank you for the heads up and the ping. @GianniTM is correct: regarding Homebrew-Cask, the disruption should be minimal. A few tweaks to the new URLs/fonts, and we should be good to go.

@chrissimpkins
Copy link
Member Author

@vitorgalvao 👍 thanks!!

@ShadowZero3000
Copy link

Hey @chrissimpkins! Thanks for the heads-up on your planned changes. At the moment the Chocolatey installer for Hack runs the equivalent of a curl against the url: https://github.com/chrissimpkins/Hack/releases/download/v${version}. It sounds like this will continue to operate for now, and ideally I can just update the url as soon as you go live with the transition, and it should be transparent to Chocolatey users.
Just keep me in the loop on when we're cut over, and I'll get a new version tested and released.
Thanks again!!!

@chrissimpkins
Copy link
Member Author

@ShadowZero3000 will do! thank you very much for letting us know!

@paride
Copy link

paride commented Jul 28, 2017

Dear @chrissimpkins, could you let us know something more about the web fonts? What will be eliminated?

I'll make my question more precise. Currently there are four variants of web fonts: eot, web-ttf, woff, and woff2. What's the plan for Hack v3? Do you plan to drop any of these?

@chrissimpkins
Copy link
Member Author

@paride haven't reached that stage of the build yet. Will let you know when I am there. We will likely replicate the sets released for the Google Fonts project.

@jonassmedegaard
Copy link

jonassmedegaard commented Jul 28, 2017

@chrissimpkins The best place to ask in Debian is the public mailinglist debian-legal@lists.debian.org - subscribers of that list are not lawyers but experienced with legalese and how it commonly fits Debian Free Software Guidelines (DFSG).

@chrissimpkins
Copy link
Member Author

@jonassmedegaard Perfect! Thank you very much Jonas. I will.

@chrissimpkins
Copy link
Member Author

Transition to the Source Foundry organization account has taken place. Please check your distributions to confirm that the forwarding URL links work.

Thanks to all for your help with the repo transition! Dependencies and scripted builds will be coming soon. More news in this thread when they are available for testing.

@chrissimpkins
Copy link
Member Author

chrissimpkins commented Aug 13, 2017

Discussion about the source build toolchain components and necessary dependencies will take place in the previous issue report:

#227

Outstanding issues in this thread include:

  • the license discussion for the Debian project (and other interested parties who have the same concerns)
  • web font binaries that will be released in v3.0 and beyond
  • any issues that developed as a result of the repository move to our organization account

@chrissimpkins
Copy link
Member Author

chrissimpkins commented Aug 14, 2017

We received some 404 error reports on the Github hosted Source Foundry website for URL that pointed to Hack text specimens. These links have all been updated as have the download links for font releases.

@coderbyheart
Copy link

I've updated the OTF release for Arch: https://aur.archlinux.org/packages/otf-hack/

@chrissimpkins
Copy link
Member Author

chrissimpkins commented Aug 14, 2017

@coderbyheart Thank you very much Markus! We have had a number of issues raised with the otf builds, they are less commonly used than the ttf builds (rightly so in our opinion - and guided by our suggestions on the README- because of less ideal hinting than in our ttf releases, an issue that likely matters on your Linux platform). We have been tossing around the thought of eliminating otf builds in favor of ttf only for the desktop and a set of web fonts.

I opened a new issue where we can discuss it if you have thoughts about it. I believe that @alerque has raised several of the hinting related issues with the otf sets and has participated in the Arch otf package. Let us know what you think in that thread.

#267

@chrissimpkins
Copy link
Member Author

@paride @jonassmedegaard

The following email was mailed to the debian-legal mailing list this evening. Please weigh in on the mailing list if I did not appropriately capture your concerns:

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: #255 (comment)

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

@chrissimpkins
Copy link
Member Author

@coderbyheart Markus, do you happen to know who maintains the Arch package for the ttf fonts?

@coderbyheart
Copy link

@chrissimpkins that is Lukas Fleischer lfleischer@archlinux.org

@chrissimpkins
Copy link
Member Author

@coderbyheart Thanks Markus. I really appreciate it.

@chrissimpkins
Copy link
Member Author

The source code repository transition took place two weeks ago and we have not received any reports of problems with any package transitions. Will close this issue report. Please feel free to reopen if you come across any issues.

Issues that arose in this thread and that remain outstanding are available as new issue report threads. These include:

@ShadowZero3000
Copy link

I just got the new Chocolatey package uploaded as well. Thanks again for this awesome font!

@chrissimpkins
Copy link
Member Author

@ShadowZero3000 👍 👍 👍

Thank you!

@chrissimpkins chrissimpkins reopened this Oct 20, 2017
@chrissimpkins
Copy link
Member Author

v3.000 was released! The new build files are available in the latest Github release. For those who are building from source, the make based scripting approach is now available in the master branch.

Please let us know if you have any issues with the redistribution project updates with these changes. Also please note the change in the archive paths in the releases as of v3.000. The paths are different than they were in the v2.x releases.

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

No branches or pull requests

9 participants