Add license information to aggregated assets

I checked every License link and they are valid working links with license info.

1. +++ b/core/core.libraries.yml
   @@ -279,18 +295,30 @@ drupal.vertical-tabs:
   +    name: GPL2
   

   GPL2 should be "GNU-GPL-2.0-or-later"

2. +++ b/core/core.libraries.yml
   @@ -342,7 +386,11 @@ jquery.once:
   -  version: &jquery_ui 1.10.2
   

   At least to me looks more clear with "jquery_ui_version" than "jquery_ui"

3. +++ b/core/core.libraries.yml
   @@ -667,6 +752,10 @@ matchmedia:
   +    remote: https://github.com/Modernizr/Modernizr/blob/v2.6.2/readme.md
   

   Maybe direct link? http://www.modernizr.com/license/

4. +++ b/core/core.libraries.yml
   @@ -674,6 +763,10 @@ modernizr:
   @@ -691,6 +784,9 @@ picturefill:
   

   Missing license info for picturefill and matchmedia ?

5. +++ b/core/includes/theme.inc
   @@ -2082,6 +2082,14 @@ function template_preprocess_html(&$variables) {
   +      '#markup' => l(t('JavaScript license information'), 'system/jslicense', array('attributes' => array('rel' => 'jslicense', 'class' => 'hidden'))),
   

   A link in every page? This is excessive IMHO, but at least is hidden (although the rules are: (copy/paste) "This link can be small, but it should be clearly visible to people who visit your site.".

6. +++ b/core/lib/Drupal/Core/Asset/LibraryDiscovery.php
   @@ -249,6 +258,13 @@ protected function buildLibrariesByExtension($extension) {
   +          if ($type === 'js' && !$library['license']['gpl-compatible']) {
   

   This is excessive IMHO. Does this means that every js library that does not have the 'gpl-compatible' tag will affect negatively the performance of the site? What about non-external libraries, like drupal-ajax ? Are they bundled together?

2. Indeed +1 the renamed the YAML alias to "jquery_ui_version". (I understood the opposite by mistake)
And, yes, I really like this patch and the motivation behind, in the meanwhile doesn't affect negatively the performance. Thank you for working on this.

Looks good. Two minor questions ...

1. +++ b/core/includes/theme.inc
   @@ -2059,6 +2059,14 @@ function template_preprocess_html(&$variables) {
   +
   +  // On each page that uses JavaScript, add the mandatory JavaScript Web License
   +  // Labels link.
   +  if (count(drupal_get_js('header')) || count(drupal_get_js('footer'))) {
   +    $variables['page_bottom'][] = array(
   +      '#markup' => l(t('JavaScript license information'), 'system/jslicense', array('attributes' => array('rel' => 'jslicense', 'class' => 'hidden'))),
   +    );
   +  }
   

   A render array is better added in hook_page_build() IMO but it is a minor distinction.

2. +++ b/core/modules/system/lib/Drupal/system/Tests/Common/JavaScriptTest.php
   @@ -38,6 +38,11 @@ public static function getInfo() {
   +
   +    // Ensure the system.javascript_license_web_labels route is available.
   +    $this->installSchema('system', array('router'));
   +    \Drupal::service('router.builder')->rebuild();
   +
   

   Why is this needed? Do we really start tests without a router table?

1. +    name: MIT
   +    name: Public Domain
   +    name: GNU-GPL-2.0-or-later
   

   Hm. This adds many custom license names, for which no schema/definition/documentation seems to exist.

   For example, you've added "Public domain", but that doesn't exist on http://www.gnu.org/licenses/javascript-labels.html

   At minimum, I think we need to add a license name validation to the processing code (throwing an exception when encountering an unknown license name).

2. +    remote: https://github.com/jashkenas/backbone/blob/1.1.0/LICENSE
   

   The existing 'remote' key name refers to a "git remote repository".

   This isn't a remote, it's just a 'url'.

   I also wondered whether it shouldn't be 'source', which would be in line with http://www.gnu.org/philosophy/javascript-trap.html#AppendixA, but I guess 'source' might be confusing...

3. +    gpl-compatible: true
   

   I wonder whether this key is really necessary?

   Why can't we derive that flag automatically from the license name?

4. +    name: GNU-GPL-2.0-or-later
   +    remote: http://malsup.github.com/gpl-license-v2.txt
   +    gpl-compatible: true
   

   The issue summary states that GPLv2+ is the default, because it's Drupal's overall license, so why are we specifying it?

5. +    name: GNU-GPL-2.0-or-later
   

   All of composer.json, package.json, and bower.json have a license key in their schema.

   I wonder whether we shouldn't use the license names of those much more common schemata instead and translate them into JSLWL identifiers?

1. +++ b/core/lib/Drupal/Core/Asset/JsCollectionOptimizer.php
   @@ -81,11 +91,13 @@ public function optimize(array $js_assets) {
        // Now optimize (concatenate, not minify) and dump each asset group, unless
        // that was already done, in which case it should appear in
   -    // system.js_cache_files.
   +    // system.js_optimized_aggregate_files (but also the unoptimized equivalent
   +    // in system.js_unoptimized_aggregate_files, for JavaScript Web License
   +    // Labels compliance).
   

   The added comment doesn't read very easily, or is it me?. There is no verb. Changing "but also" to "and also" sounds better?

2. +++ b/core/modules/system/lib/Drupal/system/Controller/AssetLicenseInfoController.php
   @@ -0,0 +1,158 @@
   +        $license_column = l($library['license']['name'], $library['license']['remote']);
   

   still 1 more "remote" left

About sun's 4. By using license 'name' in core, we give example to contrib. Also, what if Drupal changes to GPL3 at some point? But no strong opinion here.

I think we should explicitly add licenses for external libraries even if it's GPL2, otherwise you're left wondering.

Its unclear to me if there are UI changes. None are visible, but we do add a page?

The state entry can't necessarily be relied upon - at least the proposal to aggregate based on libraries in #1014086: Stampedes and cold cache performance issues with css/js aggregation would remove the need to write aggregates to state since we could determine the aggregate to serve based entirely on URL. Even if we don't fix that in core before 8.0.0, the system is pluggable (i.e. agrcache and advagg both swap it out for 7.x already and neither use the core aggregate variable).

@Bojhan yes this will add a page, and possibly a visible link to that page on every other.

It sounds really bad to me that incompatible licenses should not be aggregated together in one file and causing several http requests in a browser. That may makes me setting a non-gpl libs as true just to make it compressed in one file. The intention of #156124: JS and CSS aggregation deletes license information was to keep the license above the code (remote value). Performance is more important.

We also do not care about CSS framework licenses for many years and just remove all comments (including the license comments). This cannot be a blocker for JS minification. Otherwise we need to remove CSS aggregation also as long as this feature is in. The ONLY reason why we have removed JS minification from core in past was that *valid* JS code has been destroyed by the minification.

I can search for the case ID if this is of interest.

There is one thing I cannot find in the patch. How can I define that the file is already a minified version? In case a file is already minified it is a waste of cpu to double minify them. I think we need to combine them in such a case only.

I'm sorry to say, but you are wrong. Check out the assets folder. Ckeditor, html5shiv and others are minified. I also think it's wrong to use UglifyJS in all cases as the maintainers of libs have made extreme tests with several minifiers and decided for the best from their test results, latency, ux and other reasons. If you get this in here without such a "disable" directive we will double minify a lot of code.

I have not seen these minifier code, but minifying 5mb js code on the fly sounds like a crazy task to me. Isn't UglifyJS not a nix only tool, too? This is a showstopper to me.

I'm happy with the patch. Only got a few comments:

Having a (hidden) link at the bottom of the page is not great, especially because I'm guessing people will end up blacklisting /system/jslicense in their robots.txt (because it gives away most of the modules used on the site (security issue too maybe?)).

Having a <link rel="jslicense" href=""> would serve the same purpose. I'm reaching out to the relevant mailing list to know what they'll say.

Other than that the PHP looks good to me, not that I'm a great judge for that :D

Looks like the link stuff instead of the a tag is supported by the librejs firefox extension http://lists.gnu.org/archive/html/help-librejs/2014-02/msg00004.html (and at least unofficially supported). Couldn't get a definite yes/no for now but I say let's just go with <link>

Our way to add [link] tag is ugly but thats not invented here. All feedback has been addressed. PHP code looks good.

Needs a reroll

git ac https://www.drupal.org/files/issues/js_license_web_labels-2258313-31.patch
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 17065  100 17065    0     0   104k      0 --:--:-- --:--:-- --:--:--  130k
error: patch failed: core/modules/system/src/Tests/Common/JavaScriptTest.php:32
error: core/modules/system/src/Tests/Common/JavaScriptTest.php: patch does not apply

1. <tr id="core-assets-vendor-ckeditor-ckeditorjs" class="odd">
     <td><a href="http://drupal8alt.dev/core/assets/vendor/ckeditor/ckeditor.js"><code>ckeditor.js</code></a></td>
     <td><a href="https://github.com/ckeditor/ckeditor-dev/blob/887d81ac1824008b690e439a1b29eb4f13b51212/LICENSE.md">GNU-GPL-2.0-or-later</a></td>
     <td class="priority-medium"><a href="http://drupal8alt.dev/core/assets/vendor/ckeditor/ckeditor.js"><code>ckeditor.js</code></a></td>
   </tr>
   

   I'm not sure this row is correct - if I understand https://www.gnu.org/licenses/javascript-labels.html correctly the third row should be a link to a non minified - source code version of the javascript. Maybe the libraries info needs to have a link we can use here.

2. +++ b/core/lib/Drupal/Core/Asset/JsLicenseWebLabelsAnnotator.php
   @@ -0,0 +1,53 @@
   +      throw new \Exception('Only file JavaScript assets can be optimized.');
   ...
   +      throw new \Exception('Only file JavaScript assets with preprocessing enabled can be optimized.');
   

   Exceptions should not have fullstops and should we be using the general exception class here?

3. +++ b/core/lib/Drupal/Core/Asset/JsLicenseWebLabelsAnnotator.php
   @@ -0,0 +1,53 @@
   +    // Generate a prefix to be prepended to the "optimized" asset (no actual
   +    // optimizations are made; this is a no-op optimizer) that deep-links to the
   +    // license information on the JavaScript License Web Labels page.
   +    $url = $this->urlGenerator->generateFromRoute('system.javascript_license_web_labels', array(), array('fragment' => drupal_clean_css_identifier($js_asset['data'])));
   +    $prefix = "/** JavaScript asset: " . $js_asset['data'] . '; for license information, see ' . $url  . "  **/\n\n";
   +    return $prefix . file_get_contents($js_asset['data']);
   

   We seem to be lacking test coverage of this.

4. +++ b/core/modules/system/src/Controller/AssetLicenseInfoController.php
   @@ -0,0 +1,182 @@
   +use Drupal\Component\Utility\String;
   

   Not used

5. +++ b/core/modules/system/system.routing.yml
   @@ -418,3 +418,11 @@ system.admin_content:
   +system.javascript_license_web_labels:
   +  path: '/system/jslicense'
   

   We have no test that tests this route - afaics.

edit: fix html

Rerolled last patch.

1. +++ b/core/lib/Drupal/Core/Asset/JsLicenseWebLabelsAnnotator.php
   @@ -0,0 +1,53 @@
   +      throw new \Exception('Only file JavaScript assets can be optimized.');
   ...
   +      throw new \Exception('Only file JavaScript assets with preprocessing enabled can be optimized.');
   

   Would be slightly more semantic to throw an \InvalidArgumentException here

2. +++ b/core/modules/system/system.module
   @@ -626,6 +626,12 @@ function system_page_attachments(array &$page) {
   +  // Add the JavaScript Web License Labels link to all pages.
   

   If we don't send any JavaScript at all (i.e. for anonymous users), this shouldn't be added either, right?

changing to use the more common tag, so the less common one can be deleted, so it does not show up in the auto complete and confuse people.

I just want to confirm a couple of items:

1) Is it now resolved so that all JS can be aggregated in one file regardless of license type?

2) Have we verified that having the link element to the JS license won't result in a file download?

Those seem like two key things for front-end performance with this issue.

While that is true, I think this is still worth working on in 8.0.x, since:

a) It's an enabler for a performance improvement, and we need more of those. ;)
b) (raised today by nod/jhodgdon) If we try and do JSDoc, without this we're going to bloat the size of JS files unnecessarily.

Doing that. :)

While it'd be cool, let's not expect wimleers to fix all our bugs.

Maybe we can clone Wim Leers and then he could fix all the bugs?

Rerolling again

WIP reroll.

The changes to template_preprocess_html() didn't apply as it has changed substantially since 8.0.0-beta11. I've attached one file of the rejected changes to the theme.inc file and another with beta11's template_preprocess_html with the patch applied, so it can be seen in context.

Might someone who knows the JS aggregation code be able to take a look at re-applying the missing template_preprocess_html() change? Thanks.

By the way, I did a very minimal port of https://www.drupal.org/project/librejs from Drupal 7 to Drupal 9. So far, it's missing much of the functionality of the Drupal 7 version, like allowing administrators to configure the license and source code URL of JS resources. However, at least it does grab the license and source metadata of each JS resource automatically from core library services, which is a nice starting point, and if anyone's interested they can add/restore more functionality... :)

Coming here from #1014086: Stampedes and cold cache performance issues with css/js aggregation and #3301573: Remove the aggregate stale file threshold and state entry.

I'd like to remove the state entries for js and css assets, since it's no longer necessary for the implementation at all. However this means that the implementation in this issue would be broken.

However, I can't see why the complexity added here is necessary at all.

From https://www.gnu.org/licenses/javascript-labels.html:

Add a page for JavaScript license web labels to your site. You can use whatever path or filename is most convenient for you; others will find it through links. The page must include one table marked with the attribute id="jslicense-labels1". This name lets automated tools find the table easily, and tells them what format to expect. Each row of this table will contain three cells, providing information about a standalone JavaScript file used on the site, its license, and how visitors can obtain its source code.

This isn't saying you need to provide a list of every aggregate on the website, it's saying you need to provide a list of every standalone file on the site + a link to its source code.

So I think what is necessary is actually this:

1. Add license + source code link to every asset in a library definition.
2. On the weblicense page, list the standalone js file in core (i.e. what the library definition includes), the license, and a link to the source code.

For files that we include pre-minified in core (like ckeditor), we'd need to link to an unminified version of the file (either one we include or to the repo).

The fact that we'll be bundling files together and minifying them is irrelevant to the fact that this page will list every file that's used on the site - which it still will because we'll be getting it from the library definitions.

Should also make the page itself a lot easier to read for humans.

The LibreJS browser extension did require aggregated/bundled JS to be listed, as it would only load JS files that were listed (as free software) on the jslicense page. However, I have no idea if anyone uses that extension nowadays.

The LibreJS browser extension did require aggregated/bundled JS to be listed, as it would only load JS files that were listed (as free software) on the jslicense page.

Since core doesn't implement a jslicense page, everything would already be broken for someone using that extension, even if serving unminified, unbundled core JavaScript. I think we need to meet the licensing requirements but not a particular technical implementation that's not friendly to humans.

Added reroll of patch #55 on Drupal 9.4.x.

It seems like there are alternative methods to declare the licence, where a dedicated page is not necessary, see The "other" section of https://www.gnu.org/software/librejs/free-your-javascript.html#magnet-li...

as stated in the JSWL page the table is a good solution in the following situation (emphasis mine):

If you are a webmaster deploying minified JavaScript on a site, here's a method for stating their licenses and source code locations without altering the minified (or aggregated in our case) files themselves. It's especially helpful in cases where the JavaScript is under one of the GNU licenses, but does not include the additional permission proposed in Section 3.2 of Setting Your JavaScript Free, by Loic Duros.

I don't have a problem with messing with the aggregate contents and wrapping an already minified code with a license comment such as

// @license [magnet-link] [human readable name of the license]
... JS code
// @license-end

That avoid many problems with declaring a new route, hidden link, new meta etc. it's directly in the file. That would make aggregated JS more compliant that non aggregated JS too (since libs like shepherd don't put their license in the minified version).

Also librejs is a tool that prevent the execution of "non-free" javascript, and they explicitly state that it's not for security purposes (see disclaimer in https://www.gnu.org/software/librejs/manual/librejs.html), or even checking that the licences are properly declared. It's simply to not run code that is not "free". Anyone is free to use it but I don't think we should bend over backwards to ensure that it's working with that extension.

// @license [magnet-link] [human readable name of the license]
... JS code
// @license-end

This looks like a good option to me, easy to wrap the file contents in the optimizer.

#2276219: Asset libraries should declare their license added the license information to the library rather than the file, but aggregation deals with files (derived from libraries), usually this is fine but it's not guaranteed to be. If a library was combining assets with two different licenses, maybe that should just be two libraries and we don't worry about it? Do we need to go back through the library definitions and add magnet links?

I wouldn't worry about having files with different licences in the same library, if that's the case the rest of the metadata is probably wrong too, such as the version

Fixed Drupal CS issues of patch #72.

@ravi we're going to change the direction of the patch, there is no need to reroll the previous one as we won't be using that approach.

The magnet-link part of the spec seems kinda wonky (ah, gnu). To streamline everything for library authors, they could be automatically added by core based on the license identifier?

The original solution can't work since we aggregate files with different licenses. like jquery is MIT and our code is GPLv2 and they're in the same file, so we need to use inline license declaration, which makes things easier for us so yay.

I ignored the whole magnet part like you said it's kinda wonky and I don't see the real value, we have the URL to the actual licenses if necessary. I checked the librejs code to see how it'd work and they hardcode the possible licenses and associated "valid" URLs here https://git.savannah.gnu.org/cgit/librejs.git/tree/license_definitions.j... So the SPDX identifier is not enough for this extention, but it is enough for humans

Went with /* */ type comments so that JS and CSS license comments end up the same.

A version adding the license URL to the license comment.

In addition, it sounds like LibreJS cannot handle multiple @license tags per script, as they say "Please note that no code or comment should be added to the script after the // @license-end comment. However, whitespace is allowed."

oh right, well, let's simplify all this a bit then. Removed the @license-end part

to come back to #74

If a library was combining assets with two different licenses, maybe that should just be two libraries and we don't worry about it?

Turns out this is already the case in core, as we include jQuery UI files in a Drupal library (dialog/autocomplete) so we have files with GPLv2 and MIT in the same library definition. jQuery UI keeps some license information in all their files so things are still accurate. Since we already covered the fact that existing automated tools won't be able to understand our aggregate I don't think we should care much.

Dialog and autocomplete are an anomaly in 10.x since we explicitly munged everything together to deprecate the jQuery UI libraries. Given we'd normally have separate definitions seems fine to make that assumption. Especially since jquery ui has the license info anyway.

The inline version of this seems really straightforward and a good way to do it.

fixing tests

need to update deprecated code path

1. fixed
2. fixed
3. Went a different way, the problem is when processing @import rules in the CSS optimizer. Adding a leading "\n" would start all js and css with a blank line. probably safe but you never know, i personally don't like starting with a blank line in those files.
4. added a new method to test the licenses specifically.

we're not actually implementing js web labels as defined (we don't have the magnet links) so renaming the issue.

What do you think about also adding the "remote" URL, as it provides access to the source code for minified JS?

I think it's out of scope, we link to the project license, which is a link to the source code itself, so we're kinda giving the repo link implicitly.

also remote is outside of the "license" key in the libraries, so that would mean adding additional informations to the individual asset array.

Addressed comment #95.1

1. +++ b/core/lib/Drupal/Core/Asset/JsCollectionOptimizer.php
   @@ -124,7 +124,14 @@ public function optimize(array $js_assets, array $libraries) {
                  foreach ($js_group['items'] as $js_asset) {
   +                // Ensure license information is available as a comment after
   +                // optimization.
   +                if ($js_asset['license'] !== $current_license) {
   +                  $data .= "/* @license " . $js_asset['license']['name'] . " " . $js_asset['license']['url'] . " */\n";
   +                }
   +                $current_license = $js_asset['license'];
                    // Optimize this JS file, but only if it's not yet minified.
                    if (isset($js_asset['minified']) && $js_asset['minified']) {
   

   Shouldn't this only be added if the asset is unminified? Otherwise if the minified file has it anyway, we might be adding it twice?

   But then if minified files don't include it, it's adding missing information.

   So.. no idea tbh but better ask.

2. +++ b/core/lib/Drupal/Core/Asset/JsCollectionOptimizerLazy.php
   @@ -172,7 +172,14 @@ public function deleteAll() {
        $data = '';
   +    $current_license = FALSE;
        foreach ($group['items'] as $js_asset) {
   +      // Ensure license information is available as a comment after
   +      // optimization.
   +      if ($js_asset['license'] !== $current_license) {
   +        $data .= "/* @license " . $js_asset['license']['name'] . " " . $js_asset['license']['url'] . " */\n";
   +      }
   +      $current_license = $js_asset['license'];
          // Optimize this JS file, but only if it's not yet minified.
          if (isset($js_asset['minified']) && $js_asset['minified']) {
            $data .= file_get_contents($js_asset['data']);
   

   Same question here.

+++ b/core/tests/Drupal/Tests/Core/Asset/css_test_files/css_license.css.optimized.aggregated.css
@@ -12,3 +14,8 @@ body{margin:0;padding:0;background:#edf5fa;font:76%/170% Verdana,sans-serif;colo
+body{margin:0;padding:0;background:#edf5fa;font:76%/170% Verdana,sans-serif;color:#494949;}.this .is .a .test{font:1em/100% Verdana,sans-serif;color:#494949;}.this
+.is
+.a
+.test{font:1em/100% Verdana,sans-serif;color:#494949;}some :pseudo .thing{border-radius:3px;}::-moz-selection{background:#000;color:#fff;}::selection{background:#000;color:#fff;}@media print{*{background:#000 !important;color:#fff !important;}@page{margin:0.5cm;}}@media screen and (max-device-width:480px){background:#000;color:#fff;}textarea,select{font:1em/160% Verdana,sans-serif;color:#494949;}

This looks like duplicate CSS added to the file? Is this a bug? I don't see where this is otherwise added to a test case.

#97 Minified version don't all include license, see once, jquery, loadjs, or shepherd minified files. CKE5 include copyright info, not license info in their minified files. So it doesn't hurt to always add it to be sure. Also our CSS minifier removes all comments, including license info that we have in normalize.css so we need to add it back or change the optimizer. This ensure a standard way of declaring the license too instead of relying on the third party.

#98 it's a test file that only serve to ensure the aggregation works as expected. It doesn't matter what the content are, that threw me off a bit at first too. The import part of this file is the 2 different licenses being shown in the aggregate. for simplicity I used the same file and declared a different license because I already had the minified version of that css file on hand.

Re #98 I see now that it's a brand new test case and that file is just reusing parts of an older test case, the explanation makes sense.

still need a RTBC :D

porting issue credit from a bunch of duplicate issues.

Sorry, should have done that in #100 :)

+++ b/core/lib/Drupal/Core/Asset/CssCollectionOptimizerLazy.php
@@ -160,7 +160,14 @@ public function deleteAll() {
     $data = '';
+    $current_license = FALSE;
     foreach ($group['items'] as $css_asset) {
+      // Ensure license information is available as a comment after
+      // optimization.
+      if ($css_asset['license'] !== $current_license) {
+        $data .= "/* @license " . $css_asset['license']['name'] . " " . $css_asset['license']['url'] . " */\n";
+      }
+      $current_license = $css_asset['license'];
       $data .= $this->optimizer->optimize($css_asset);
     }

Only question I had here was whether we should be doing this inside CssOptimizer instead of CssOptimizerLazy, for example in ::processFile(). However, for JavaScript preprocessing and minification are separate (i.e. we only run JsOptimizer on non-minified files), so... answered my question and the collection optimizers are the right place.

Committed 53a59af and pushed to 10.1.x. Thanks!

This is theoretically backportable to 9.5.x/10.0.x, but it'd need a re-roll due to aggregation class changes, so I think it's easier to leave in 10.1.x since the issues it blocks will only land in 10.1.x too.

It seems to me that this issue/fix does not address the problem of providing end-users with a reference to the source code for the aggregated GPL'd asset files.

Can someone please confirm that this is still an outstanding issue?

As such code is "distributed" by necessity (to the end-user's machine, where it is executed), GPL'd javascript must also provide the user with access to the source code, and minified and/or aggregated derivatives are not sufficient for that requirement (the GPL defines source code as the preferred form of the work for making changes in it).

Section 3.2.4 "Stylized comment" near the bottom of https://www.gnu.org/software/librejs/free-your-javascript.html recommends the use of a @source indicator in the header comment at the top of a minified JS file:

/**
 *
 * @source: http://www.lduros.net/some-javascript-source.js
 *
 * @licstart  The following is the entire license notice for the 
 *  JavaScript code in this page.
 *
 * [...]
 *
 * @licend  The above is the entire license notice
 * for the JavaScript code in this page.
 *
 */

We're using @license which sounds fine for indicating that bit; but I can't see anything in the committed change (or the files I've checked in https://git.drupalcode.org/project/drupal/-/tree/10.1.x/core/lib/Drupal/... ) for adding @source comments.

I believe a header comment for all aggregated or minified files should display a @source value for each GPL'd asset, providing access to the original source file.

I couldn't find a more relevant issue than this one, so we likely need a new issue to be raised; but this seems like the right place to ask for initial comments.

@jweowu see #94 - adding an additional source link was considered out-of-scope of this issue, but you could open a new issue.

Many libraries are built from a whole project, not just one "source file" , so I'd say the "remote" URL that is already available in the *.libraries.yml files could be used as @source - it's basically a link to "the preferred form of the work for making modifications to it" (quoting GPL).

Thank you for the follow-up, mfb. I've now raised #3321761: Aggregated or minified GPL'd assets must document a source for the original file.