Adding the GPL to Fluid license? - requesting input
colin.clark at utoronto.ca
Sun Jan 13 22:32:12 UTC 2008
A lot of passion and confusion inevitably seems to arise where the GPL
is concerned, so I particularly appreciate the cogent feedback from
Barnaby, Chris, and John on this issue.
I wanted to wait to see how the discussion evolved before weighing in
myself. I'll admit that I tend to be agnostic about licensing issues.
I don't like the polarization that tends to occur, and far I'm more
interested in designing great software, sharing it, and seeing it
However, Sheila has been incredible in tutoring me on many aspects of
copyright and licensing since the project began, and I see it as a
major responsibility of leadership within an open source community.
One area that I had been a bit fuzzy on was the ability for the BSD
license to be "promoted" to GPL where desired. Thanks to everyone who
clarified this point, as I think it's a key factor in the decision.
My priority for Fluid's licensing strategy is to enable people from a
variety of projects and perspectives to use our technology in a way
that they are comfortable with. This is *not* about trying to be all
things to all people, but rather, finding a satisfying middle ground.
I'm not a lawyer, so I'll defer to the experts' advice regarding how
best to be both inclusive and realistic when sharing our work.
My motivation in floating this trial balloon was largely in
anticipation of greater interest in adopting our work outside of Sakai
and uPortal. As many of you may have heard, Fluid is now a core
contributor to the new Mellon-funded OpenCollection project. This work
will involve direct integration of Fluid's user interface technologies
into OpenCollection's PHP application.
While OpenCollection's work is licensed under the GPL 2, I don't
anticipate any resistance to our present licensing strategy within
their community. We're all committed to a productive collaboration,
and I expect to see a lot of the code written for OpenCollection
making its way into the Fluid framework for the benefit of all
participating projects. My goal in suggesting a dual GPL/ECL license
was to avoid imposing boundaries on the collaboration, but this was
Increasingly, I have heard specifically from *individuals* within the
Moodle and Drupal communities that they were intrigued by our work,
but would not accept it if it were not available in GPL form. It's not
clear to me if the BSD/ECL will be sufficient for those needs, nor is
it clear if these individual perspectives are representative of the
wider community. Again, my hope for a GPL/ECL approach was to address
those potential concerns early. Perhaps too soon?
Regardless, Fluid's current priorities are entirely focussed on
creating great user interfaces and getting them into Sakai, uPortal,
and OpenCollection. While we're here to help, the work of integrating
Fluid into other applications such as Moodle, Drupal, or others will
fall to volunteers within those communities. We'll have to watch and
see how it goes.
I want to clear up one worrying misconception about the nature of
Fluid's code base. The software we are writing is specifically
designed as a library upon which new user interfaces can built more
contained and distinct from other aspects of an application. Our
toolkits we're familiar with and use within Sakai. Since Fluid's
architecture leverages existing server-side markup generation
capabilities, the only aspect of Fluid components that may intermingle
with other application code are the HTML templates when used with less
One last point I'd like to make is about forking. Our current
licensing strategy specifically allows anyone to make a fork of the
code if desired. This would also be the case if the GPL were involved.
The core question, which I think Chris, John, and Barnaby have
articulated well, is if the GPL will *encourage* forking among those
more ideologically-minded proponents of the GPL.
In my mind, forking is a huge responsibility. It's a right, but it's a
responsibility. We've worked very hard to make Fluid an open and
accommodating community in which to contribute code. A healthy,
inviting community is the first line of defense against a fork, and I
hope that anyone making modifications to Fluid will see the value of
contributing that work back to the community in way that is respectful
of our licensing approach. I'd like to similarly respect other
projects' licensing decisions where possible.
At this point, I'm in general agreement with the points John and
Joseph have made. If our current BSD/ECL license will indeed allow
GPL'd projects to comfortably incorporate Fluid into their GPL'd code
base--and similarly for the non-GPL contingent--then I think we can
continue as-is. Perhaps we'll want to be aware of situations where
this approach keeps us from wider adoption, and revisit this decision
if necessary down the road.
Once again, thanks very much for sharing your comments and advice;
I've found it invaluable.
On 12-Jan-08, at 12:53 PM, Joseph Hardin wrote:
> 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.
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
More information about the fluid-work