5

Say I've been working on this java project for over a year, and it's necessary for this project to reference a GNU GPL licensed software library somewhere in there, then the whole thing suddenly poof has to be GNU GPL. I get it. Software that references GNU licensed software has to be GNU as well.

What if this jar file has two functions. What if it can be loaded in via a classloader in external software, or executed. Loading it in via classloader by external software will run the source that references the GNU GPL protected libraries, and therefore that software is GNU GPL. Say it outputs a file called bob.txt and inside it says "Hi, I'm Bob".

However, executing the jar file starts up a whole different package of code that never once references any of the GNU protected code. It's a program all its own. But say it can also generate a file called bob.txt, or load in an existing bob.txt, and it gives you a nice GUI for modifying all the information about bob.

Could the classloader accessed packages of the software be licensed under GNU GPL and the executable accessed packaged given its own more restrictive license?

If the answer to that is yes, does that answer remain the same if you distribute the software compiled into a jar? Keeping in mind that a jar is really not much different than a zip?

  • Can your project be split into two completely independent parts that don't reference each other? One that is loaded through the classloader and references the GPL library and another that is executed independently. – Bart van Ingen Schenau Nov 27 '17 at 16:27
  • Yes, it would be possible to remove the executable accessed code and put it into its own jar, and both packages would function perfectly as intended. They don't reference each other at all. The closest thing that could be called "shared" is the reading and writing to a file at a location depending on where the jar is running from. Or creating a file if it's not there. – justis Nov 27 '17 at 21:09
  • However, literally doing this would avoid the question, which is me wanting to know if I can license them separately without packaging them separately. Seeing how I'm already providing the source for the GNU licensed code. – justis Nov 27 '17 at 21:17
  • Calling gpl code from your code doesn't usually require it to be gpl. If you merge gpl code into your project then it would need to be gpl. – sambler Nov 28 '17 at 8:06
  • 2
    @justis See gnu.org/licenses/old-licenses/… -- According to that, FSF considers combining programs into an executable file a combined work. A .jar file is an archive, but it could also be considered a type of executable file. To be safe, put the code you are calling in a separate file. It could be a jar file too, e.g. "my_code.jar" and "some_gpl_code.jar". – Brandin Nov 28 '17 at 12:21
2

Software that references GNU licensed software has to be GNU as well.

That's not exactly true always, but in the case of a Java app calling code from a GPL-licensed Jar in the same process, that would likely be true.

Could the classloader accessed packages of the software be licensed under GNU GPL and the executable accessed packaged given its own more restrictive license?

If this runs in the same JVM process, no classloader trick would work to try to escape the GPL, especially if this is shipped in a single JAR.

Now if you have an app bundled as a Jar that requires some class named Foo with a function named bar, then you could very much have two JARS versions of this Foo.bar and setup your classpath to use either one at runtime. When you bundle the GPL version, the whole code is eventually subject to the GPL, otherwise it may not apply.

Again in the case of the JVM, the key test for me is "same JVM process or not". And furthermore there is a presumption that this runs in the same process and is designed to so when bundling in the same JAR.

Update

They utilize separate JVM processes and do not interact with each other during runtime, but the classloader accessed code that references GPL licensed software is bundled within the same jar as the separate executable accessed code. Given this: gnu.org/licenses/old-licenses/… Would you say the statement here presumes that they share a JVM, and the fact that in my circumstance they do not makes it an exceptional case?

Even though there is no such think as static linking in the JVM, I would consider bundling GPL-licensed and proprietary code similar to static linking (or LGPL-licensed code for that matter with not so different implications).

Now in your cases you run two processes each with their own isolated JVM, therefore my advice is to have a clear separation of concerns:

  1. one JAR that embeds GPL-licensed code and only GPL-compatible code and is treated overall as GPL-licensed

  2. another JAR without any GPL-licensed code.

And run each on their own spawned in two separate processes, e.g. two different command line runs.

  • They utilize separate JVM processes and do not interact with each other during runtime, but the classloader accessed code that references GPL licensed software is bundled within the same jar as the separate executable accessed code. Given this: gnu.org/licenses/old-licenses/… Would you say the statement here presumes that they share a JVM, and the fact that in my circumstance they do not makes it an exceptional case? – justis Nov 28 '17 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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