Bundle the font

[tstarling]

For performance, offline support and privacy.

Cut down the CSS file from the package so that we only need to bundle
the one font file, like what Google was doing.

[Krinkle]

Tested locally and confirmed that Parcel indeed knows to copy and bundle the file from node_modules.

Opening index.htm from the latest stable release zip, involves two network requests to fonts.googleapis.com. Checking out this patch, running scripts/prepare-test-installation.sh, and opening dist/release/index.html involves no network requests.

[jlfwong]

Thank you! Next time I'm ready to cut a release, I'll test this myself and merge

[tstarling]

Hi @jlfwong, thanks for your response. @Krinkle and I are on the performance team at Wikimedia and we're looking at integrating speedscope with Wikimedia websites using our own sampling profiler for PHP. We're doing it in a way that should be usable by other PHP applications. The details are at https://phabricator.wikimedia.org/T291015

[jlfwong]

When I look at https://fonts.googleapis.com/css?family=Source+Code+Pro, it lists the woff2 formatted files rather than ttf. It looks like the npm package also contains these files: node_modules/source-code-pro/WOFF2/TTF/SourceCodePro-Regular.ttf.woff2. The woff files are smaller, which appeals to me. Is there a reason to use the ttf files instead of the woff2 files?

I'm also not sure what the licensing requirements of this become once it's bundled with the software.

From looking at https://github.com/adobe-fonts/source-code-pro/blob/release/LICENSE.md, it seems like I'm supposed to include licensing information somewhere in this project. If you're interested in having this merged, can you please look into that and see what, if anything, would need to change in this repository?

[tstarling]

When I look at https://fonts.googleapis.com/css?family=Source+Code+Pro, it lists the woff2 formatted files rather than ttf. It looks like the npm package also contains these files: node_modules/source-code-pro/WOFF2/TTF/SourceCodePro-Regular.ttf.woff2. The woff files are smaller, which appeals to me. Is there a reason to use the ttf files instead of the woff2 files?

I didn't realise that it delivers different stylesheets depending on User-Agent. If you use curl, it only shows TTF.

I'm also not sure what the licensing requirements of this become once it's bundled with the software.

From looking at https://github.com/adobe-fonts/source-code-pro/blob/release/LICENSE.md, it seems like I'm supposed to include licensing information somewhere in this project. If you're interested in having this merged, can you please look into that and see what, if anything, would need to change in this repository?

Yes, I think you're right that a license notice is required. Although probably all of your runtime dependencies have this problem.

[jlfwong]

I didn't realise that it delivers different stylesheets depending on User-Agent. If you use curl, it only shows TTF.

Gotcha. As far as I can tell, WOFF-2 is very widely supported now (https://caniuse.com/?search=woff2), so I'd prefer this woff-2 instead to keep things as compact as possible.

Yes, I think you're right that a license notice is required. Although probably all of your runtime dependencies have this problem.

This might be true, but AFAIK all of my other runtime dependencies have common software licenses like MIT, rather than a font-specific license. I've never heard of folks getting in trouble for bundling MIT licenses for npm dependencies (otherwise every single npm package would need this). But I know much less about legal issues around fonts.

[Krinkle]

Yes, I think you're right that a license notice is required. Although probably all of your runtime dependencies have this problem.

This might be true, but AFAIK all of my other runtime dependencies have common software licenses like MIT, rather than a font-specific license. I've never heard of folks getting in trouble for bundling MIT licenses for npm dependencies (otherwise every single npm package would need this).

Stuff about MIT and FLOSS licenses

I am not a lawyer, but my understanding based on working in open source at Wikimedia Foundation and in the jQuery Team (OpenJS/Linux Foundation) for over a decade, is as follows:

The MIT license is among the most liberal in open source. Practically the closest thing to being entirely in the public domain. You can do literally anything you want with it, as long as you attribute its authors/copyright line somewhere. Similar in spirit to the Creative Commons Attribution license in that sense. "Attribution", thus requires the copyright line to be preserved or otherwise presented in distributions that include copies of the software.

Most npm packages are not end-user applications or products, and thus don't have any practical involvement around this. For a typical library package, its only concern is its own license in the repo/package uploaded to npm, and anyting it uses or that others use it for, is handled transparently by npm-install later on when someone else uses it. When you upload your own package to npm, usually, you are not distributing your dependencies for they are not included in the package. package.json merely points to them by name, and it is later on, that someone else runs npm-install and then installs both it and the dependencies. Even for end-user applications like ESLint and Grunt, npm solves it automatically. Naturally, their dependencies are either not yet downloaded (you haven't ran npm-install yet) or both a copy of the code and its LICENSE file are present (after you run npm-install, in the node_modules directory). This requires no further action on your part.

If you do something special with the code and distribute it by other means outside npm, or if you attach artefacts to your npm package that bundle/embed/inline code from dependencies, then you have to preserve or present the attribution by other means yourself. For example:

• If you distribute a tarball that includes the node_modules directory, you probably don't have to do anything. This naturally preserves any license header in source files and any separate license text files in directories.
• Firefox (the finished binary on your computer) compiles and embeds lots of C++ and JS software under a variety of licenses. There is not really a way to view this in source form after compilation, and thus does not naturally preserve attribution. This is why Mozilla included a semi-automated way to present this in their UI. You can go to Firefox > About > License information (or about:license) and you'll find a list there of each package they embedded/compiled, and the legally required attribution (e.g. Copyright John Doe). Most FLOSS licenses, also require a copy of (or web link to) the license terms. You'll find similar "about" views in many desktop apps, as well as mobile apps for iOS/Android often have such a license page.

In the case of Speedscope, Parcel is used to produce a single JS file and a single CSS file, and any comments are stripped. My best guess is that this is technically in violation of the MIT license for your dependencies. When I publish a copy of Speedscope on my own domain, I'm (probably?) not in violation of your license, since the Speedscope UI links to your GitHub repo, where your license file can be viewed. However, there's not really a clear path to the copyright statement of your dependencies (much less which ones were bundled, or which versions, or which copyright statement they had at that time). Parcel strips it all out. I could not find anything in the the Speedscope release tarball, e.g. the HTML, JS file, or other text files, that indicates what code was bundled or who holds their copyright. The source repo also does not distinguish in package.json between dev and prod dependencies (noting that your dev dependencies are generally not distributed. E.g. the tools you use for bundling, testing, minification are not being distributed in the release and do not require attribution). Instead, it seems your prod dependencies are listed among dev-only, and some of them are then bunded into the JS file during release. This makes sense for efficiency, but means that the npm distribution is probably technically in violation as well.

Font

As for the font, https://openfontlicense.org/ofl-faq/ does a good job of answering the hard questions. It is in essense an even more liberal license than the MIT license, as it presents plethora of scenarios where you do not even have to attribute its author or copyright holders. Unlike commerically licensed fonts where you may have to pay to download them, and then pay pay for permission to use the font in a brand or publication.

The OFL is much like the MIT license in that it permits copying, modification and re-distribution, so long as you preserve a copy of the original license text and/or other attribution. In addition, it grants very useful and practical exemptions for work that merely applies the font (e.g. a logo or a screenshot of Speedscope where the font is used), where it requires no attribution at all. Given that Speedscope releases would include a copy of the file as-is, atttribution would be required, however.

While by no means required, I would personally choose the following as the simplest approach:

• Create the assets/source-code-pro directory with in it the SourceCodePro-Regular.ttf.woff2 file and https://github.com/adobe-fonts/source-code-pro/blob/release/LICENSE.md.
• Check, or update as needed, the release step so that during or after the Parcel step, there are both SourceCodePro-Regular.woff2 and SourceCodePro-Regular.license.md in the dist directory. Alternatively, you could create your own "NOTICE.txt" file in Git with the two attribution lines of the license and make sure to copy that into the dist folder. You may want to expand that at some point to include the attribution of this repo and other dependencies as well.

If this sounds acceptable, I'd be happy to submit a PR doing that.

[jlfwong]

Hey @Krinkle! Thanks for the thorough rundown, and especially for hunting down the licensing details of source-code-pro!

Regarding the technical MIT violations, I think you're probably right too. That sounds, frankly, like a pain to resolve, and certainly a separate concern from what this PR is addressing. So for now I think I'll punt on that.

The simplest approach you propose sounds good to me, and I'd be happy to accept a PR doing that.

[jlfwong]

Closing in favor of #472