Adding the GPL to Fluid license? - requesting input

Christopher D. Coppola chris.coppola at
Thu Jan 10 19:33:45 UTC 2008

LOL! You're right. The same problem exists either way... I just have a  
slanted view of the world because the projects I'm involved in are ECL  
projects. I guess we can think of the BSD as Switzerland in this  
regard. As long as:

1. Contributions back to the Fluid project are made in a way that  
permits Fluid to continue the dual licensing model; AND
2. The majority of work on Fluid, regardless where it happens, is  
contributed and re-released by the fluid project as per #1.

Then the project is going to be striking a good balance given the  
difficulty of the OS licensing world.

Ok, now I'm going back to work also. :-)

the rSmart group
Chris Coppola | 602.490.0472

On Jan 10, 2008, at 12:25 PM, swg wrote:

> I was thinking more along the lines of it it were dual licensed  
> under the ECL and BSD, and then a 3rd party modified it and released  
> it under ECL, then it wouldn't be compatible with the GPL'd project.
> But I guess it might be possible to go ECL -> BSD -> GPL?
> I should probably just go back to work before I get too confused and  
> have to make a diagram...   ;)
> -Steve
> Christopher D. Coppola wrote:
>> 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  
>> strategy.
>> 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 
>> .
>> /chris
>> -- 
>> the rSmart group
>> Chris Coppola | 602.490.0472
>> blog:
>> 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.
>> ----------------------
>> 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