[kemitchell]

I doubt there's any single answer that isn't tautological. In other kinds of development, like embedded programming, notice files are a part of the cycle. Web developers simply haven't developed the habit.

Which is a real head scratcher, because as a rule, JavaScript developers use JavaScript package managers, and JavaScript package managers, especially npm, provide good license metadata and auditability. You can have an automated tool, usually a plugin for your front-end bundler, compile a pretty good notice file for you, no many how many direct and transitive dependencies you have.

I think there's also a chicken-and-egg problem, in that it's not exactly clear how to make the notices file for front-end code available. Link from website footer? At the top of the client bundle? Comment at the top of the client bundle, with a URL for the notices files?

[detaro]

I've seen at least some minified/bundled JS files that neatly preserved the copyright notices for each minified blob they included.

[ignoramous]

Minifiers and obfuscators are one reason newer licenses like MPLv2 don't require minified JavaScript to carry attribution and copyright notices.

[detaro]

MPLv2 does require you to inform the recipient that the software is under MPLv2 and where to find the source code for it.

[ignoramous]

Yes, but not necessarily as part of the minified code.

> Q16: Is "minified" JavaScript Source Code?

> No. Minified JavaScript, while not an "executable" in the software engineering sense of the word, is difficult for humans to read, edit, and modify. As such, it is not "the preferred form for modification" and so it is not Source Code as defined by the license. Therefore, minified JavaScript is the Executable form, and the responsibilities set out in the license for distribution of the Executable form should be met when you distribute minified MPL-licensed JavaScript.

> This means, among other things, that you do not need to, and probably should not preserve the MPL boilerplate (which begins "This Source Code Form...") when minifying JavaScript. However, you do need to comply with section 3.2(a) by informing the recipients of the minified source how they can obtain a copy of the source code. How exactly you do this will depend on how they can obtain that copy, but one way would be to include a comment with a link to the source code in either the page which uses the JavaScript or in the JavaScript file itself.

> Note that treating minified JavaScript as an executable increases distributor flexibility by allowing MPL-licensed code to be combined into a single file with non-MPL JavaScript source code without requiring the non-MPL code to be distributed under the terms of the MPL.

Ref: https://www.mozilla.org/en-US/MPL/2.0/FAQ/

[fenomas]

> You can have an automated tool, usually a plugin for your front-end bundler, compile a pretty good notice file for you,

I think the tl;dr is that this is feasible but not common, and there's no single widely-used default way of doing it.

E.g. Many packages put their copyright/license info in special inline comments (using /! ... / tags), and every minifier I've used keeps such tags by default. But including these tags in your bundles can be undesirable - if a dependency has: /! Copyright foo@bar / without specifying the package name, then your bundle will appear to be entirely (c) that author.

OTOH the huge majority of projects do include a valid license identifier in a package.json tag (since npm complains if you don't). But I don't think there's any widely-used default way of generating a good licenses declaration from them.