Adding the GPL to Fluid license? - requesting input
Christopher D. Coppola
chris.coppola at rsmart.com
Sun Jan 13 16:40:31 UTC 2008
This all makes good sense to me John & Joseph. I'm interested in
better understanding the motivations but at present would certainly
advocate sticking with the current position which is dual licensed
under ECL and BSD essentially saying "we want maximum dissemination,
participation, and contribution but we'll rely on intrinsic motivation
to contribute rather than legal enforcement."
There's one side point I'd like to make here. In the dialog we've
tightly associated the proprietary fork behavior with commercial (for-
profit) interests. I don't think that's a particularly healthy or
accurate correlation. The fact is there are various reasons for the
behavior. In my experience in our communities the most common reason
unfortunately is old-school thinking and policies regarding
intellectual property that occur more with institutions who are
accustomed to monetizing IP than the commercial organizations in our
community. My point is that we should be more precise in how we talk
about this. The behavior we're talking about is "proprietary" not
"commercial." We still have a challenge ahead to help the larger
education community understand the opportunities for open source
software. We should strive to be very accurate in our language as a
part of addressing that challenge.
/chris
--
the rSmart group
Chris Coppola | 602.490.0472
blog: coppola.rsmart.com
On Jan 12, 2008, at 10:53 AM, Joseph Hardin wrote:
> I think this is pretty much the same position I would advocate,
> John, and the analysis is fine, with a few tweaks (inlined below)
> and I have a clarifying question to Colin, who is at the point of
> impact here.
>
> The question has to do with the motivations he sees for doing this,
> which I thought went beyond dissemination and sought to encourage
> participation. Colin, what are the people from the GPL side of our
> open source house saying here (maybe some of them could get in on
> this discussion)? They must not like the idea of taking the BSD-
> licensed source? Would it really stand in the way of their using
> FLUID? To contributing to FLUID? What do they think about the
> option of taking the BSD, making mods, and then dual licensing the
> result on their part, as GPL and BSD? As others have pointed out,
> it's not clear what this gets you other than a clean conscience, but
> that may be important here.
>
> On the whole, I have always liked the Apache/BSD/MIT/ECL style of
> allowing any reuse and redistribution of the source, with the
> encouragement to return work done back to the community (we do care
> what you do with our code, we just don't demand anything), and
> belief in market mechanisms and enlightened self-interest to make
> that happen.
>
> Joseph
>
> On Jan 12, 2008 12:11 PM, John Norman <john at caret.cam.ac.uk> wrote:
> [Warning] rambling stream of consciousness post.
>
> I think substituting LGPL for BSD is a red herring based on a
> misunderstanding of who we are trying to please.
>
> I think ECL (or Apache) + BSD dual licensing is fine.
>
> - If a GPL project just wants to incorporate code and continue to
> release under GPL, they can take code under the BSD license
> - If they then create a derived work with that code and refuse to
> return it to Fluid under the BSD license, then we are in no
> different position to a commercial company that takes the code under
> BSD and improves it, but declines to contribute the improvements back.
>
> Our motivation in considering this option is *maximum dissemination*
> of Fluid work
> and maximum participation in FLUID development, and maximum adoption
> in working code bases
> and the perception that _some_ projects may reject code if it is not
> released under a viral license (in a similar way to Sakai tending to
> reject GPL code)
> - A project that takes this attitude is unlikely to contribute back
> using BSD if they make developments so any development would be a
> GPL fork. What is wrong with that? Well the worst thing would be if
> they make valuable improvements that we cannot take AND we can't use
> their code in an ECL distribution. But this is no different to a
> commercial organisation taking the code 'private' and our license
> choice explicitly tolerates that.
>
> So we have NOT chosen a licensing strategy designed to prevent forks
> (we rely on enlightened self interest for that). Accordingly I don't
> think we should analyse this decision in terms of preventing a GPL
> fork.
>
> I think this is the central insight here...our strategy and beliefs
> have always tended to lean in the direction of not requiring, but
> rather encouraging things, and leaving individuals with the widest
> set of choices
>
>
> It seems that the choice is
> (a) stick to the 'liberal' line and say our code is available under
> a completely flexible license (BSD) and commercial and GPL forks are
> not forbidden. Go do what you like.
> (b) try to make it easier for the more religious of projects to take
> the code under GPL and recognise that they are just like commercial
> companies from our perspective - what they put back is at their
> discretion and any development they do is likely to create a GPL
> fork, in the same way as we recognise that many companies will be
> tempted to create a 'private' fork.
>
> There is no easy middle ground. Either you don't care what happens
> to your code after people take it or you do.
>
> Or, as I've said, and you say here too, "we do care, but we don't
> require"...
>
> Sticking to 'we don't care what happens to the code' and adding in
> 'we want as many as possible to take it' suggests that if and when
> someone indicates they would only take it under GPL, we let them.
> But should we encourage this or make it equally easy as taking it
> under BSD?
>
> This leaves me with; we don't publicise GPL availability, but if
> someone insists on GPL or nothing, we could allow it and recognise
> it is likely to be a one way flow. I am against encouraging GPL
> uptake and would prefer we encourage GPL projects to take it under
> BSD and return improvements under BSD. I am less clear on exactly
> how to implement that policy.
>
> The only way of implementation I see is what the FLUID folks have
> done: release with a BSD license to allow GPLers to incorporate into
> their GPL source base. Then encourage those selfsame GPL folks to
> release their work under BSD also. It is totally unclear to me
> whether they would do this. Perhaps for the FLUID components of
> their code they would, though it has been pointed out that the FLUID
> codes lack of clean modularity (perhaps a future design goal? maybe
> not possible) would add to the difficulty of doing this. I'd like
> to hear from the GPLers on this, and/or the FLUID folks talking with
> them.
>
> Does that make sense to anyone else. I'm probably missing a key
> point somewhere.
>
> Makes lots of sense. I also think the LGPL 'tri-license' approach
> is just too messy.
>
> John
>
> Joseph
>
> On 10 Jan 2008, at 23:53, Christopher D. Coppola wrote:
>
>> 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 r Smart 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
>>>>
>>>
>>
>> _______________________________________________
>> 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
>
>
>
>
> --
> Joseph Hardin
> School of Information
> University of Michigan
> Sakai Foundation
> 734-763-3266
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20080113/75dd9083/attachment.htm>
More information about the fluid-work
mailing list