Adding the GPL to Fluid license? - requesting input

Christopher D. Coppola chris.coppola at
Thu Jan 10 19:15:00 UTC 2008

But right now there are only two different ways to license Fluid IP:  
ECL, or BSD. Both are compatible. The same would be true if the  
project permitted licensing under only GPL or BSD. I guess that *if* a  
GPL project incorporated the Fluid work (taking the BSD option) *and*  
that project modified the Fluid work as a part of that new derivative  
work, then the derivative would be incompatible with the licensing  
practices of the Fluid project, Sakai, Kuali, etc. and it couldn't be  
contributed back

However, in practice, if the project in question were to take the  
Fluid work as BSD, make the necessary modifications that were intended  
to be shared, make that available as BSD, and then incorporated it  
into the GPL project also, then all the stars would be aligned and  
projects on either end of the spectrum would be able to use the code.

By offering a GPL option it seems like it would be easier for the  
project in question to simply take the work as GPL, contribute it back  
as GPL and then that branch of code would no longer be something which  
could be licensed under either BSD or ECL.

I do agree with Lennard that *if* either LGPL or GPL *had* to be  
chosen, LGPL is the better choice for compatibility... but not much  
better. Any derivative work licensed under LGPL would still be an  
incompatible fork  that couldn't follow the original dual license  

Maybe the next step in figuring out the best course of action is to  
lay out the objective/problem very clearly and seek input on license-discuss at 

the rSmart group
Chris Coppola | 602.490.0472

On Jan 10, 2008, at 11:32 AM, swg wrote:

> It's seem like dual licensing either way would be problematic, since  
> Apache 2 (and I'm assuming ECL) code can't be copied wholesale into  
> GPL2 code, then you'd have incompatible forks for those people.
> I've been thinking this lately myself for what to license my fun  
> side projects (like Sash) under.  I guess BSD is a pretty safe way  
> to go...
> -Steve
> Christopher D. Coppola wrote:
>> Wow, this has sparked quite a conversation. I'd be a pretty strong  
>> -1 on this. The key reason is that it's almost certain to create  
>> incompatible forks of the code. The GPL does not limit commercial  
>> usage necessarily. It does limit the ability of multiple open  
>> source projects on either end of the copyleft - non-copyleft  
>> spectrum to share code. It seems that Fluid's existing solution is  
>> the best balance between the two. The ECL is clearly non-copyleft  
>> and unclear whether it's GPL compatible. The BSD license is clearly  
>> compatible and the dual license strategy strikes a nice balance.  
>> Offering a GPL option is almost certain to create incompatible forks.
>> /chris
>> -- 
>> the rSmart group
>> Chris Coppola | 602.490.0472
>> blog:
>> On Jan 10, 2008, at 10:40 AM, Lennard Fuller wrote:
>>> Just to further clarify the difference between GPL and LGPL.  LGPL  
>>> does using the Lesser GPL permits use of the library in  
>>> proprietary programs.  For fluid this would mean that large  
>>> companies could then make use of fluid to build their products.   
>>> LGPL would also mean that if a commercial company were to enhance  
>>> fluid in any way, those changes would have to be made open and  
>>> available to the world.  A full GPL license only allows non  
>>> proprietary usage.  In short, a full GPL limits your audience...  
>>> and for software like fluid, in my opinion, it would also limit  
>>> the good such a product could do.
>>> Again, my vote would be to not use either LGPL or GPL, but if one  
>>> must be used, LGPL would seem to be the better course.
>>> -Lennard Fuller
>>> Lennard Fuller wrote:
>>>> So long as the customizations are also open and available there
>>>> shouldn't be any problems.  GPL does not require that the changes  
>>>> be
>>>> committed back into the project's root.  It is just that all of the
>>>> modifications must be open and available.  Problems really start  
>>>> when
>>>> GPL code is included into a proprietary application... there is a  
>>>> clause
>>>> in the license that then requires the entire application be made  
>>>> open
>>>> and available.  If the code being used is LGPL, and is used  
>>>> properly,
>>>> then by and large the 'viral' type restriction is removed.  IF  
>>>> the LGPL
>>>> software is modified in any way, it does need to be open and  
>>>> available.
>>>> Mark Norton wrote:
>>>>> I had a look at Moodlerooms Terms of Service.  Had trouble  
>>>>> accessing
>>>>> the site, so used Google Cache:
>>>>> Interesingly, there is VERY little mention of Moodle in the  
>>>>> TOS.  This
>>>>> line is interesting, however:
>>>>> "Moodlerooms provides expertise and energy to train your  
>>>>> instructors,
>>>>> customize Moodle to your specifications, host Moodle at an
>>>>> enterprise-level stemming from superior hardware and software
>>>>> engineering, connect your legacy information systems to Moodle  
>>>>> through
>>>>> integrations, and convert your courses so that they work in  
>>>>> Moodle."
>>>>> Customize Moodle, eh?  Sounds like thin ice to me.
>>>>> - Mark
>>>>> Lennard Fuller wrote:
>>>>>> MoodleRooms source code is open and available.  They also provide
>>>>>> services such as corporate hosting.  It is not that GPL  
>>>>>> precludes any
>>>>>> commercial usage... it is just that the license places some  
>>>>>> severe
>>>>>> limitations on how it can be used.  Personally, I am not for  
>>>>>> adding
>>>>>> the GPL license.  If we absolutely HAVE to have some form of  
>>>>>> the GPL,
>>>>>> please consider using the LGPL.
>>>>>> Mara Hancock wrote:
>>>>>>> This is very interesting. I agree with Mark that this seems  
>>>>>>> like an
>>>>>>> attempt to avoid the inevitable conflict between the licenses. I
>>>>>>> fear that it make the management of the code contributions so
>>>>>>> complicated that it will need a full time code gatekeeper. I  
>>>>>>> came
>>>>>>> into the conversation late yesterday, but I thought  that  
>>>>>>> Colin had
>>>>>>> some very concrete examples of why he thought this might be a  
>>>>>>> good
>>>>>>> thing. It would be good to hear those. Right now I am on the -1
>>>>>>> track but willing to be convinced otherwise. I would love to  
>>>>>>> know
>>>>>>> the answer to the question about Moodle Rooms.
>>>>>>> Thanks, Mara
>>>>>>> On Jan 10, 2008, at 8:00 AM, Lennard Fuller wrote:
>>>>>>>> Many of my clients specifically ask me to avoid GPL, some of  
>>>>>>>> that
>>>>>>>> set of
>>>>>>>> clients will accept an LGPL if no other reasonable  
>>>>>>>> alternative exists.
>>>>>>>> Oddly enough... over the last 7 years I have yet to have had  
>>>>>>>> a single
>>>>>>>> client that has demanded the use of GPL exclusively.
>>>>>>>> -Lennard Fuller
>>>>>>>> Mark Norton wrote:
>>>>>>>>> This sounds like an attempt to please all of the people all  
>>>>>>>>> of the
>>>>>>>>> time.
>>>>>>>>> The fact is there are some very different philosophies in  
>>>>>>>>> the open
>>>>>>>>> source community, primarily divided between those who favor
>>>>>>>>> commercial
>>>>>>>>> use and those who don't. If Fluid is licensed (as it  
>>>>>>>>> currently is)
>>>>>>>>> under
>>>>>>>>> ECL 2.0, then the Sakai community will likely be satisfied,  
>>>>>>>>> since
>>>>>>>>> it has
>>>>>>>>> a more inclusive view of open source use. However, I suspect  
>>>>>>>>> that
>>>>>>>>> those
>>>>>>>>> in other camps will not be satisfied with a GPL license if  
>>>>>>>>> it is also
>>>>>>>>> licensed under ECL. What's the point, really?
>>>>>>>>> Who specifically needs a GPL license for Fluid?
>>>>>>>>> - Mark Norton
>>>>>>>>> Sheila Crossey wrote:
>>>>>>>>>> All,
>>>>>>>>>> We are considering adding the GPL to the Fluid licensing  
>>>>>>>>>> scheme and
>>>>>>>>>> are seeking input on the ramifications this would have.
>>>>>>>>>> Refresher:
>>>>>>>>>> Fluid is currently dual-licensed under ECL 2.0 and BSD  
>>>>>>>>>> licenses. The
>>>>>>>>>> BSD license was selected to enable combining with GPL- 
>>>>>>>>>> licensed code
>>>>>>>>>> (as BSD is deemed to be GPL compatible whereas ECL 2.0 is  
>>>>>>>>>> not)
>>>>>>>>>> and to
>>>>>>>>>> avoid forking of the code (BSD is not copyleft so code  
>>>>>>>>>> licensed
>>>>>>>>>> under
>>>>>>>>>> BSD can be merged into non-copyleft code).
>>>>>>>>>> Issue:
>>>>>>>>>> Some communities who license their code under the GPL will  
>>>>>>>>>> not adopt
>>>>>>>>>> any third party code unless it also is licensed under GPL;  
>>>>>>>>>> that
>>>>>>>>>> is, a
>>>>>>>>>> GPL-compatible license such as BSD does not solve the  
>>>>>>>>>> problem (even
>>>>>>>>>> though technically, it should).
>>>>>>>>>> Proposed solution:
>>>>>>>>>> Tri-license Fluid under ECL 2.0, BSD, and GPL V2.
>>>>>>>>>> GPL V3 was considered as an option, but rejected as there  
>>>>>>>>>> are some
>>>>>>>>>> parties who have licensed a considerable body of code under  
>>>>>>>>>> GPL
>>>>>>>>>> V2 and
>>>>>>>>>> who will not move to GPL V3 as they have various objections  
>>>>>>>>>> to
>>>>>>>>>> the new
>>>>>>>>>> terms. We can apply GPL V2 in a way that will permit the  
>>>>>>>>>> option of
>>>>>>>>>> applying GPL V3 to those who wish to.
>>>>>>>>>> Risk/Benefit:
>>>>>>>>>> The benefit would be potentially increased penetration and  
>>>>>>>>>> usage of
>>>>>>>>>> Fluid code.
>>>>>>>>>> One risk is that GPL communities could license their
>>>>>>>>>> modifications to
>>>>>>>>>> Fluid code solely under GPL thus creating a separate fork.  
>>>>>>>>>> The
>>>>>>>>>> chances
>>>>>>>>>> of this happening could be reduced by publicizing this  
>>>>>>>>>> negative
>>>>>>>>>> impact
>>>>>>>>>> of single-licensing under the GPL.
>>>>>>>>>> A second risk is that communities who are concerned about the
>>>>>>>>>> effects
>>>>>>>>>> of GPL’s copyleft terms might be uncomfortable adopting  
>>>>>>>>>> Fluid if the
>>>>>>>>>> GPL is one of the licenses which apply to it. We need input  
>>>>>>>>>> from
>>>>>>>>>> Sakai
>>>>>>>>>> regarding this.
>>>>>>>>>> As there may be other risks arising from the increased  
>>>>>>>>>> complexity of
>>>>>>>>>> tri-licensing and adding copyleft into the mix, I encourage  
>>>>>>>>>> anyone
>>>>>>>>>> with expertise, or access to it, to weigh in on this.
>>>>>>>>>> Sheila
>>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>>> Sheila Crossey
>>>>>>>>>> Senior Project Coordinator
>>>>>>>>>> Adaptive Technology Resource Centre
>>>>>>>>>> Faculty of Information Studies
>>>>>>>>>> University of Toronto
>>>>>>>>>> voice: (416) 946-7820
>>>>>>>>>> fax: (416) 971-2896
>>>>>>>>>> email: sheila.crossey at
>>>>>>>>>> <mailto:sheila.crossey at>
>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>> _______________________________________________
>>>>>>>>>> fluid-work mailing list
>>>>>>>>>> fluid-work at
>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>> No virus found in this incoming message.
>>>>>>>>>> Checked by AVG Free Edition.
>>>>>>>>>> Version: 7.5.516 / Virus Database: 269.19.0/1216 - Release  
>>>>>>>>>> Date:
>>>>>>>>>> 1/9/2008 10:16 AM
>>>>>>>>> _______________________________________________
>>>>>>>>> fluid-work mailing list
>>>>>>>>> fluid-work at
>>>>>>>> _______________________________________________
>>>>>>>> fluid-work mailing list
>>>>>>>> fluid-work at
>>>> _______________________________________________
>>>> fluid-work mailing list
>>>> fluid-work at
>> [see attachment: "message0.html", size: 13040 bytes]
>> Attachments:
>> message0.html
>> ----------------------
>> This automatic notification message was sent by Sakai Collab ( 
>> ) from the WG: Licensing site.
>> You can modify how you receive notifications at My Workspace >  
>> Preferences.

More information about the fluid-work mailing list