Adding the GPL to Fluid license? - requesting input

[Colin Clark]

Hi all,

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  
widely used.

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  
perhaps misguided.

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  
easily. Our JavaScript code is carefully packaged up so as to be self- 
contained and distinct from other aspects of an application. Our  
designs represent a discrete code library much like other JavaScript  
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  
modular technologies.

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.

Further thoughts?

Colin

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.

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org