Re: JGroups license change ?

we just went thru a large software audit with an IP law team. LGPL 2.1 raised a bunch of flags with them for several reasons. Apache 2.0 or MIT licensing is much more preferable for commercial usage. We had to document in great detail responses to the following questions. LGPL licensing requires greater supporting documentation to be created and maintained and is very easy to be non compliant with. LGPL 3.0 is a complete poison pill for commercial usage and has not been widely adopted by many open source projects. LGPL 2.1 appears to have been written for non Java programs where libraries are linked into the executable. We had a number of discussions with the IP lawyers regarding how java programs use components via classpath. Their contention is that the resulting application is still considered a derivative work since it depends on the presence of the LGPL binaries in order to operate as intended. The Apache 2.0 license is much less restrictive and has a lot fewer gray areas than LGPL.

PLEASE CHANGE THE LICENSING FOR JGROUPS !!!!!!!!!

Thanks

Dov Rosenberg


 1.
Please indicate the implementation language used for this component (e.g., Java, Javascript, C, C++). If this component is implemented in Java, please indicate whether Target obtained the component as a single jar file.

2. Please indicate whether Target modifies this component (modification includes without limitation any cutting and pasting of code from the library and any distribution of anything other than the complete library code in exactly the form received from the licensor). If Target modifies this component, please respond to the following questions:
(a) Please indicate identify the component implementation language of the Target modification to the LGPL lib - Java, Perl, etc.
(b) Please identify what was modified.
(c) Please indicate whether the modifications have been contributed back to the community and how.

3. Please identify the way the component is invoked, i.e. dynamic or static link, ext, or any other connection, such as external tool, exe dynamic jar file loading, etc. If a dynamic link, is the linking completed at runtime using LGPL header files and APIs which do not include portions of operating code?

4. Please identify the files from the component that are shipped with Target’s product. Please indicate whether Target ships any files from the component other than the designated runtime libraries. If so, please list them. Alternatively, please re-confirm that Target does not ship the third party work.

5. Please indicate whether the component’s interface contains any macro/inline functions of more than 10 lines.

6. Please indicate whether the component is invoked through a ‘standard interface’ used across a range of applications and implemented by the Target application in accordance with industry standards, rather than an API specific to the component, and if so, name the standard.

7. Please indicate whether Target's code operates properly with an interface-compatible modified version of the component.

8. Please indicate whether the component is in the separate deployment packages from the core of the Target product and whether it is in a separate jar.

9. Please indicate whether Target's code uses only numerical parameters, data structure layouts and accessors to access the component.

10. Please indicate whether Target's use of the component otherwise complies with all LGPL requirements.



On 7/13/11 3:33 AM, "Bela Ban" <[email protected]<mailto:[email protected]>> wrote:

Not a single response ?

I had a lively discussion inside of JBoss (the majority of folks were
*against* a change), but it seems that the community is not interested
in this, or doesn't care ?


On 7/11/11 9:52 AM, Bela Ban wrote:
Hi all,

over the years I've had quite a few projects, either commercial or open
source, turn down JGroups because of the (LGPL 2.1) license.

I've never been 100% happy with the LGPL myself because (1) it is long
and complicated, and (2) because it is (and I'm not a lawyer) ambiguous.
Even the creators of the LGPL spurn it...

So I'm thinking about changing the license for JGroups 3.0.

This is a request for comments/feedback. I'd like to get as much
feedback as possible on whether we should do this and - if yes - to
which license we should switch ?

I understand that most open source Java projects use ASL 2.0, so this is
a likely candidate, however, there are others such as BSD, MPL, EPL and
so on.

Unlike other projects, I wrote most of the current JGroups code, so a
license change should be easy. The procedure would be to track down all
contributors in the 3.0 code base and ask for their permission to change
the license. If someone objects, I'd have to pull his/her code or
rewrite it.

Should we embark on this ?

Counting on your feedback ...
Cheers,


--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat

------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
javagroups-users mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/javagroups-users


------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev