Adding the GPL to Fluid license? - requesting input

Fri Jan 11 13:48:26 UTC 2008

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer

fluid-work-bounces at fluidproject.org wrote on 01/10/2008 01:33:45 PM:

> 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

That would be good. IBM and many others would not be able to support GPL.

> 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.
> >>
>
> _______________________________________________
> 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/20080111/71b9d326/attachment.htm>