From: M R. <mr...@gm...> - 2010-04-12 17:05:40
|
On Mon, 2010-04-12 at 11:06 -0500, kevin granade wrote: > On Mon, Apr 12, 2010 at 10:25 AM, M Rawash <mr...@gm...> wrote: > > - fork an earlier version of Ion that didn't include Tuomo's additional > > terms (or one that had a loophole in it), this means a lot of extra > > work, when many people would like to see us moving on (start adding new > > features, rather than going back and fix/add old ones). > > > > Another "PRO" for this option is the libtu and libextl situation. > AFAIK these libraries are also unmaintained now, and I don't imagine > them growing in popularity to the point of it being helpful to have > them as separate libraries. IIRC, they were still part of the same > package at the point when the license changes were made, so will be > part of our original code. I haven't had a chance to really dig in, > so for all I know this might be a trivial issue. All I know is this > is the issue I ran into (trying to compile/install ion3 on a fresh > system and failing since libtu/libextl were missing) that made me > aware of the true extent of the problem. > > Also, what are the libtu and libextl licenses like? if they're > standard lgpl we have a great deal of flexibility with what we do with > them, to the point of possibly using the latest libtu/libextl along > with the older version of ion as a starting point, but if they are a > similar modified license, it seems it will be all-or-nothing with > regard to which version of the sources we use as a starting point. libtu and libextl are both licensed under standard LGPL, and Tuomo didn't consider them as part of Ion (forming a whole), which means we really can do whatever onto them. we will most likely distribute them with notion and keep their licenses unchanged. > On another note, how much information do we have available concerning > the issues that were fixed in the time between the license change and > the most recent release? It will make a rather large difference to > how easy that work will be to reproduce if we have detailed > information about the bugs we want to work on. > More concretely, which resources would we be able to use if we do use > the pre-license-change source code as a starting point: > mailing list archives > darcs commit messages > changelog > other??? well, depending on which version/snapshot we will fork, we can either get a darcs log ('$ darcs changes') or a diff output. either way, we can easily have a very accurate list of (two years worth of) changes, > Thanks for the update, > Kevin Granade > > > > > as you can see, all our options are lacking in one way or another, so > > it'd indeed be good if we could get Tuomo's blessing, but i think we > > should remain realistic going forward; so if you have other > > ideas/opinions, please, do tell. > > > > regards, > > M Rawash > > > > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > grr, I have crappy managed hosting with no ssh access, I'm tempted to > get better hosting just so I can get rid of these ads, but I also > haven't set anything like that up before. Does google's project > hosting do the same thing? IMO, a host with no ssh access is a bad idea, as for google, they definitely don't have ads (just a few unnecessary instructions that can 'probably' be disabled), they do get spammed a lot though (which can 'probably' be avoided too). regards, M Rawash |