Tinder is licensed under the Apache 2.0 now.
But, Tinder depends on Libidn which is licensed under the LGPL.
Now, I have a question.
Does the software which uses Tinder need to comply with the LGPL?
In other words, does the software need to follow the requirements in section 6 of the LGPL?
As I understand it: no, you don't need to release your software under the LGPL license if that software uses LGPL libraries. There is a distinction between GPL and LGPL here.
Tinder can be characterized as a "work that uses the Library" as defined in the LGPL. The LGPL (v2.1) reads in section 6:
you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
As I understand it, we do allow this.
Additionally, the Why you shouldn't use the Lesser GPL for your next library article on gnu.org indicates that you can use LGPLed software in non-free programs:
using the Lesser GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs.
As LibIDN is released under the LGPL, it can be used in proprietary programs.
Thank you for your reply.
Yes, I know that I don't need to release the software which uses LGPL libraries under the LGPL license
and I can use LGPL libraries with proprietary programs.
But the software needs to follow the requirements in section 6 of the LGPL.
In "The LGPL and Java"
FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java. Applications which link to LGPL libraries need not be released under the LGPL. Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this.
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. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that—people who modify the library are responsible for making it work.
Then, I want to know that the software, which depends on Tinder, needs to follow the requirements in section 6 of the LGPL or not?
I think this case is not clear in LGPL and "The LGPL and Java".
I am at a loss what to do.
Please give me a piece of advice.
Section 6 of the LGPL reads:
(...) you may also compile or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
Note the "under terms of your choice" part in the above quote. Although I'm not an expert, I simplify this as:
OK. This is my conclusion for now.
When I distribute only a jar file of application without Tinder and libIDN, I don't need to comply with the LGPL.
The users must get the requirements separately.
When I distribute the zip file (like war) includes Tinder and libIDN, I think I must comply with a part of LGPL.
Because, in Section 5
However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.
It's hard for me...
I sent e-mail to email@example.com.
And I received a reply saying that I need to comply with all of the relevant licenses, including the LGPL.
(He is not a lawyer. So it is not legal advice.)
It's bad for me.
So, I think an another solution.
There is another Stringprep implementation lisenced under the Apache License.
It's not a pure Stringprep library, though.
It is part of the Apache MINA Vysper.
I'm considering using this code in place of LibIDN.