Adding the GPL to Fluid license? - requesting input

Christopher D. Coppola chris.coppola at rsmart.com
Thu Jan 10 23:53:20 UTC 2008


Barnaby,

I'm not sure I understand how the dual ECL 2.0 and LGPL 2.1 situation  
would work. As you clearly articulated, Fluid's IP isn't a discrete  
library. The advantage of the LGPL over the GPL in a situation like  
this is that we can be more clear about what constitutes a derivative  
work. If something's licensed under LGPL and it's not a discrete  
library then the waters are muddy and you end up in the same fuzzy  
situation you'd be in if the work was licensed under GPL. Right?

/chris
--
the rSmart group
Chris Coppola | 602.490.0472
blog: coppola.rsmart.com

On Jan 10, 2008, at 4:39 PM, Barnaby Gibson wrote:

>
> I spoke a bit to Sheila this morning, but I thought that I would  
> chime into this forum as well.
>
> As Lennard pointed out in one of his messages, the folks who are  
> asking for the software to be licensed under the GPL are concerned  
> that they will contribute to the code base and then later discover  
> that a third party is distributing a modified version of the  
> software without contributing its modifications back to the  
> community.  But if the software is also licensed under the BSD and/ 
> or the ECL, there is not much that prevents a third party from  
> taking the software under the BSD or ECL and distributing a modified  
> version without contributing its modifications to the community,  
> potentially creating a proprietary fork if people find the  
> modifications to be sufficiently compelling that they start to  
> insist on using the modified distribution. This is the "proprietary  
> fork" that foks in the GPL camp worry about.
>
> Likewise, under a dual BSD/ECL licensing scheme, there is nothing  
> that prevents a third party from taking the software under the BSD  
> and distributing a modified version under the GPL that creates a GPL- 
> only fork, again if people find the GPL-only modificiations to be  
> sufficiently compelling that they insist on the distribution that  
> has the GPL-only modifications, rather than on the Fluid  
> distribution that is dual licensed. The problem with this GPL-only  
> fork is that in many cases it discourages investment in the software  
> by commercial third party developers.
>
> I'm not sure in these circumstances that there is a solution that  
> will make everyone happy, in part because the UI- and code- (as  
> versus library) centric nature of the Fluid project makes it hard to  
> license it exclusively under the LGPL, which is one of the more  
> common "compromises" between copyleft and non-copyleft open source  
> licenses.  If Fluid were more akin to a library or had an API, or if  
> it provided discrete functionality, it would be easier for Sakai to  
> come to the conclusion that including it in the distribution under  
> LGPL is consistent with the non-proprietary/non-copyleft "agnostic"  
> nature of the Sakai project, and I would probaby think that using  
> only the LGPL would be a possible compromise solution.  But given  
> the nature of Fluid it's hard to recommend that they adopt the LGPL  
> exclusively.
>
> If they really are not willing to license Fluid solely under the  
> ECL, they should dual license Fluid under the ECL 2.0 and the LGPL  
> 2.1 and drop the BSD.  The BSD does nothing to protect against a  
> proprietary fork, and it does nothing to protect against a GPL-only  
> fork.  I still think a LGPL fork would be a "bad thing," but at  
> least if there is a LGPL fork, there is some chance that folks will  
> feel comfortable using portions of the LGPL code.
>
> Regards,
> Barnaby
>
> --------------------------------------------------
> D. Barnaby Gibson
> General Counsel, Treasurer & Secretary
> Ithaka Harbors, Inc.
> 151 East 61st Street, New York, NY 10065
> (212) 500-2342 (work)
> (212) 500-2366 (fax)
> barnaby.gibson at ithaka.org
>
>
>
> From: Lennard Fuller [mailto:lfuller at unicon.net]
> Sent: Thursday, January 10, 2008 12:41 PM
> To: markjnorton at earthlink.net
> Cc: Barnaby Gibson; Christopher D. Coppola; licensing at collab.sakaiproject.org 
> ; fluid-work at fluidproject.org
> Subject: Re: Adding the GPL to Fluid license? - requesting input
>
> 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:
>>> http://64.233.169.104/search?q=cache:mElfwQm2ZYoJ:www.moodlerooms.com/tos.html+Moodlerooms+license&hl=en&gl=us&strip=1
>>>
>>>
>>> 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 utoronto.ca
>>>>>>>> <mailto:sheila.crossey at utoronto.ca>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> fluid-work mailing list
>>>>>>>> fluid-work at fluidproject.org
>>>>>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> 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 fluidproject.org
>>>>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> fluid-work mailing list
>>>>>> fluid-work at fluidproject.org
>>>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>>>
>>>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080110/cac0d5c7/attachment.html>


More information about the fluid-work mailing list