Am 19.10.2024 11:24 schrieb Bastien: > I stumbled across this, which may be of interest for the LibreJs > project: > https://matija.suklje.name/persistent-copyright-licensing-information-in-client-side-javascript-css-and-similar-a-proposal-call-for-help >
Just read through it. It is suggesting comments for license-start and license-end with SPDX tags and is focusing on bundled JavaScript. LibreJS already supports the marking of licenses via comments, just not with SPDX tags: https://www.gnu.org/software/librejs/free-your-javascript.html Like > // @license > magnet:?xt=urn:btih:1f739d935676111cfff4b4693e3816e664797050&dn=gpl-3.0.txt > GPL-v3-or-Later > var myString = "Hello World!"; > alert(myString); > // @license-end Adding support for SPDX tags is a feature request, that just nobody acted on yet, but the interest is there: https://savannah.gnu.org/bugs/?61893 I am not a LibreJs maintainer (yet), just a developer dealing with bundles and who wrote webpack plugins. There are a few different subjects here: > wrapping the bundled code in such comments That's what the author suggests. It isn't very useful in my opinion. The bundled code isn't the source. And webpack will remove it from the bundle (as the author found out as well) because the bundler extracts individual exports of a file, which can then be on different positions in the finished bundle. It's like trying to ad license tags into the binary code of a compiled application. > .js.LICENSE files Webpack detects and parses LICENSE headers by default, and outputs them into .js.LICENSE files. Here is gitea merging them together and linking to it in their License disclaimer: https://gittea.dev/assets/licenses.txt It's cool, but can a user express his rights of freedom with this or use this in any meaningful way? It's also not useful for libreJs when it is merged like this, because you can't tell which package went into what bundle. > license comments in source maps License comments are kept intact in source maps, which is from user-perspective probably a useful place to encounter them, because source maps are a standard and developer consoles of browsers automatically download those to de-obfuscate the code if they exist. So a user can actually browse through the source code and see them there. But we can't expect from extensions like LibreJs to parse source maps, they are way too large. > doing a Web Labels Table > https://www.gnu.org/licenses/javascript-labels.html You can define multiple sources in such a table or an archive where you copied the sources of all individual files that got bundled. Software Heritage does that: https://gitlab.softwareheritage.org/swh/devel/swh-web/-/tree/master/assets/config/webpack-plugins/generate-weblabels-webpack-plugin And this is LibreJs compatible. https://archive.softwareheritage.org/jslicenses/ The issue i see here is that just because i have access to all the individual files, it doesn't mean that i can bundle those. There is no bundler configuration or plugins that might be needed. If i would change and build it myself, i would go to their gitlab. There is also pixelplanet who built upon the softwareheritage webpack plugin: https://pixelplanet.fun/legal/summarized.html As a user, this one tells me the most and i know what is going on. Having a plugin like this, that simply outputs one html file with a table you link to, and its LibreJs compliant, would be the ideal solution in my opinion. The one thing that stops it from being completely automated is that a package.json of a npm module does not link to the source. They have the license inside, they link to the repository, but not to a source archive of the specific version you just got. So those need to be specified manually. They do it like this: https://git.pixelplanet.fun/ppfun/pixelplanet/src/branch/master/scripts/sourceMapping.js Regards
