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: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20080110/cac0d5c7/attachment.htm>
More information about the fluid-work
mailing list