-
Notifications
You must be signed in to change notification settings - Fork 933
-
Hi,
I'm wondering how the NH license model would impact a private, commercial project.
According to the brainhub.eu libraries using the LGPL 2.1 should be avoided because they are "risky".
The LGPL 2.1 summary is:
You may copy, distribute and modify the software if you license the modifications under LGPL-2.1. Anything statically linked to the library can only be redistributed under LGPL. Applications that use the library don’t have to be.
So far what I understood is: if my app only uses features provided by NH and doesn't change NH code I'm fine. Is that right? Because this "statically linked" and "application that use the library" confused me.
You that have used NH for a long time, what is your understanding regarding this?
Note: other open source libraries I use are under MIT, NH is the only one under LGPL 2.1. Is there any intention of change it to MIT?
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 1 comment 3 replies
-
NOT A LEGAL ADVICE
My own opinion and understanding how LGPL intended to work:
- You should include NHibernate's copyrights into appropriate place in your application or library
- If you modify NHibernate or use part of it's code and redistribute it, then:
- you should make source code of the modified version/part available to the users
- you should clearly mark the modifications in the source code
- you cannot charge money for the modified version/part
- you should license the modified version/part under LGPL, or GPL 2 or later
- Using NHiberante does not make your application a derivative of NHibernate, unless you distribute your application with NHibernate compiled into the application (eg, using self-contained single file/.NET Native/AOT/Native AOT, ILMerge/ILRepack, or other ways of embedding "statically linking").
- If you statically link NHibernate to something and distribute it then you should allow users to reverse engineer it for the purposes to re-link or modify copy of NHibernate used by your thing. Or license itself under LGPL, or GPL 2 or later, and make source code available.
Is there any intention of change it to MIT?
Even if there were such intentions (there is no at the moment) it would be really hard or impossible to do. As we do not require contributors to sign contributor's agreement and assign sub-licensing rights to us it means that we would need to ask all former contributors (including contributors to Hibernate) to agree to change the license.
Beta Was this translation helpful? Give feedback.
All reactions
-
Hi @hazzik,
Item 3 is a bit concerning to me.
Using NHiberante does not make your application a derivative of NHibernate, unless you distribute your application with NHibernate compiled into the application (eg, using AOT/Native AOT, ILMerge/ILRepack, or other ways of embedding "statically linking").
We know .NET is moving to AOT, giving developers a choice to use. At the moment it is not a complete feature, it has limitations, etc.
However the day will come it will be fully implemented in .NET and maybe widely used. What will happen to applications that want be migrated to AOT, they will need to abandon NH or keep as they are. But in long term (after full AOT is released) new application won't be using NH due to licensing issues.
I'd say this licensing issue should be handled to keep NH an option to developers in years to come.
Regards,
Paulo.
Beta Was this translation helpful? Give feedback.
All reactions
-
With AOT you also don't get run-time code generation which NHibernate applications typically use, and the conditional loading of drivers at run time, heavy use of reflection. It seems MS has identified this as challenges for EF and AOT also.
Things seems to get a bit confusing in .NET AOT. I mean, historically all apps where ahead-of-time compiled to native code - this did not imply anything like single-file or static linking. Feels unfortunate that this all seems to be conflated into a single option.
Perhaps it also depends why someone wants to make their application AOT. For faster startup? For easier deployment? In that case it sounds like it's fine to distribute statically linked, as long as you agree to make object files available. I suspect on demand is enough, but I'm not a lawyer. Only power users would really care about it so no "normal" users would need to be bothered with it. Based on https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 2
-
I don't think that NHibernate would be compatible with AOT any time soon as it heavily reliant on runtime code generation and reflection.
Beta Was this translation helpful? Give feedback.