Re: JGroups license change ?

Apache 2.0/BSD/MIT would give you a wider user base, but less control.  
They are VERY business friendly and permissive.  They also make it very 
easy to fork, change, and not contribute back, which is what the LGPL 
was designed to prevent.

In my opinion, the problem with MPL, EPL, etc. is that they are less 
prevalent that people will wonder what, exactly, they can and can't do.  
With the ones above and the LGPL, I think there's a wider understanding 
of what you can and can't do.    They may give you some protection 
against people hording improvements to JGroups, though.

So in the end, I think it's up to you to figure out where that balance 
point is.  If you have a wide base of support and people contributing 
patches something like Apache would be fine because you are the hub for 
all that activity.  If you are worried about people taking it in a 
different direction and not sharing, I'd evaluate the less-prevalent 
ones you mention to see if they can at least keep enhancements open for 
you to possibly include them in the formal baseline.

IANAL,

Jeff

On 07/13/2011 06:33 AM, Bela Ban 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,
>>

-- 
This communication is intended FOR OFFICIAL USE ONLY of the recipient(s) designated above.  This email and/or its attachment may contain SOURCE SELECTION INFORMATION within the definition set forth in Federal Acquisition Regulation (FAR) 2.101 that is related to the conduct of a potential Federal agency procurement - disclosure of which is restricted by Section 27 of the Office of Federal Procurement Policy Act (41 USC 423). The Unauthorized disclosure of such information is prohibited under FAR 3.104 and may subject both the discloser and recipient of the information to contractual, civil and/or criminal penalties as provided by law.


------------------------------------------------------------------------------
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