Adding the GPL to Fluid license? - requesting input
Christopher D. Coppola
chris.coppola at rsmart.com
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. :-)
/chris
--
the rSmart group
Chris Coppola | 602.490.0472
blog: coppola.rsmart.com
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 opensource.org
>> .
>>
>> /chris
>> --
>> the rSmart group
>> Chris Coppola | 602.490.0472
>> blog: coppola.rsmart.com
>>
>> 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: coppola.rsmart.com
>>>>
>>>> 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:
>>>>>>> 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
>>>>>>
>>>>>
>>>>
>>>> [see attachment: "message0.html", size: 13040 bytes]
>>>>
>>>>
>>>> Attachments:
>>>>
>>>> message0.html
>>>> https://collab.sakaiproject.org/access/content/attachment/3e639311-1fb2-4a7a-00ce-80debf4fb0c3/message0.html
>>>>
>>>> ----------------------
>>>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org/portal
>>>> ) 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 (https://collab.sakaiproject.org/portal
>> ) from the WG: Licensing site.
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>>
More information about the fluid-work
mailing list