[Building Sakai] [Management] Gradebook Situation

Thu Jul 29 10:05:30 PDT 2010

The board chose not to allow Ext GWT because it violates the principle of a commercial-friendly licensing policy. That said, the decision seemed to be more utilitarian than absolutist. If there were a strong case why Sakai will be materially harmed in the long haul by not allowing this project into core, then I'm pretty sure the board would hear that case with an open mind. The preferable solution would be to get a licensing exception from Sencha, though.

On the more general topic of GWT, I personally think it's very important for us to support one (though preferably only one) server-side UI framework in Sakai 3, and GWT is the obvious candidate. 

- m

-- 
Oracle
Michael Feldstein | Principal Product Manager
Phone: +1 8188172925 | Mobile: +1 9179218895 
Oracle Academic Enterprise Solutions
25 Christian Hill Road | Great Barrington, MA 01230 

Green Oracle	 Oracle is committed to developing practices and products that help protect the environment	 

-----Original Message-----
From: Clay Fenlason [mailto:clay.fenlason at et.gatech.edu] 
Sent: Wednesday, July 28, 2010 1:33 PM
To: Noah Botimer
Cc: Managers; sakai2-tcc; Sakai Developers
Subject: Re: [Building Sakai] [Management] Gradebook Situation

IIRC, the last time someone looked at this, the language of the dual licensing allowed for a BSD-style license to be granted, but it attached conditions about derivative works downstream from that point also being required to use the same license thus granted. As Noah points out, I believe the issue is not so much what Sakai could release as what people could do with that release.

That said, I don't think it's out of the question to approach the library developers again (as Noah hints, 'Sencha' may signal new
management) and try to get special dispensation. In fact it's in my queue of things to try. I'd assume that some of the open questions (whether other institutions might help drive GB2 development) might hinge on a positive outcome on that point. But the next steps identified (for marching us toward shared ownership of GB services) are useful regardless, and we'll work our way around to GB2's future as a front end again. Of the two issues - community coordination on core capabilities vs. the GB2 interface - I think I can say that the former is the more far-reaching concern without slighting the results of the GB2 work.

We can at least move from 3 front ends and 2 back ends, to 2 front ends and 1 back end. While we're at it we can get IU off the hook for being sole owner of GB code, distribute focus a little better, and have a clear conversation about GB requirements that could even inform
S3 design work in the offing. That's the constructive path I'm focused on atm.

~Clay

On Wed, Jul 28, 2010 at 12:56 PM, Noah Botimer <botimer at umich.edu> wrote:
> I should also be clear, here. Though we may be able to distribute the 
> library under the exception with the Sakai community release under 
> ECLv2, this would be a burrowed problem for our commercial partners. 
> They could relicense the whole of Sakai except for this little bit, 
> which is included contingent on the larger work's license.
> This would be severe overhead, likely to force partners to remove and 
> distribute GB2 separately. As my colleague Matt Jones just pointed 
> out, this is a place where we would get some mileage out of a solid 
> packaging/installation mechanism. Maybe there is enough value in GB2 
> to drive investment in such overdue infrastructure.
>
> Thanks,
> -Noah
> On Jul 28, 2010, at 12:07 PM, Noah Botimer wrote:
>
> ...Fixing the TCC address on this thread.
> Thanks,
> -Noah
> On Jul 28, 2010, at 12:05 PM, Noah Botimer wrote:
>
> GB2 uses Ext JS/Ext GWT for the spreadsheet/tree views. These are GPLv3.
> There is a "FLOSS Exception" that applies for ECLv2, which can exempt 
> an "Application" from the same-license bits of GPL.
> However, this is a unique case and I don't know that we've gotten any 
> assessment from someone qualified. There are also very tricky details 
> around "Extensions" (modifications, add-ons), where distribution of 
> the main library is forbidden. As a last detail, the exception applies 
> to given versions "or later, where the exception notice is present". 
> As a technicality, the legal entity has changed names (to Sencha, 
> Inc.), so the exception should be vetted for the "or later" part.
> There is effectively no suitable replacement at this time, as I 
> understand it. Ext JS is quite nice and has a very specific 
> object/inheritance model, giving good results and pretty tight 
> binding. I'm less familiar with Ext GWT, but it effectively provides 
> the Ext JS library to GWT apps, where I believe the binding is even a bit tighter.
> As I understand, the spreadsheet/tree interface of GB2 is the primary 
> goal and primary body of work -- porting would essentially be a 
> rewrite and a different project.
> Thanks,
> -Noah
>
> http://www.sencha.com/products/floss-exception.php
>
> On Jul 28, 2010, at 10:27 AM, Carl Hall wrote:
>
> What library is it?  Maybe we could work out some dual licensing or 
> help find a replacement.
>
> On Tue, Jul 27, 2010 at 9:16 AM, Mark Norton 
> <markjnorton at earthlink.net>
> wrote:
>>
>>  > Gradebook 2 includes an indispensable library which is licensed 
>> under GPL
>>
>> Well, that was a pretty silly thing to do.  We've managed to steer 
>> clear of GPL code for the entire lifetime of Sakai (with the possible 
>> exception of MySQL).  That, at a minimum, needs to be fixed, IMO.
>>
>> - Mark Norton
>>
>> Clay Fenlason wrote:
>> > We started to talk about the state of various gradebook tools at 
>> > the Project Coordination meetings in Denver, and some discussion 
>> > between Kirk, Karen and I has followed since, so an update is in 
>> > order.  I wanted also to communicate the information more widely 
>> > and make sure the rest of the community was aware.
>> >
>> > You can find an overview of the gradebook situation in Confluence 
>> > [1], where the information will be revised as the situation develops.
>> > Questions and comments welcome, though you'll notice we don't have 
>> > answers to every question yet.
>> >
>> > Please note in particular the next step planned around 2.8. In 
>> > mid-August UCDavis and IU are planning to come together to agree on 
>> > the final details of a common data model, and it's expected that 
>> > this work (including conversion scripts) could be completed by the 
>> > projected code freeze in mid-September
>> >
>> > ~Clay
>> >
>> > [1] http://confluence.sakaiproject.org//x/_hIhB
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to 
> sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>
> _______________________________________________
> management mailing list
> management at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to 
> management-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>
_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"