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.

  • Is the input format for the 3rd-party stylesheet a well-known format, or is it specific to that stylesheet? That is important to determine how closely related (in copyright terms) your work and that stylesheet are. Jan 21, 2015 at 9:32
  • The input format is specific to that stylesheet. The only thing that is specific to my program and will not change, regardless of the used stylesheet, is the output format: Java. The input format is an XML-representation of the Java AST. This XML format and the transformation to Java takes quite a lot of work to develop, something I can avoid by using the stylesheet, which is my primary motivation for using it.
    – pancake
    Jan 21, 2015 at 10:42
  • You might want to know why I don't make the transformation from my own XML format to Java in 1 go: because it's a complicated transformation and I use xspec to unit test the output. Since testing XML output using xspec is way easier than testing the Java output, I divided the process in two steps: xml -> intermediate representation (IR) and IR -> Java. I don't care about the IR format, I just want to create as few lines of code as possible to minimalize the occurence of bugs. I trust the stylesheet to have fewer bugs than something I create in the course of a week.
    – pancake
    Jan 21, 2015 at 10:47

3 Answers 3


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.

  • "reads the LGPL XSLT stylesheet as an external file" is a bit vague. You could say the same about staticly-linked libraries. Jan 20, 2015 at 19:28
  • @RobertHarvey: I have extended that statement, so it does not apply equally to static libraries. Jan 20, 2015 at 19:33
  • Thanks for responding! I have edited my question to add more information. When I apply your response (which is older than my last edit) the essential point is that I am distributing the LGPLv2.0 licensed stylesheet together*/*as part of a ASLv2.0 licensed program, which according to the stylesheet's license (LGPLv2.0) is NOT OK.
    – pancake
    Jan 21, 2015 at 8:43
  • @pancake: LGPL does not forbid distribution together with other, non-copyleft, works. Otherwise all Linux distributions would have a problem. And it is presumed that the person who wants to replace/modify the LGPL parts has sufficient skill to locate the relevant files on the filesystem. Jan 21, 2015 at 13:46

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.

  • Would downvoter care to explain? Jan 21, 2015 at 4:52
  • I don't think you understood the question. Jan 21, 2015 at 6:29
  • @RobertHarvey, hmm... I’ve re-read the question: it still contains a lot of unnecessary information and does not contain the key point (what exactly is ‘Apache-licenced program’), but I’m still sure, I understood it and gave a correct answer for two different readings. Please, explain your vote in more details. Jan 21, 2015 at 7:47
  • Thanks for responding Dmitry, I have edited my question, so its clear which license goes where. Could you reflect on that, please?
    – pancake
    Jan 21, 2015 at 8:25
  • @pancake That’s the second scenario, then. Note, that I made an assumption, that the stylesheet is under LGPLv2.0 only, which is not very probable; you’d better double-check it (give a link to that XSLT, actually). While the procedure, I described, is indeed possible, I do not recommend you or anyone else do that, it overcomplicates things to the greatest extent. Why are you insisting on ASLv2 for your work? Jan 21, 2015 at 10:45

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.

  • 1
    Those tests are too strict for LGPL, which is only weakly copyleft. LGPL code can legally be linked to non-copyleft programs, but they would probably fail the first test (can it work without the library). Jan 20, 2015 at 17:49
  • @Robert first of all, thank you for your response! Now a another question: could you point me to the place in the LGPL that contains a reference to the concept "integral part"?
    – pancake
    Jan 20, 2015 at 21:40
  • What you wrote is a good answer to a question whether it is possible to use a code, covered by GNU GPL (not Lesser), in a combination with a code under more restrictive licence. It not very relevant to Lesser GPL, and not relevant at all when the terms of another licence are more permissive than LGPL. Jan 21, 2015 at 5:03
  • @DmitryAlexandrov: Well, if the entire thing is open-source, the whole discussion about LGPL is probably moot. Jan 21, 2015 at 6:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.