Thursday, 9 July 2026
silver_hook
@silverhook:matrix.orgIntroduction¶
At this year’s LLW we held a workshop to finally come up with something that all present could agree was a solution to the problem that client-side1 JavaScript, CSS etc. gets distributed to the user without proper (or typically any) license and copyright information.
I first presented a short summary of my initial controversial proposal as well as the feedback obtained at FOSDEM, LLW and other sources. Then we discussed in a group consisting of OSPO leaders, FOSS lawyers and FOSS developers on what would be a good solution. Thankfully, we were able to rely quite a bit on the outcomes of a similar “REUSE-ify JS/CSS” workshop at LLW 2025.
To my big surprise, we pretty quickly came to an agreement what such a solution could look like.
In contrast, it was no surprise that the final solution had very little in common with my initial controversial proposal from 2024. So please forget about that one if it is still causing you high blood pressure.
Solution¶
TL;DR¶
- apply REUSE.software best practices, just as you would with writing in any other programming language
- use a tool of your choice to generate either:
- make sure that the file/page from 2. is linked in a
<link> rel="license" href="">HTML tag in the HTML<head> - create something in the web UI to present this link too, using a
<a rel="license" href="">HTML tag in the HTML<body>
Explanation¶
Just use REUSE¶
The first step should be pretty self-evident to any regular reader of my blog. REUSE.software has become the de facto standard for marking source code with licensing and copyright information. It essentially takes the SPDX (ISO/IEC 5962:2021) standard and implements it directly in source code2.
The big difference between this and the initial proposal is that the wrap-all-files-as-snippets hack is not needed – good riddance!
So, just follow the simple instructions on REUSE.software.
Create a compliance document¶
Regarding the second and third step, already at LLW 2025 we identified that it would be much better to ship a file/document alongside, instead of keeping tags in minified source code. Some companies already reported doing something similar, but not in any standardized way – and that they would very much be in favour of having a convention to follow.
When debating, we quickly came to the conclusion, that different organizations would have different tools3 and different processes on how to generate and handle license compliance artifacts. So we decided to leave the details of what exactly constitutes the best format to each project and organization, and concentrate on the how part instead (see subsection below).
Some options that were brougt up for you to consider:
- SPDX 2.x SBOM (in a variety of formats)
- SPDX 3.x SBOM
- CycloneDX SBOM
- tool-generated “attribution” file4 – typically in HTML format; typically lists components as PackageURL, their copyright holders and licenses
- manually written “attribution” document/notice
Distribute the compliance document to machines¶
And now for the “how” part.
As SBOM are typically primarily machine-readable, it would make sense to use a standard way of communicating said SBOM.
Luckily, the HTML standard already provides for something like this in the headers.
We can simply use a <link> tag with rel=license and the appropriate MIME type.
Where the rel=license attribute specifically is very topical:
licenseValid on the
<a>,<area>,<form>,<link>elements, the license value indicates that the hyperlink leads to a document describing the licensing information; that the main content of the current document is covered by the copyright license described by the referenced document. If not inside the<head>element, the standard doesn't distinguish between a hyperlink applying to a specific part of the document or to the document as a whole. Only the data on the page can indicate this.
So this could look something like:
<head>
<link
rel="stylesheet"
href="/static/client/styles-global.8f1bfba40e45c550.css"
fetchpriority="high"
/>
<link
rel="preload"
href="/static/client/inter-latin.9a3b1bc220d426ef.woff2"
as="font"
type="font/woff2"
crossorigin="anonymous"
fetchpriority="low"
/>
<script
data-cfasync="false"
data-report-only="on"
data-prompt="0"
src="https://transcend-cdn.com/cm/d556c3a1-e57c-4bdf-a490-390a1aebf6dd/airgap.js"
>
</script>
<!-- NB: this is the one we’re looking for: -->
<link
rel="license"
href="sbom.spdx.json"
type="application/spdx+json"
fetchpriority="high"
/>
</head>
With this in place, if you wanted to check a compliant website/webapp for licensing and copyright information relevant to the software (and styling) your web browser is downloading, all you would need to do is have some software check for the appropriate <link rel="license"/> and download or parse it.
Distribute the compliance document to humans¶
Understandably, you may5 also want to make it easy for humans to be able to see which licenses apply.
Again, we quickly came to the conclusion that different web apps have different technical or UI capabilities, and different organizations have different approaches too. So anything too rigid would not work.
But what we can do is to create some guidance on how to leverage the above. And, hoo boy, are we in luck today! The <a> HTML tag can also use the rel="license" attribute.
Some ideas on where to put the link though:
- just a link somewhere, e.g. in the footer
- (small) banner to pop-up the information
- an entry in a menu
Note as well, that nothing prevents us from having more than one rel="license" element, so we can serve different formats at the same time this way. Indeed, we could even serve an SBOM (or other licensing document) for each component separately, if we wanted.
As most humans will not readily consume SBOM, let us expand the above example a bit:
<head>
<!-- A machine-readable SBOM in JSON format -->
<link
rel="license"
href="sbom.spdx.json"
type="application/spdx+json"
fetchpriority="high"
/>
<!-- A human-readable HTML ”attribution” document -->
<link
rel="license"
href="attribution.html"
type="text/html"
fetchpriority="high"
/>
</head>
[…]
<body>
[…]
<footer>
<!-- A human-readable notice in the footer, linking to the “attribution” document -->
This website is licensed under
<a rel="license" href="https://creativecommons.org/licenses/by/4.0/">CC-BY-SA-4.0</a>
with the client-side software and styling under several FOSS licenses – the information to which, you can get in
<a rel="license" href="attribution.html" type="text/html">human-readable</a> and
<a rel="license" href="sbom.spdx.json" type="application/spdx+json">machine-readable</a> form.
</footer>
</body>
Prioritizing the delivery of licensing documents (optional)¶
Some German colleagues suggested that in their jurisdiction it may be important that license is shared at the exact same time as the content it covers. This raised the question of whether this compliance document should be forcefully pushed to the user’s/visitor’s browser and if so, when.
As the web development continues to be penny-pinching white-space6 in order to have webpages load faster, this is likely to be a show-stopper if we made it obligatory to fetch an SBOM before (or at the same time as) loading JS and CSS.
So the suggestion is, again, to leave it to each project and organization to decide.
Our old friend <link> has some features that help us here too.
You may have noticed in the above example that we used the fetchpriority="high" HTML attribute. As its name implies, this causes the compliance document to load in the browser sooner than other elements.
If you feel this is not fast enough either, you could even try out the rel=preload attribute in combination with <link as="">. But, to be honest, I would expect some big ire from the web developers if you did that, and there seems to be no ideal as="" to “preload as” either, because license is not an option there.
On the flip-side, if you are of the persuasion that licensing information should not hinder the speed the website loads, you could also set fetchpriority="low" instead. Do not come crying to me if a German court decides that you have made a grave mistake, though.
Example¶
Above I showed how this would look like in HTML itself. Here is a super-simple7 example of how it could look like.
Copyright and licensing
This website is licensed under CC-BY-SA-4.0 with the client-side software and styling under several FOSS licenses – the information to which, you can get in human-readable and machine-readable form.
What about?¶
Garbage in = garbage out¶
Did we solve everything now? Is there finally peace on earth and cancer is eradicated? Of course not.
The original sin of developers simply not storing (enough) copyright and licensing information in their software is still here.
But what we have achieve with this, is to provide a solution on how to easily, without much extra work and tooling:
- store this data – just use REUSE.software as in every other programming language; and
- provide this data – serve the results in
<link rel="license">and<a rel="license">
Of course, this still leaves work to actually mark all the front-end code with REUSE/SPDX tags, but at least that is fairly easy to do and has a growing following in both the community and industry alike.
So, please, consider this as a call for tagging your web front-end code with REUSE.software. It really is quite easy, I promise!
Size of the website¶
How does this proposal affect the size of the website and the speed of its loading, you wonder?
I have not done any tests this time round, but unless I heavily misunderstand how HTML (and HTTP) work:
- the minified JS/CSS itself will not increase a bit;
- you can tweak the “speed” of your webpage loading by setting the
fetchpriorityattribute to eitherlow, if you prefer the page to load faster but and OK with the risk; orhighif you are risk averse and OK with the page loading slower.
Also see the file-size analysis in my previous blog post on this topic for some actual PoC and tests.
Conclusion¶
I think we finally cracked it!
This is the plan.
The building blocks already exist.
Now we just need to build it together – each in their own little corner of the web, little by little :)
hook out → well, that was a long journey…
P.S. If you were part of this project and wanted to be attributed, please let me know. Since a lot of it was done in meetings under the Chatham House Rule, I did not attributed without explicit agreement.
Also known as “browser-side” JavaScript/CSS. ↩
In fact, SPDX’s Annex H: Specifying SPDX information in source files (a.k.a ”SPDX File Tags”) is there because of REUSE and was developed alongside the version 2 of REUSE specification. ↩
In case you are looking for a simple tool to generate SBOMs from a REUSE-compliant code base, the easiest way is to simply use REUSE’s own
reusetool. For more tooling suggestions check out Open Source Tooling for Open Source Compliance. ↩For example, you could use the ScanCode toolkit to generate an “attribution” file or FOSSology to generate a “notice“ file. ↩
Arguably, this is the more important part. ↩
IMHO, a much bigger loading speed increase could be achieved, by just not bundling everything and the kitchen sink in the JS “required” to parse a website, but what do I know … ↩
The example also uses an SBOM that is completely unrelated to this website too. It is just for demonstrative purposes. I also did do the
<head>part, as I did not want to make my blog show bogus licensing info everywhere. ↩
GSoC
