Menu
▾
▴
notion-devel
|
From: Nedko A. <ne...@ar...> - 2010-08-26 21:37:56
|
Hi, I've imported into git the last ion3 tarball that was digitally signed by Tuomo Valkonen and had unmodified license. The signature and original tarball are in the first commit, the second commit contains the sources only. I personally think it is not worth to try to grow notion in a tainted soil. Even if FSF replies that it is safe to use the latest codebase after name change, it has yet to be proven in a court. And even then the law depends on country. I do understand that there are people who think otherwise. So I propose to let the evolution do its job by allowing both codebases to exist. If newer source snapshots are commited over the commit 9d93ba723a3acf0a14be347a75dada8df972e97a, and are are dual licensed, then they could even be backported to the pristine land. In this codebase, the ion name can be kept because it is pure LGPL but still I think it is a good idea to change the name. I like the notion name and probably it could be possible to have two codebases associated with same project. The cgit view of the repo: http://nedko.arnaudov.name/git/cgit.cgi/ion/ The clone url: http://nedko.arnaudov.name/git/ion.git -- Nedko Arnaudov <GnuPG KeyID: DE1716B0> |
|
From: Joshua T. <egg...@gm...> - 2010-08-27 14:14:13
|
On Fri, Aug 27, 2010 at 12:04:32AM +0300, Nedko Arnaudov wrote: > I personally think it is not worth to try to grow notion in a tainted > soil. Even if FSF replies that it is safe to use the latest codebase > after name change, it has yet to be proven in a court. And even then the > law depends on country. Can I register my bystander's support of at least exploring this option? I am unlikely ever to become an active ion/notion developer, and perhaps that changes the weight of my vote, but put me in the "interested user" category as one who over the years has tried without success to find an ion alternative. My particular concern, in fact, is not the licensing specifically, but is rather knowing that the project will remain active and easily available in common BSD or Linux distributions. An unfamiliar license makes both of those more difficult. That said, I don't honestly have any idea what differences there are between the latest code and this version, so I have no idea how much of a regression is involved if the project chooses this earlier codebase. Nor do I know how likely it is that, as the community begins modifying this earlier codebase, they would avoid adding code "tainted" by later ion versions. But those problems (and probably others I haven't thought of) need to be part of the discussion. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com |
|
From: kevin g. <kev...@gm...> - 2010-08-27 15:59:47
|
+1 for this approach (not that it matters, since you've already made the git repo) While this approach does mean duplicated effort, I think it has promise just via its "just do it" attitude. If we can make this branch reach feature/stability parity with the other branch, then this one will have the best of both worlds, especially since we should be able to backport any changes made to the other branch to this one. I think the first order of business is to determine what exactly is required to make this branch reach feature parity with the "bad license" branch so we have a solid goal (in addition to the rename, which should definitely happen due to the trademark issue). I'm planning on cloning the repository and trying to come to grips with what we need for feature parity tonight. Kevin Granade On Fri, Aug 27, 2010 at 9:14 AM, Joshua Tolley <egg...@gm...> wrote: > On Fri, Aug 27, 2010 at 12:04:32AM +0300, Nedko Arnaudov wrote: >> I personally think it is not worth to try to grow notion in a tainted >> soil. Even if FSF replies that it is safe to use the latest codebase >> after name change, it has yet to be proven in a court. And even then the >> law depends on country. > > Can I register my bystander's support of at least exploring this option? I am > unlikely ever to become an active ion/notion developer, and perhaps that > changes the weight of my vote, but put me in the "interested user" category as > one who over the years has tried without success to find an ion alternative. > My particular concern, in fact, is not the licensing specifically, but is > rather knowing that the project will remain active and easily available in > common BSD or Linux distributions. An unfamiliar license makes both of those > more difficult. > > That said, I don't honestly have any idea what differences there are between > the latest code and this version, so I have no idea how much of a regression > is involved if the project chooses this earlier codebase. Nor do I know how > likely it is that, as the community begins modifying this earlier codebase, > they would avoid adding code "tainted" by later ion versions. But those > problems (and probably others I haven't thought of) need to be part of the > discussion. > > -- > Joshua Tolley / eggyknap > End Point Corporation > http://www.endpoint.com > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkx3yCkACgkQRiRfCGf1UMM0QACgsL9g5iOPhpCp7lvsSzF5Znuf > uPEAnAtD2Yt1z2mW65rkBD68h12tkhcS > =fkS/ > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Notion-devel mailing list > Not...@li... > https://lists.sourceforge.net/lists/listinfo/notion-devel > > |
|
From: Arnout E. <no...@bz...> - 2010-09-03 21:08:10
|
On Fri, Aug 27, 2010 at 12:04:32AM +0300, Nedko Arnaudov wrote: > I personally think it is not worth to try to grow notion in a tainted > soil. Even if FSF replies that it is safe to use the latest codebase > after name change, it has yet to be proven in a court. And even then the > law depends on country. I don't have many fears: afaics, there are 3 groups of stakeholders here, and we're safe from all of them if we stick to our plan of dual-licensing all contributions under both the LGPL and the ION license: - Tuomo: we can honour his license without much problems - all the 'funky' terms and conditions only apply when the product is presented under the 'Ion' name, which we don't. - Contributors: by asking contributors to contribute their code dual-licensed under the ION license and the LGPL, they can't object to their code being incorporated in a product released under either of those. - The FSF: There is some fear the FSF, as the copyright holder for the LGPL, could object to us the ION license being a 'modified' LGPL license. The FSF can confirm whether they think this is a problem for them - unlikely imho. > I do understand that there are people who think otherwise. So I propose > to let the evolution do its job by allowing both codebases to exist. Agreed. > If newer source snapshots are commited over the commit > 9d93ba723a3acf0a14be347a75dada8df972e97a, and are are dual licensed, > then they could even be backported to the pristine land. Also, as we're asking our contributors to dual-license their contributions under LGPL and ION license, you can cherry-pick those contributions you lika (and do not depend on ION-licensed constructs). > In this codebase, the ion name can be kept because it is pure LGPL but > still I think it is a good idea to change the name. I like the notion > name and probably it could be possible to have two codebases associated > with same project. I think giving both the 'picking up where ion changed licenses' fork and the 'picking up where ion3 left off' fork 'notion' *might* be confusing. Perhaps the distinction could be made by having a 'notion1' (the LGPL fork) and a 'notion2' (the ION-licensed fork), though I always found this kind of thing mighty confusing in Jack ;). Arnout |
|
From: kevin g. <kev...@gm...> - 2010-09-03 22:02:37
|
On Fri, Sep 3, 2010 at 4:07 PM, Arnout Engelen <no...@bz...> wrote: > On Fri, Aug 27, 2010 at 12:04:32AM +0300, Nedko Arnaudov wrote: >> I personally think it is not worth to try to grow notion in a tainted >> soil. Even if FSF replies that it is safe to use the latest codebase >> after name change, it has yet to be proven in a court. And even then the >> law depends on country. > > I don't have many fears: afaics, there are 3 groups of stakeholders here, and > we're safe from all of them if we stick to our plan of dual-licensing all > contributions under both the LGPL and the ION license: > > - Tuomo: we can honour his license without much problems - all the 'funky' > terms and conditions only apply when the product is presented under the > 'Ion' name, which we don't. The only thing that really bothers me about Tuomo getting annoyed and doing bad things to the project (and if you ever read this Tuomo, I don't expect you in particular to do anything, it's just that I don't trust anyone) is the trademark on the ion name. I don't know how it works in his jurisdiction, but my reading of case law in the US is pretty clear about embedding a trademarked word in a product name. But that is the case with all of the proposed options since everyone seems to like the notion name so much. > > - Contributors: by asking contributors to contribute their code dual-licensed > under the ION license and the LGPL, they can't object to their code being > incorporated in a product released under either of those. But they might not want to contribute to a codebase that is under the ION license. Personally I don't want to contribute to anything non-free, even if it is dual-licensed with a free license. > > - The FSF: There is some fear the FSF, as the copyright holder for the LGPL, > could object to us the ION license being a 'modified' LGPL license. The FSF > can confirm whether they think this is a problem for them - unlikely imho. > There is a stakeholder you are skipping, users, and more specifically distributions. My primary concern as a user is that the software is available on whatever distribution I'm using at the moment (I don't always have time to build from source), and having the license situation be weird potentially interferes with distribution uptake. >> I do understand that there are people who think otherwise. So I propose >> to let the evolution do its job by allowing both codebases to exist. > > Agreed. Haha, like either group has a choice :) Although I think I do understand your intent, which is that there is no need to argue about it. > >> If newer source snapshots are commited over the commit >> 9d93ba723a3acf0a14be347a75dada8df972e97a, and are are dual licensed, >> then they could even be backported to the pristine land. > > Also, as we're asking our contributors to dual-license their contributions > under LGPL and ION license, you can cherry-pick those contributions you lika > (and do not depend on ION-licensed constructs). Even if they do depend on ION-licensed constructs, we should be able to work around that in most cases, the contribution itself will be LGPL, and therefore we can modify it as we see fit to work with our codebase. > >> In this codebase, the ion name can be kept because it is pure LGPL but >> still I think it is a good idea to change the name. I like the notion >> name and probably it could be possible to have two codebases associated >> with same project. The trademark on the ion name is also an issue regardless of the license, and I think changing to notion is at least slightly better than sticking with ion. > > I think giving both the 'picking up where ion changed licenses' fork and the > 'picking up where ion3 left off' fork 'notion' *might* be confusing. > > Perhaps the distinction could be made by having a 'notion1' (the LGPL fork) > and a 'notion2' (the ION-licensed fork), though I always found this kind of > thing mighty confusing in Jack ;). Speaking solely for myself, my intent with the "pre-license change" fork of ion is to bring it up to par with the other fork just to clear up the license issue, and then see where things go from there. Hopefully it won't last long enough for real confusion to set in. Good luck to all of us, Kevin > > > Arnout > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Notion-devel mailing list > Not...@li... > https://lists.sourceforge.net/lists/listinfo/notion-devel > |
|
From: Arnout E. <no...@bz...> - 2010-09-03 22:36:37
|
On Fri, Sep 03, 2010 at 05:02:30PM -0500, kevin granade wrote: > Personally I don't want to contribute to anything non-free, even if it is > dual-licensed with a free license. Of course, the ION license is not *that* non-free - it might actually even be DFSG-free, for example. All the nasty stuff only applies when you distribute the softare under the name 'Ion'. But let's not get into the 'my license is free-er than yours' discussion too much ;). > There is a stakeholder you are skipping: Obviously - I was just talking about 'stakeholders' that might have a *legal* objection to what we're doing > users, and more specifically distributions. > My primary concern as a user is that the software is > available on whatever distribution I'm using at the moment (I don't > always have time to build from source), and having the license > situation be weird potentially interferes with distribution uptake. Though that's a valid concern, on the other hand there's plenty of proprietary software pretty conveniently available for most distro's, and we can probably do even better. > > I think giving both the 'picking up where ion changed licenses' fork and the > > 'picking up where ion3 left off' fork 'notion' *might* be confusing. > > > > Perhaps the distinction could be made by having a 'notion1' (the LGPL fork) > > and a 'notion2' (the ION-licensed fork), though I always found this kind of > > thing mighty confusing in Jack ;). > > Speaking solely for myself, my intent with the "pre-license change" > fork of ion is to bring it up to par with the other fork just to clear > up the license issue, and then see where things go from there. This is a good idea. My fear is/was that it will not materialize. There's a lot of talk (and yes, I'm partly guilty of that too :) ), but only a few people have actually moved the project forward since it was abandoned in september 2009. Forking the latest version (and taking the weird license for granted) will provide an upgrade path for existing ion3 users that is as painless as possible, with the least amount of effort required - and even this is taking longer than I had hoped. > Hopefully it won't last long enough for real confusion to set in. > Good luck to all of us, Indeed :) Arnout |
×
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