1

A customer asked me to add a (fairly generic monitoring and notifications) functionality to the in-house solution he has assembled on top of JBoss and couple of GPL-licensed components (downloadable from the open source vendor as EARs). I am using JMS and JMX to communicate with these components. Do I have to provide the source and redistribution rights to my customer to satisfy GPL restrictions? In other words, does configurable code that uses JMX and JMS mechanisms constitutes a derivative work? I would actually prefer to open source my code, but part of it relies on a patented third party logic that is unwilling to GPL it, but would gladly supply it to this customer. I am not asking for a legal advice, just for the opinion in terms of best practices / fair use.

1

Charging money has nothing to do with it. Your real question is Do I have to provide the source and redistribution rights to my customer to satisfy GPL restrictions? In other words, does configurable code that uses JMX and JMS mechanisms constitutes a derivative work?

It's a gray area. The FSF considers the manner in which one communicates with the GPL code relevant to its declaration as a derived work, but they are not specific about the manner in which that decision can be made, other than to say that the two programs must communicate "at arm's length," and that it must be apparent that the GPL program is not part of your work.

The relevant part of the GPL FAQ is here:

I'd like to incorporate GPL-covered software in my proprietary system. Can I do this?

In many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.

If people were to distribute GPL-covered software calling it “part of” a system that users know is partly proprietary, users might be uncertain of their rights regarding the GPL-covered software. But if they know that what they have received is a free program plus another program, side by side, their rights will be clear.

  • Thanks! I think, I can keep it closed source, in this particular case. My program (regardless of packaging, .ear or .dll does not matter) provides generic monitoring and sends notifications if certain criteria are met. It does not rely on these particular components to function and can be described as a generic J2EE module for monitoring/notifications purpose. It can be used with any other J2EE app server and JavaBeans, if they meet certain logical and broad requirements. Even more, I do not re-distribute or otherwise provide GPL-ed software with my package, only test with it. – Alex Pakka May 2 '13 at 3:44
  • Indeed. Using JMX or JMS to communicate is an irrelevant detail. Open source and closed source communicates all the time via HTTP, and the FSF has no problem with that. As long as the protocol is a standard protocol, it doesn't matter which protocol you use. – MSalters May 2 '13 at 14:12

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.