Hi Sandro, The artistic license defines the term "Package" to be the package of software to which the license is applied. Since its applied to npm, that "Package" is npm and not any package that npm happens to distribute. Further, this is clarified in the npm license towards the end of the license text with
" Data published to the npm registry is not part of npm itself, and is the sole property of the publisher. While every effort is made to ensure accountability, there is absolutely no guarantee, warrantee, or assertion expressed or implied as to the quality, fitness for a specific purpose, or lack of malice in any given npm package. Packages downloaded through the npm registry are independently licensed and are not covered by this license. " The last line of that paragraph clearly states any package distributed by npm is covered by its own license and not the artistic license used by npm. This is logical as it would be a nightmare trying to relicense software under the Artistic License that had been already licensed under one of the 100s of other licenses. For a start, no one would agree to that, as they would need to hand over copyright of the code to do it. I have been through an such a licensing exercise outside Apache. Have you seen something else that says that npm inc takes ownership of the code and redistributes under its own license ? ------------------------ Using npm in a build process is the same as using any software in a build. Apache licenses source, not binaries, and a restrictive license on a build process does not deny anyone access to the source. Putting a javascript file inside Sling source code, where the license on the source code is restrictive w.r.t the Apache License is not ok, as it would mean redistributing a restrictive license in the source code. eg jQuery is MIT licensed and presents no issues. Referencing an external library by URL pointing to a CDN is a grey area in the license is not A2 compatible and probably falls into the same category as the MySQL JDBC driver which is LGPL and therefore allows runtime linking via the javax.jdbc API. So (imho) you can use npm, but only as a build tool, you can't extend it and redistribute it in an Apache project. btw, IANAL, but I think this is what Jim was saying in http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201503.mbox/%[email protected]%3E Best Regards Ian On 19 March 2015 at 13:21, Sandro Boehme <[email protected]> wrote: > NPM is the package manager for many frontend libraries. It is comparable > to Maven with Maven Central. > > The problem is, that it is a bit (at least) unusual as the npm license > applies terms on which a npm package (not npm itself) can be "copied, > modified, distributed, and/or redistributed" additional to the license of > the package itself. See one of the first sentences here: > https://www.npmjs.com/policies/npm-license. > > While npm is not checked in it is configured to be used at build time. > > I'm not 100% sure if I distribute the packages by having them in the > bundle / standalone jar / war and pointing to them e.g. with > "<script type="text/javascript" src="path-to-package.js"></script>" or if > this is linking. For details see [1]. > > I also don't see where a package owner (e.g. jQuery) agrees on the npm > terms that will also apply to their package when uploading the package to > the npm server. > > As I didn't got any more infos from legal [2], [3] I will contact the npm > team to clarify and get an authorized answer. > > [1] - https://issues.apache.org/jira/browse/SLING-4463 > [2] - https://issues.apache.org/jira/browse/LEGAL-217 > [3] - http://mail-archives.apache.org/mod_mbox/www-legal- > discuss/201503.mbox/%[email protected]%3E > > Best, > > Sandro > > Am 03.03.15 um 12:27 schrieb Justin Edelson: > >> I agree with Robert here, but it might be worthwhile to open an issue with >> LEGAL. At minimum, that would get the question and answer documented. >> >> Justin >> >> On Tue, Mar 3, 2015 at 5:50 AM, Sandro Boehme <[email protected]> >> wrote: >> >> Hi Robert, >>> >>> yeah, that sounds good. >>> Yes, with the Frontend Maven Plugin I declare to use Node.js and npm. I >>> don't check it in. >>> The question now is just how to make sure everything is fine from the >>> legal perspective. It would be good if either someone from the Sling PMC >>> could say that it's fine the way I proposed to do it or I would like to >>> make sure that it's fine to open a legal issue at >>> https://issues.apache.org/jira/browse/LEGAL. >>> >>> Best, >>> >>> Sandro >>> >>> Am 03.03.15 um 11:26 schrieb Robert Munteanu: >>> >>> Hi Sandro, >>> >>>> >>>> On Fri, 2015-02-27 at 22:20 +0100, Sandro Boehme wrote: >>>> >>>> Hi, >>>>> >>>>> in SLING-4463 [1] I have a question about a license for SLING-4462 [2]. >>>>> Does someone has an idea on how to handle that or should I open a legal >>>>> issue [3]? >>>>> >>>>> [1] - https://issues.apache.org/jira/browse/SLING-4463 >>>>> [2] - https://issues.apache.org/jira/browse/SLING-4462 >>>>> [3] - https://issues.apache.org/jira/browse/LEGAL >>>>> >>>>> >>>> I'm not really familiar with the toolchain you're using so I might be >>>> mistaken, but as long as the tools are not checked in to source control >>>> and are not distributed we should be fine. >>>> >>>> Robert >>>> >>>> >>>> >>>> >>>> >>> >> >
