Page MenuHomeSoftware Heritage

Add Web Labels to state the license of the JavaScript we distribute
Closed, MigratedEdits Locked

Description

To ease automated license/freeness checking of the javascript code that the Web UI depends on, it would be nice to add Web Labels wherever appropriate, for both our own code and the third party modules we use.

Event Timeline

zack triaged this task as Low priority.Feb 3 2019, 11:53 AM
zack created this task.

This should be feasible but the main issue here is that our javascript code is bundled in multiple files.

According to section 7.1.1 of LibreJS documentation [1], we should use that method to declare
the js modules licenses.

From my point of view, a webpack plugin should be written to extract all bundled files and their
associated license and then generate the web labels page. Maybe these existing plugins [2, 3] could help us in that task.

{1] https://www.gnu.org/software/librejs/manual/html_node/Setting-Your-JavaScript-Free.html

{2] https://github.com/xz64/license-webpack-plugin

[3] https://github.com/codepunkt/webpack-license-plugin

anlambert renamed this task from add Web Labels to state the license of the JavaScript we distribute to Add Web Labels to state the license of the JavaScript we distribute.Feb 6 2019, 5:42 PM
anlambert raised the priority of this task from Low to Normal.

Based on my first experiments, the webpack plugin is effectively the right way to go here.
There will also some slight modifications to bring to our django templates containing some script tags.

Regarding the webpack plugin, it should be able to output:

  • the Web Labels HTML page containing the table describing the modules bundled in each generated js assets (license and link to non minified source code)
  • a JSON file with all require data for generating the Web Labels page (for instance to generate it with Django)

To describe the npm modules we are using in our bundles, I think the simplest way is to give their name, their license and add a link to the original tarball
available from the npm registry. Linking to invidual source files on GitHub contained in each npm module should also be feasible.

However I have a doubt on the fact that linking to tarballs or source files not located on our web server is a good practice for Web Labels.
The few examples I can found via a Google search [1] do not provide external links in the Web Labels page.
This surely means the webpack plugin will have to copy the tarballs or the original js source files in a dedicated folder
of our web server.

[1] https://www.google.com/search?client=firefox-b-d&biw=1920&bih=1050&ei=0hRbXLeDCKO7gwe54KDAAg&q=javascript+license+information&oq=javascript+license+information&gs_l=psy-ab.3...0.0..16987...0.0..0.0.0.......0......gws-wiz.pXfGSt9SYtw

@anlambert Will an as-specified weblabels table work with webpack? I feel like weblabels were specified assuming one source and license per file, which is often not the case here. I've started a thread on the LibreJS mailing list about possibly adapting the magic-comment style syntax for this purpose, but interested to hear if you prefer a weblabels based approach and what that might look like.

From my perspective, there's no reason to copy the source code to your server unless you're worried about the source going away. Really, once SWH is ingesting npm the best course would be to generate SWH archive links instead of links to npm or github.

@anlambert: did you follow-up on list and/or to @singpolyma about the solution you've adopted?

I intend to do that on monday (I will be on vacation tomorrow) and write a post on the LibreJS mailing list to discuss the proposed approach (simply respecting the current specs) and see what can be improved to better handle compiled JavaScript assets. I wanted to have a live demo first to showcase the results.