Can I use JFreeChart in a commercial application?

[pbrema]

Can I use JFreeChart in a commercial (closed source) application? Do I need to pay a fee? if yes please send the details
Thanks in Advance.

[reden]

http://www.jfree.org/jfreechart/faq.html#FAQ4

[swdev]

The licensing FAQ does not answer an important question, one which arises because of the antiquity of the (L)GPL, conceived in the days of C, before OO: when we extend or override a JFreeChart class, is that custom class part of our code or does it constitute an extension of JFreeChart, subject as such to the source disclosure provision(s) of the LPGL?

[Taqua]

Hi,

you are free to call any methods, import classes or derive classes (deriving classes is just another form of calling methods, so there's nothing special about that in any way) as you like.

You have to make sure that newer or changed versions of the library can be used with your programm. (This does not cover changes where we change the API, this is meant to allow users to modify the LGPLed parts of your programm without getting problems, either through the licensing terms or technical countermeasures.)

If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application.

See the full statement for reference:

http://www.fsf.org/licensing/licenses/lgpl-java.html

Regards,
Thomas

[swdev]

Thanks for the reference but that is still obscure. The blog entry you sent me to says:

Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.

which I take to mean that classes created by inherited LGPL classes do fall under the LPGL themselves (since they are derivative work) but, as with all LGPL code, can then be "linked" to applications that merely call them w/o making these application LGPL'ed.

Meanwhile the point about reverse-engineering is either obscure, too, or else disingenuous, since the very goal of a closed app is to prevent reverse-engineering, precisely.

[Taqua]

Hi,

no it means, that "the LGPL permits this type of derivate work in the same way as it permits ordinary function calls." There is no difference (technically *and* legally) from calling a functions/methods in Java or from inheriting classes or implementing interfaces. Its all the same.

You can happily prevent reverse engeneering in *your* parts, but as soon as that reverse engineering limits prevent the user from replacing the LPGLed libraries with their own versions, you violate the license. Its aims at the common software license clause, which tries to forbid the reverse engineering for the whole programm. Hiding your secret algorithms is ok, but dont hide/protect the JFreeChart/Jcommon code.

So all I can tell you is: Yes, you can use JFreeChart in any way, either by calling code or by implementing/extending JFreeChart classes without causing your code to become LGPLed too.

Feel free to ask either your legal department and/or the FSF for a clear statement on that issue. I'm confident, they will tell you exactly the same.

Regards,
Thomas

[skunk]

There appear to be some differences of opinion between this thread and this one

http://www.jfree.org/phpBB2/viewtopic.php?t=18195

[Taqua]

Hi,

no, even plain *using* of LGPLed code requires you to offer the sourcecode for the LGPLed code.

That means: If you use JFreeChart unmodified, then you're still responsible to provide the sourcecode of JFreeChart (even if the same one can be downloaded here) and you have to tell your users about the LGPL license. Using Applets is the same as providing a binary download of a standalone application.

If the applet there created all its chart without modifying JFreeChart, then they dont have to provide *their* code. Using object oriented Java-code is not different from using object oriented C++ code. And technically, deriving classes *is* nothing more than calling methods.

The question on when using a library causes you code to become LGPLed too is bound to the question on whether you use dynamic linking or static linking.

Lets go into detail:

Static binding means, that the used library becomes an integral part of your application's binary. That means, the code from the library is copied at compiletime into the final executable. Obviously, there is no way for the user to replace the library with their own versions, and thus, they would not be able to execute their rights as granted by the LGPL. Static binding also happens, if library and executable are separate files, but the mapping of methods into addresses in the code happens at compile time. This again would bind the executable to a specific binary result and the user would not be able (with reasonable effort) to replace the LGPLed code with his own versions.

Dynamic binding means, executable (calling code) and library (called code) are held in separate files, and the resolution of method names to addresses in code happens at runtime. The user will be able to replace the library with own versions, without having to recompile the executable itself. Therefore, the user is able to replace and modify the LGPLed code whenever he wants. The executable itself does not need to be LGPLed as well (as it does not prevent the user from using the rights granted in the LGPL).

If a user, who modifies the LGPLed code changes the interface in a way that makes it incompatible with the original version, well, then that's bad luck for the user. It is always responsiblity of the one how does a modification, that this modification actually works.

Linking occurs, when the bytecode is loaded into the running VM:
http://java.sun.com/docs/books/vmspec/2 ... html#22574

Java, by its nature, always uses late binding. So you are always free to replace the library with an modified version. Thus your code is safe from the viral effect.

(Dynamic binding in Java and C++ is similiar: They also have to do a named lookup to get the actual address of the method that should be called; and for that lookup (you may have guessed it) they need a signature of the method to be called.)

But as said before: If you need a 100% safe statement about any legal issues regarding the (L)GPL, go ask your lawyer or the FSF.

Regards,
Thomas

[Taqua]

Sidenote: JBoss has a rather clear explaination too.

http://www.jboss.com/pdf/Why_We_Use_the_LGPL.pdf

Regards,
Thomas

[david.gilbert]

The licensing FAQ does not answer an important question, one which arises because of the antiquity of the (L)GPL, conceived in the days of C, before OO: when we extend or override a JFreeChart class, is that custom class part of our code or does it constitute an extension of JFreeChart, subject as such to the source disclosure provision(s) of the LPGL?

This comes down to whether your code is a "work that uses the Library" or a "work based on the Library". Section 0 of the LGPL says: A "work based on the Library" means either the Library or any derivative work under copyright law. Are your extensions of the JFreeChart classes a derivative work under copyright law (if they provide enhanced charting capabilities, they most likely are)? In that case, you need to distribute those modifications and enhancements under the LGPL.

On the other hand, if you've subclassed something simply as a means of using the features that JFreeChart already provides, then your code will fall within the definition of a "work that uses the library", and you can distribute the combined work as per Section 6 of the LGPL.

I'm sure there are plenty of "grey area" cases, but the application of some common sense can probably sort out most of them.

[david.gilbert]

So all I can tell you is: Yes, you can use JFreeChart in any way, either by calling code or by implementing/extending JFreeChart classes without causing your code to become LGPLed too.

I partly disagree on this. If your code provides additional charting capabilities, I believe this falls within the category of a "work based on the Library", which means the code is required to the LGPLed.

But if the code doesn't provide additional charting features, I think it generally would be considered a "work that uses the library", and you can keep that code to yourself, no problem.

Note that the LGPL states in Section 0:

...a "work based on the Library" means either the Library or any derivative work under copyright law...

I don't believe the linking mechanism is at all important to this definition.

[skunk]

The differences in opinion are even worse than I suspected. A clear and unambiguous statement of "where is the line" seems to me to be far more important than all the technical information on this forum.

[swdev]

David Gilbert's answer is the one that makes sense to me. It further implies that if you extend JFreeChart classes to create new charting functionality, as I do, then you must carefully segregate them from the rest of your code (that is, in their own package and jar) lest your entire code base should be contaminated.

A clear and unambiguous statement of "where is the line" seems to me to be far more important than all the technical information on this forum.

This is a vain hope on two counts. First, licenses with ambitious goals like the (L)GPL are by necessity highly technical. Second, you won't get "unambiguous statements" on the LGPL from anyone, anywhere. I was interested in knowing the author's position (otherwise I would have enquired directly on some FSF-run forum) because in practice he is the one who'd have to start the ball rolling in the event of a violation (licenses are not self-enforcing), whether on his own or by referring the matter to the FSF, and that makes his own take on the issue important but the truth is that only jurispudence (the more the better) derived from actual judgements in a court of law could "fix" the meaning of the (L)GPL or of any license, for that matter. Until then we're all speculating and that includes even Stallman and his lawyers: they could only tell you what they wished the LGPL to say when they crafted it, not what it actually says.

Now you see why so many people just hate the GPL: even leaving aside its politics, it's a gnarly, complex license and for all that it is also an exercise in pure futility since nobody can know what it says!

[Taqua]

Well, the GPL is fairly simple: No matter what you do with the code - it infects and there is no way around it. The GPL has been proven in court in Germany several times.

The LGPL, however, is a completely different chapter (and a rather sad one). But among the available licenses, it is the one that makes sure that changes flow back and dont get locked away in proprietary products.

Separating code is surely a good idea anyway - and if JFreeChart has a lack of features and your code fixes it - then contributing it back is surely a good idea

The ambigous wording of the current LGPL is the reason why I pray for the day, when the LGPL v3 is released (I'll switch JFreeReport to that at the very same day). It has a clearer wording on what is allowed and what not.

[david.gilbert]

A clear and unambiguous statement of "where is the line" seems to me to be far more important than all the technical information on this forum.

There are so many different ways that people integrate JFreeChart into their applications that it is very hard to give one statement that covers all cases. But in general, if you extend JFreeChart to provide additional charting capabilities, I consider those to be modifications to the library that should be released under the LGPL. Any other code (business logic, glue code, GUI, etc) that is part of your application, you are most welcome to keep to yourself.