Transitive dependency on an LGPL module #830
Comments
|
Why? |
|
I'm wondering if MIT license allows inclusion of LGPL module dependencies. For example, Apache projects explicitly prohibits dependencies on LGPL libraries, see http://www.apache.org/legal/resolved.html#category-x. |
|
I have no idea. That's why I'm asking. I would assume not since it's just downloaded on install time and not bundled, but IANAL. // @kemitchell |
|
https://gist.github.com/kemitchell/6a25ab437a5ce809eb84 As for MIT-LGPL compatibility, unfortunately, I can't go around GitHub handing out legal opinions, nor would I do any good passing off such opinions as "the right answers". The Apache FAQ admits more or less the same, taking pains to point out that it reflects Apache's point of view of Apache's license for Apache people on Apache projects. Whether the combination of LGPL and MIT is too risky or inconvenient is really a question for individual companies. As for respecting the expectations of |
|
Sorry, I can't change the LGPL licence of If @skeggse wants to relicense I'd probably be willing to go along. Alternatively |
|
I'd be happy to relicense! I probably licensed it wrong to begin with, I was trying to be compatible with antimatter15's original bzip.js (which has since changed to MIT). Do I just need to push an updated |
|
@skeggse That would be great! Typically, you need to push an updated LICENSE that contains the MIT license and update |
|
@skeggse and then ping me (or file an issue on cscott/seek-bzip) and I'll
follow suit.
|
|
@skeggse Any update? |
|
@raymondfeng thanks for the poke, just pushed skeggse/node-bzip@0dd3c81. |
|
I did publish a new release. |
|
Hm, not so fast: although @antimatter15 and @skeggse relicensed their contributions, as far as I can tell, Rob Landley (rob@landley.net)'s original version (from which all these have sprung) was originally and has always been LGPL. I don't think we can relicense to MIT without explicit permission from Rob Landley. |
|
Rob Landley's work, just to make the trail of contributions longer, includes the following: — http://www.landley.net/code/ under micro-bunzip And Julian R Seward is credited in the |
|
Julian Seward's license is a "BSD-like" license. It is half BSD and half zlib. It's compatible with the LGPL (Rob's chosen license) but really both licenses should appear in the distribution ("some portions are (c) Julian Seward..." with the complete Seward license). I've emailed Rob Landley, we'll see what he feels about relicensing. If he wants to stick with the LGPL, I believe the rest of us ought to (have to) do so as well. That said, I don't think there is really any problem using LGPL libraries from an MIT-licensed application. That's what the LGPL is for, after all. |
|
I read through the LGPL and GPL, and a couple of analyses of the former. I've come to the conclusion that @antimatter15, @cscott, and I must license our libraries under the LGPL (or GPL) unless Julian Seward (EDIT: I meant Rob Landley) gives permission to license our libraries under a different license. The LGPL has provisions for libraries which link to LGPL libraries: "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License." I'm going to consider an npm dependency as a form of linking, so I think decompress-tarbz2 is welcome to use any license. Anything which subsequently depends on decompress-tarbz2 can similarly use any license, provided decompress-tarbz2's license permits it - that is, libraries which depend on decompress-tarbz2 must comply with decompress-tarbz2's license, but need not comply with seek-bzip's license or micro-bunzip's license. Similarly, I don't think any module which depends on a derivative of micro-bunzip needs to worry about the license of bzip2. As such, I think this specific issue (issue #830) is no longer a concern, but those of us who have works derived from micro-bunzip need to choose a compatible license, barring written permission from Julian Seward (EDIT: I meant Rob Landley). |
|
@skeggse Julian actually used a BSD license. It's Rob who chose LGPL, and he just wrote me in personal email that he's willing to relicense. I encouraged him to repost here (or on his website) so we have a paper trail. |
|
Rob has switched to a "zero clause" BSD license. In his words:
Rob also makes clear that he is not actually using any code from Julian's implementation, so Julian's almost-BSD license shouldn't apply to our derivatives. So I think we're back to the point where we can switch to the MIT license, although we should also probably take Rob's advice to apply his fixes! |
|
so complicated |
This package inherited an LGPL license from Eli Skeggs' upstream, which had forked Kevin Kwok's upstream package (https://github.com/antimatter15/bzip2.js), also originally with an LGPL license. Kevin Kwok's code was a port of Rob Landley's C implementation, which was LGPL. Since then, Rob Landley has switched to "zero-clause BSD" (http://landley.net/toybox/license.html) when he relicensed his original code for the toybox project in 2006. Kevin Kwok switched his port to the MIT license in 2013. Eli Skeggs followed Kevin to switch to MIT, and now we can follow suite as well. See: http://landley.net/code/micro-bunzip.c (LGPL) http://landley.net/hg/toybox/file/37ea9dff9c27/lib/bunzip.c (0-clause BSD) antimatter15@e2ba119 https://github.com/skeggse/node-bzip/commit/0dd3c810c3b9341957a0a6f638369433b2e68126 yeoman/generator#830 (comment)
|
Published a new release. @kemitchell's point about missing licenses for many of the other dependencies is still valid. |
|
FWIW, we'll try to implement automatic license checking for the Yeoman projects eventually yeoman/yeoman#1523 |
|
So, are we all good now? |
npm lsfinds a transitive dependency onseek-bzipwhich is LGPL licensed . See https://github.com/cscott/seek-bzip/blob/master/package.json#L11.Is it a concern of yeoman-generator under MIT?
The text was updated successfully, but these errors were encountered: