Can I include an LGPLv2.0-licensed XSLT stylesheet into my Apache v2.0-license nodejs package?

Question

I am creating an open source tool which leverages some XSLT stylesheets in order to do its work, which is transforming XML to Java code. One of the stylesheets that I want to use is licensed under LGPL v2.0. My tool will be license under the Apache License v2.0.

I read somewhere that if you link your Apache-licensed program to an LGPL library dynamically, it's ok. I see the link between my program and the stylesheet as dynamic, since it only depends on a filename and could easily be replaced with a different stylesheet by replacing a single file.

Can I infer from this that it's OK to use LGPL XSLT stylesheets or am I making an error in judgement here?

• The file would be included in the nodejs package project directory

  • the package would be distributed through npmjs.org.
  • my own source files would be in lib/ (e.g. lib/transform.js), licensed under ASLv2.0.
  • the stylesheet would be in xslt/' (e.g.xslt/java/xml-to-java.xslt`) licensed under its original license (in this case LGPLv2.0).
  • the program does not provide an interface to change the used stylesheet, but the user has to go into the filesystem, look for the install directory of my package and manually replace the file with another if so desired.

• The file provides essential functionality to the program

  • my own stylesheets convert to a format that this stylesheet understands
  • without it, I would have to provide a stylesheet with the same behavior (same input format, same output format).
  • So basically my program delegates the last transformation phase that is part of my program's behaviour.

To be clear: the file that I am trying to include into my package may retain its original license, I am only interested in adding its functionality to my program, because without it, my program loses so much of its functionality that it becomes useless. The reason I'm asking this question is that I want to distribute the file along with my project, because I would like my tool to work out of the box, not have the user download the xslt separately from the developers website.

Answer 1

The LGPL effectively requires that it must be possible for the user of your program to replace the LGPL-licensed parts with versions of his own and still have a functioning program (provided that the new versions are interface-compatible).

If your program reads the LGPL XSLT stylesheet as an external file at runtime (as in, the XSLT file is distributed as a separate file), then the requirement of user-replaceability has been fulfilled.
Furthermore, if your program only requires that there exists a file "foo.xslt" in a certain folder, then it can even be argued that the XSLT stylesheet is not actually part of your program but just mere data. In that case, the application and stylesheet are considered to be unrelated for copyright purposes.
Distributing them together means just that you are distributing an aggregation of multiple independent works.

Answer 2

_{I am not a lawyer. You should get one, if you are concerned about possible legal issues.}

---

It’s absolutely irrelevant what that stylesheet does and where it is stored in a package. The important question is what you mean by including something covered by GNU LGPL into a package covered by the Apache License v2.

Do you mean, that the whole package, including that XSLT, should be under ASLv2? Then no, that’s absolutely impossible regardless of how parts are combined: statically, dynamically, even if they do not interact at all but just packaged together by some reason. You basically want to grant more rights to your licensees than you obtained.

Or you are just want to assign ASLv2 to your work, that incorporates someone else's work under a GNU licence? Then I do not understand, why you are looking for problems from nothing: definitely yes, you can do that even if that GNU licence would be ordinary GPL, not Lesser.

Copyleft of GNU (L)GPL protects free/libre software from being bound with additional restrictions and becoming proprietary, not the opposite; if you want to, you are free to apply to your own part of work alone any of GNU GPL-compatible licences, which are actually either ① more permissive ones that does not prohibit sub-licensing or ② ones that explicitly allows re-licensing under GNU (L)GPL; ASLv2 is in the former category.

Now about issues, specific to certain licence’s versions. You stated that the stylesheet is under GNU LGPLv2.0. Though GNU licences allow limiting upper bound of their version when applying them, there are actually few who do it. But suppose that you did not overlook ‘or any later version’ clause in the copyright notice; that makes question more interesting, since ASLv2 is not compatible with obsolete GNU GPLv2, only with modern GPLv3.

However, GNU Library/Lesser GPL 2.x do allow re-licensing (re-, not sub-) to ordinary GNU GPL of the same or any later version regardless of whether it is allowed to bump a version of LGPL.

So, what you definitely may do is to take the stylesheet and change its copyright notice, so that it refers to GNU GPLv3+ instead of GNU LGPLv2.0=; then combine it with your your work, which is under ASLv2. But the only answer to a question ‘What terms this package as a whole is?’ would be ‘GNU GPLv3+’¹.

---

^{¹ By the way, that is not something specific to GNU (L)GPL or copyleft. For example, if you would combine software covered by 3-clause BSDL and Apache License and would want to distribute it as a whole under a single licence, you should do actually the same – choose the less permissive of them, i. e. Apache License.}

Answer 3

To determine if copyleft applies, ask yourself:

1. Is the XSLT stylesheet an integral part of the application? Will your application work without it?

2. Are you communicating with it at arms length (through a File/Open command, batch file or something similar)?

If the answer to either of those questions is no, the answer to your question is no.

Note that LGPL has a linking exception that makes it easier to incorporate libraries into your program without opening your own source, but it still requires you to distribute any changes you make to the library's source.