Menu
▾
▴
notion-devel
|
From: M R. <mr...@gm...> - 2010-04-12 15:33:01
|
hi everybody, thought I'd give you a little update of what's going on.
Ole Brønner and I spoke earlier about our legal situation (with regard
to Tuomo's license); he's in favour of getting Tuomo's blessing to fork
the latest Ion3(plus) release, while i'm in favour of forking an earlier
version of Ion that didn't include Tuomo's terms. Ole has contacted
Tuomo and we have set a deadline ("a couple of days") for a response,
and since it's very likely that Tuomo won't respond, i think we should
be aware of our other options while we wait, and here they are:
- forking Ion while keeping Tuomo's license, this, of course, will
render the fork 'non-free', and infringe on our own right to license any
future work under a different license.
- fork Ion and change the license (possibly to GPL), this will leave us
vulnerable to Tuomo's hostility (assuming he is indeed hostile), since
it's basically 'illegal' in light of Tuomo's additional terms (which,
according to Tuomo, "take precedence over the LGPL").
- 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).
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
|
|
From: kevin g. <kev...@gm...> - 2010-04-12 16:06:50
|
On Mon, Apr 12, 2010 at 10:25 AM, M Rawash <mr...@gm...> wrote:
> hi everybody, thought I'd give you a little update of what's going on.
> Ole Brønner and I spoke earlier about our legal situation (with regard
> to Tuomo's license); he's in favour of getting Tuomo's blessing to fork
> the latest Ion3(plus) release, while i'm in favour of forking an earlier
> version of Ion that didn't include Tuomo's terms. Ole has contacted
> Tuomo and we have set a deadline ("a couple of days") for a response,
> and since it's very likely that Tuomo won't respond, i think we should
> be aware of our other options while we wait, and here they are:
>
> - forking Ion while keeping Tuomo's license, this, of course, will
> render the fork 'non-free', and infringe on our own right to license any
> future work under a different license.
>
> - fork Ion and change the license (possibly to GPL), this will leave us
> vulnerable to Tuomo's hostility (assuming he is indeed hostile), since
> it's basically 'illegal' in light of Tuomo's additional terms (which,
> according to Tuomo, "take precedence over the LGPL").
>
> - 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.
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???
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?
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
>
|
|
From: Ole J. B. <ole...@ya...> - 2010-04-12 16:44:32
|
>> - 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. I'm 99% sure this is a trivial issue. > 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. They use standard licenses: http://folk.ntnu.no/bronner/temp/ion3/repos/libextl-3/LICENSE http://folk.ntnu.no/bronner/temp/ion3/repos/libtu-3/LICENSE Last change in libextl is: Sat Dec 15 15:38:58 CET 2007 libtu is: Thu Dec 20 19:04:14 CET 2007 ... if my checkout is the most recent. (I'm quite sure of that) PS: does anyone know how I can check when a darcs repo was checked out and if it was checked out lazily? Date of license modification in ion3(-plus): Fri Apr 27 23:50:40 CEST 2007 > 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??? Darcs patch/change descriptions: http://folk.ntnu.no/bronner/temp/post-license-changes.txt Tarball of pre-license-change (from darcs, not an "official" stable release): http://folk.ntnu.no/bronner/temp/ion3/ion3-prelicense-change.tgz (size due to inclusion of darcs repo) |
|
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
|
|
From: Olof J. <zi...@et...> - 2010-04-12 17:24:16
|
On 2010-04-12 18:58, M Rawash wrote: > 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). Google is bound by US law to block users from Iran, Syria, Cuba, etc[1] (like SF, but I've read that SF has circumvented this (?)) I'd urge against using Google to host free software projects. So, once again, I'd recommend using own hosting or maybe Savannah (I don't personally have experience with Savannah, so if anybody disagrees, please speak up). Wikipedia has a comparison article on code hosting[2]. 1: http://en.wikipedia.org/wiki/Google_Code#Access_restrictions 2: http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities -- Olof Johansson jabber: ol...@et... irc: zibri on Freenode, OFTC uri: http://www.stdlib.se/ |
|
From: M R. <mr...@gm...> - 2010-04-12 17:47:10
|
On Mon, 2010-04-12 at 19:24 +0200, Olof Johansson wrote: > On 2010-04-12 18:58, M Rawash wrote: > > 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). > > Google is bound by US law to block users from Iran, Syria, Cuba, etc[1] > (like SF, but I've read that SF has circumvented this (?)) I'd urge > against using Google to host free software projects. So, once again, I'd > recommend using own hosting or maybe Savannah (I don't personally have > experience with Savannah, so if anybody disagrees, please speak up). > Wikipedia has a comparison article on code hosting[2]. > > 1: http://en.wikipedia.org/wiki/Google_Code#Access_restrictions > 2: http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities nice, thanks for the info/links, i'll be checking them out tonight, maybe narrowing them down to a few good choices... cheers, M Rawash |
|
From: Aron G. <agr...@n0...> - 2010-04-12 18:07:35
|
Hi Rawash (is this how you prefer to be addressed?)
Thanks for this update...
M Rawash wrote: [Mon Apr 12 2010, 11:25:54AM EDT]
>hi everybody, thought I'd give you a little update of what's going on.
>Ole Brønner and I spoke earlier about our legal situation (with regard
>to Tuomo's license); he's in favour of getting Tuomo's blessing to fork
>the latest Ion3(plus) release, while i'm in favour of forking an earlier
>version of Ion that didn't include Tuomo's terms. Ole has contacted
>Tuomo and we have set a deadline ("a couple of days") for a response,
This is certainly the most desirable option, though it does seem
unlikely that Tuomo will acquiesce. No offense intended, but if
he saw your comments earlier to the tune of "let him sue!" that
probably didn't help.
>and since it's very likely that Tuomo won't respond, i think we should
>be aware of our other options while we wait, and here they are:
>
>- forking Ion while keeping Tuomo's license, this, of course, will
>render the fork 'non-free', and infringe on our own right to license any
>future work under a different license.
IMHO we want to avoid this option because we will continue to
have problems getting into distributions.
>- fork Ion and change the license (possibly to GPL), this will leave us
>vulnerable to Tuomo's hostility (assuming he is indeed hostile), since
>it's basically 'illegal' in light of Tuomo's additional terms (which,
>according to Tuomo, "take precedence over the LGPL").
IMHO we want to avoid this option too. We will be on dubious
legal ground and distributions will not want to deal with it.
>- 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).
If Tuomo doesn't give his blessing to fork current ion3 with
simple LGPL then I think this is the next best option. It means
more work but it leaves us free of license problems.
Regards,
Aron
|
|
From: M R. <mr...@gm...> - 2010-04-12 19:02:55
|
On Mon, 2010-04-12 at 14:08 -0400, Aron Griffis wrote:
> Hi Rawash (is this how you prefer to be addressed?)
yah, why not? :)
> Thanks for this update...
>
> M Rawash wrote: [Mon Apr 12 2010, 11:25:54AM EDT]
> >hi everybody, thought I'd give you a little update of what's going on.
> >Ole Brønner and I spoke earlier about our legal situation (with regard
> >to Tuomo's license); he's in favour of getting Tuomo's blessing to fork
> >the latest Ion3(plus) release, while i'm in favour of forking an earlier
> >version of Ion that didn't include Tuomo's terms. Ole has contacted
> >Tuomo and we have set a deadline ("a couple of days") for a response,
>
> This is certainly the most desirable option, though it does seem
> unlikely that Tuomo will acquiesce. No offense intended, but if
> he saw your comments earlier to the tune of "let him sue!" that
> probably didn't help.
ok, maybe that was too early, but i assumed (and i'm probably still
right), that Tuomo's rejection of what we're doing is a done deal (based
on his responses to earlier emails/"Fake Tuomo"); but Ole had a
different opinion, hence, the current situation.
> >and since it's very likely that Tuomo won't respond, i think we should
> >be aware of our other options while we wait, and here they are:
> >
> >- forking Ion while keeping Tuomo's license, this, of course, will
> >render the fork 'non-free', and infringe on our own right to license any
> >future work under a different license.
>
> IMHO we want to avoid this option because we will continue to
> have problems getting into distributions.
> >- fork Ion and change the license (possibly to GPL), this will leave us
> >vulnerable to Tuomo's hostility (assuming he is indeed hostile), since
> >it's basically 'illegal' in light of Tuomo's additional terms (which,
> >according to Tuomo, "take precedence over the LGPL").
>
> IMHO we want to avoid this option too. We will be on dubious
> legal ground and distributions will not want to deal with it.
> >- 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).
>
> If Tuomo doesn't give his blessing to fork current ion3 with
> simple LGPL then I think this is the next best option. It means
> more work but it leaves us free of license problems.
+1 on all accounts.
regards,
M Rawash
|
|
From: Aron G. <agr...@n0...> - 2010-04-12 18:27:47
|
Olof Johansson wrote: [Mon Apr 12 2010, 01:24:00PM EDT] > On 2010-04-12 18:58, M Rawash wrote: > > 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). > > Google is bound by US law to block users from Iran, Syria, Cuba, etc[1] > (like SF, but I've read that SF has circumvented this (?)) I'd urge > against using Google to host free software projects. So, once again, I'd > recommend using own hosting or maybe Savannah I haven't looked at Savannah but I've been impressed with github. How about using sf.net for web host (unless there's something better), github.com for code host and librelist.com for mailing lists? Aron |
|
From: Marc H. <mar...@al...> - 2010-04-12 18:30:35
Attachments:
signature.asc
|
Excerpts from M Rawash's message of Mon Apr 12 11:25:54 -0400 2010: > - fork Ion and change the license (possibly to GPL), this will leave us > vulnerable to Tuomo's hostility (assuming he is indeed hostile), since > it's basically 'illegal' in light of Tuomo's additional terms (which, > according to Tuomo, "take precedence over the LGPL"). It seems a fork-and-rename is consistent with the intent, if not the terms, of the modified LGPL. It would seem a release under a modified LGPL with the rider that the project or its forks may not be renamed to Ion, ion3, or anything which would associate it with the Ion project, and may not contain anything which refers users to the Ion project or Tuomo Valkonen for support, and that this project and its forks may not change to any license which does not contain, or invalidates, this rider would be consistent with the goal of the license. IANAL, but shouldn't this be doable in a reasonably straightforward way? The point of the name change is that it and not referring back to ion is what's required by the license. Yes, it wouldn't be "pure GPL", but if the only additional restriction is "can't rename this to Ion or ask Tuomo for tech support, must preserve this restriction", is that going to relegate it to scary/non-free? It's not restricting a distro from doing anything they'd actually do anyway [not like the current ion license]. |
|
From: M R. <mr...@gm...> - 2010-04-12 19:58:03
|
On Mon, 2010-04-12 at 14:30 -0400, Marc Hartstein wrote: > Excerpts from M Rawash's message of Mon Apr 12 11:25:54 -0400 2010: > > - fork Ion and change the license (possibly to GPL), this will leave us > > vulnerable to Tuomo's hostility (assuming he is indeed hostile), since > > it's basically 'illegal' in light of Tuomo's additional terms (which, > > according to Tuomo, "take precedence over the LGPL"). > > It seems a fork-and-rename is consistent with the intent, if not the > terms, of the modified LGPL. intent, maybe, terms, not so sure; if so, i believe Tuomo "unintentionally" made it impossible to fork Ion under a different license, that's why we're still in need of a clarification on his part, and if that indeed was his intention, we have to consider other options. > It would seem a release under a modified LGPL with the rider that the > project or its forks may not be renamed to Ion, ion3, or anything which > would associate it with the Ion project, and may not contain anything > which refers users to the Ion project or Tuomo Valkonen for support, and > that this project and its forks may not change to any license which does > not contain, or invalidates, this rider would be consistent with the > goal of the license. > > IANAL, but shouldn't this be doable in a reasonably straightforward way? > The point of the name change is that it and not referring back to ion is > what's required by the license. > > Yes, it wouldn't be "pure GPL", but if the only additional restriction > is "can't rename this to Ion or ask Tuomo for tech support, must > preserve this restriction", is that going to relegate it to > scary/non-free? It's not restricting a distro from doing anything they'd > actually do anyway [not like the current ion license]. here's the part that, i believe, makes this scenario un-doable: "In the text of sections 0-2, 4-12, and 14-16 of the LGPL, "this License" is to be understood to refer to the LGPL __extended with these terms__ and, where applicable, possible similar terms related to the names of other works forming a whole. Sections 3 and 13 of the LGPL are void. Where contradictory, these additional terms take precedence over the LGPL." this means that every single reference to "this License" in Tuomo's code points to Tuomo's terms (in addition to the LGPL), which makes it 'illegal' for us to replace the license with, say, GPL or something similar. this, of course, is based on my own interpretation of the above text, and is not necessarily correct, so please tell us if you see it differently. regards, M Rawash |
|
From: kevin g. <kev...@gm...> - 2010-04-12 20:36:00
|
On Mon, Apr 12, 2010 at 2:50 PM, M Rawash <mr...@gm...> wrote: > On Mon, 2010-04-12 at 14:30 -0400, Marc Hartstein wrote: >> Excerpts from M Rawash's message of Mon Apr 12 11:25:54 -0400 2010: >> > - fork Ion and change the license (possibly to GPL), this will leave us >> > vulnerable to Tuomo's hostility (assuming he is indeed hostile), since >> > it's basically 'illegal' in light of Tuomo's additional terms (which, >> > according to Tuomo, "take precedence over the LGPL"). >> >> It seems a fork-and-rename is consistent with the intent, if not the >> terms, of the modified LGPL. > > intent, maybe, terms, not so sure; if so, i believe Tuomo > "unintentionally" made it impossible to fork Ion under a different > license, that's why we're still in need of a clarification on his part, > and if that indeed was his intention, we have to consider other options. > >> It would seem a release under a modified LGPL with the rider that the >> project or its forks may not be renamed to Ion, ion3, or anything which >> would associate it with the Ion project, and may not contain anything >> which refers users to the Ion project or Tuomo Valkonen for support, and >> that this project and its forks may not change to any license which does >> not contain, or invalidates, this rider would be consistent with the >> goal of the license. >> >> IANAL, but shouldn't this be doable in a reasonably straightforward way? >> The point of the name change is that it and not referring back to ion is >> what's required by the license. >> >> Yes, it wouldn't be "pure GPL", but if the only additional restriction >> is "can't rename this to Ion or ask Tuomo for tech support, must >> preserve this restriction", is that going to relegate it to >> scary/non-free? It's not restricting a distro from doing anything they'd >> actually do anyway [not like the current ion license]. > > > here's the part that, i believe, makes this scenario un-doable: > "In the text of sections 0-2, 4-12, and 14-16 of the LGPL, "this > License" is to be understood to refer to the LGPL __extended with these > terms__ and, where applicable, possible similar terms related to the > names of other works forming a whole. Sections 3 and 13 of the LGPL are > void. Where contradictory, these additional terms take precedence over > the LGPL." > > this means that every single reference to "this License" in Tuomo's code > points to Tuomo's terms (in addition to the LGPL), which makes it > 'illegal' for us to replace the license with, say, GPL or something > similar. > > this, of course, is based on my own interpretation of the above text, > and is not necessarily correct, so please tell us if you see it > differently. I *think* he's saying that we could perhaps propose such terms to Tuomo and have some chance of him agreeing to it. Personally I'm a bit worried that he'll refuse any compromise we try, but I'd be overjoyed to be proven wrong. -Kevin Granade > > 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 > _______________________________________________ > Notion-devel mailing list > Not...@li... > https://lists.sourceforge.net/lists/listinfo/notion-devel > |
|
From: Aron G. <agr...@n0...> - 2010-04-12 21:47:37
|
M Rawash wrote: [Mon Apr 12 2010, 03:50:56PM EDT] >On Mon, 2010-04-12 at 14:30 -0400, Marc Hartstein wrote: >> Excerpts from M Rawash's message of Mon Apr 12 11:25:54 -0400 2010: >> > - fork Ion and change the license (possibly to GPL), this will leave us >> > vulnerable to Tuomo's hostility (assuming he is indeed hostile), since >> > it's basically 'illegal' in light of Tuomo's additional terms (which, >> > according to Tuomo, "take precedence over the LGPL"). >> >> It seems a fork-and-rename is consistent with the intent, if not the >> terms, of the modified LGPL. > >intent, maybe, terms, not so sure; if so, i believe Tuomo >"unintentionally" made it impossible to fork Ion under a different >license, that's why we're still in need of a clarification on his part, >and if that indeed was his intention, we have to consider other options. To me it seems irrelevant in any case. If Tuomo doesn't clarify and/or give his blessing on a fork, then we are putting distro inclusion at risk. Tuomo would only need to complain and a distro would kick notion out instantly rather than deal with it. Aron |
|
From: M R. <mr...@gm...> - 2010-04-12 19:05:42
|
On Mon, 2010-04-12 at 14:28 -0400, Aron Griffis wrote: > Olof Johansson wrote: [Mon Apr 12 2010, 01:24:00PM EDT] > > On 2010-04-12 18:58, M Rawash wrote: > > > 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). > > > > Google is bound by US law to block users from Iran, Syria, Cuba, etc[1] > > (like SF, but I've read that SF has circumvented this (?)) I'd urge > > against using Google to host free software projects. So, once again, I'd > > recommend using own hosting or maybe Savannah > > I haven't looked at Savannah but I've been impressed with github. > How about using sf.net for web host (unless there's something > better), github.com for code host and librelist.com for mailing > lists? > I'd say we need to be more centralised (imagine someone having to bookmark 3 websites in order to monitor one project, not good), i'd vote for Savannah but i haven't checked all the other options. M Rawash |
|
From: Aron G. <agr...@n0...> - 2010-04-12 21:42:42
|
M Rawash wrote: [Mon Apr 12 2010, 02:58:35PM EDT] >I'd say we need to be more centralised (imagine someone having to >bookmark 3 websites in order to monitor one project, not good), I'm not sure that's really an issue? Lots of projects are split in this manner. Google search for "site:sourceforge.net link:github.com" >i'd vote >for Savannah but i haven't checked all the other options. Savannah is fine with me too. I'm just a fan of github. :-) Aron |
|
From: Ole J. B. <ole...@ya...> - 2010-04-14 21:22:32
|
Sorry for a bit late reply.
Tuomo actually replied already late sunday. His answer was mostly inconclusive for the questions regarding names, renaming, and his future involvement/development on ion. He confirmed what we already assumed/knew though: The license can't be changed to regular LGPL in a renamed fork.
He did say that he sometimes have thought about letting the license go though.
On Mon, 12 Apr 2010 17:25:54 +0200, M Rawash <mr...@gm...> wrote:
> hi everybody, thought I'd give you a little update of what's going on.
> Ole Brønner and I spoke earlier about our legal situation (with regard
> to Tuomo's license); he's in favour of getting Tuomo's blessing to fork
> the latest Ion3(plus) release, while i'm in favour of forking an earlier
> version of Ion that didn't include Tuomo's terms. Ole has contacted
> Tuomo and we have set a deadline ("a couple of days") for a response,
> and since it's very likely that Tuomo won't respond, i think we should
> be aware of our other options while we wait, and here they are:
>
> - forking Ion while keeping Tuomo's license, this, of course, will
> render the fork 'non-free', and infringe on our own right to license any
> future work under a different license.
>
> - fork Ion and change the license (possibly to GPL), this will leave us
> vulnerable to Tuomo's hostility (assuming he is indeed hostile), since
> it's basically 'illegal' in light of Tuomo's additional terms (which,
> according to Tuomo, "take precedence over the LGPL").
>
> - 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).
>
>
> 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
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
>
--
Ole Jørgen Brønner
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X