"_": "Other keys excluded for the sake of brevity.",
"Copyright 2013 jQuery Foundation and other contributors",
"Permission is hereby granted, free of charge, to any person obtaining",
"a copy of this software and associated documentation files (the",
"\"Software\"), to deal in the Software without restriction, including",
"without limitation the rights to use, copy, modify, merge, publish,",
"distribute, sublicense, and/or sell copies of the Software, and to",
"permit persons to whom the Software is furnished to do so, subject to",
"the following conditions:",
"The above copyright notice and this permission notice shall be",
"included in all copies or substantial portions of the Software.",
"THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND,",
"EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF",
"MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND",
"NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE",
"LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION",
"OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION",
"WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
I know the name itself would need work. Also, this key should be defined per version of the package as different version will have different years in (just) the copyright line or, in some cases, I suppose completely different text if a project switches which license it is using.
I know that a "licenses" key is proposed in places like http://wiki.commonjs.org/wiki/Packages/1.1 . However, the information supplied there is insufficient because it does include the copyright/year line in the notice itself which seems like it is inseparable from the rest of the notice text (which is often a boilerplate blurb). Also, I am proposing this be at a cdnjs level because the cdnjs changeset reviewers would be able to review changesets and verify that the added libraries actually are released under the terms specified in "_cdnjs_distribution_terms" unlike the "licenses" key (about which commonjs states “This property is not legally binding and does not necessarily mean your package is licensed under the terms you define in this property.”). And, yes, this may be opposition to ideas in issue #123 to automate everything. This shouldn’t conflict with too much of #123’s goals, which are mostly to automatically notice that new library versions have been released and automatically obtain a copy of the new script itself and update the "version" key and, depending on how it’s implemented, create a pull request automatically which would need human review to check things (such as "_cdnjs_distribution_terms").