RFC: ion license

Matti Bickel wrote:
> It's main additions are a "timely response
clause", which
> requires us to get the same keywords for a newly
released version as the
> previous had within 28 days. Another point is the
"no patches" clause,
> which prohibits distributions from carrying a
"significantly modified"
> ion-3 release under the ion name.

So just rename the package to something that "clearly
illustrates that
this isn't teh upstream Ion anymore!!!111one" and be
done with that. If
users complain, ask them to talk to Tuomo Valkonen.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

Jan Kundrát wrote:
> Matti Bickel wrote:
>> It's main additions are a "timely response
clause", which
>> requires us to get the same keywords for a newly
released version as the
>> previous had within 28 days. Another point is the
"no patches" clause,
>> which prohibits distributions from carrying a
"significantly modified"
>> ion-3 release under the ion name.
> 
> So just rename the package to something that
"clearly illustrates that
> this isn't teh upstream Ion anymore!!!111one" and
be done with that. If
> users complain, ask them to talk to Tuomo Valkonen.

Perhaps "atom," an uncharged single ion. =)

Thanks,
Donnie

Jan Kundrát napsal(a):
> Matti Bickel wrote:
>> It's main additions are a "timely response
clause", which
>> requires us to get the same keywords for a newly
released version as the
>> previous had within 28 days. Another point is the
"no patches" clause,
>> which prohibits distributions from carrying a
"significantly modified"
>> ion-3 release under the ion name.
> 
> So just rename the package to something that
"clearly illustrates that
> this isn't teh upstream Ion anymore!!!111one" and
be done with that. If
> users complain, ask them to talk to Tuomo Valkonen.
> 
> Cheers,
> -jkt
> 

Well, one could ask why we should provide ebuild for stuff
that has
apparently insane upstream, instead of just dropping such
junk until the
upstream guy realizes that the world doesn't spin around
him.


-- 
Best regards,

 Jakub Moc
 mailto:jakubgentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=g
et&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F
8717 D5FD CEBA 3D9E

 ... still no signature   ;)

On Sun, 2007-05-13 at 00:41 +0200, Jakub Moc wrote:
> Well, one could ask why we should provide ebuild for
stuff that has
> apparently insane upstream, instead of just dropping
such junk until the
> upstream guy realizes that the world doesn't spin
around him.

But if we did this, we'd have no cdrecord. ;)
-- 
Peter Gordon (codergeek42) / FSF & EFF Member
Gentoo Forums Global Moderator
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
My Blog: http://thecodergeek.com
/blog/

Peter Gordon napsal(a):
> On Sun, 2007-05-13 at 00:41 +0200, Jakub Moc wrote:
>> Well, one could ask why we should provide ebuild
for stuff that has
>> apparently insane upstream, instead of just
dropping such junk until the
>> upstream guy realizes that the world doesn't spin
around him.
> 
> But if we did this, we'd have no cdrecord. ;)

That's why we have app-cdr/cdrkit now... 


-- 
Best regards,

 Jakub Moc
 mailto:jakubgentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=g
et&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F
8717 D5FD CEBA 3D9E

 ... still no signature   ;)

On Sun, 13 May 2007 00:13:57 +0200
Matti Bickel <mabigentoo.org> wrote:
> recently, there's been some worries about the changes
and new
> requirements the ion upstream, tuomov, put forth in a
new LICENSE for
> ion-3. It's main additions are a "timely response
clause", which
> requires us to get the same keywords for a newly
released version as
> the previous had within 28 days. Another point is the
"no patches"
> clause, which prohibits distributions from carrying a
"significantly
> modified" ion-3 release under the ion name.

Supporting this would be a huge policy violation, and not so
merely as
a technicality. I suggest simply removing ion support from
the main
tree, and sticking it in an overlay that comes with a big
warning
telling users that they cannot expect any level of QA for
those
packages.

-- 
Ciaran McCreesh

On Sun, 2007-05-13 at 01:19 +0100, Ciaran McCreesh wrote:
> Supporting this would be a huge policy violation, and
not so merely as
> a technicality. I suggest simply removing ion support
from the main
> tree, and sticking it in an overlay that comes with a
big warning
> telling users that they cannot expect any level of QA
for those
> packages.

Could we not simply rename it, as has been suggested many
times thus
far? Then we could mask ion3 and let people know why and
what it was
renamed to, et al.
-- 
Peter Gordon (codergeek42) / FSF & EFF Member
Gentoo Forums Global Moderator
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
My Blog: http://thecodergeek.com
/blog/

On Sat, 12 May 2007 18:22:41 -0700
Peter Gordon <codergeek42gentoo.org> wrote:
> Could we not simply rename it, as has been suggested
many times thus
> far? Then we could mask ion3 and let people know why
and what it was
> renamed to, et al.

Presumably this would require maintaining updated
documentation,
patches to change the program binary name and configuration
paths
etc... In which case it should be done as an external fork,
not a
Gentoo thing.

Really, I don't see why there's a need to go out of the way
for this.
Upstream clearly don't want their package in the tree, and
the
devmanual [1] says that that wish should be respected.

[1]: http://devmanual.gentoo.org/general-concepts/tree/in
dex.html

-- 
Ciaran McCreesh

PETER GORDON WROTE:
> ON SUN, 2007-05-13 AT 01:19 +0100, CIARAN MCCREESH
WROTE:
>> SUPPORTING THIS WOULD BE A HUGE POLICY VIOLATION,
AND NOT SO MERELY AS
>> A TECHNICALITY. I SUGGEST SIMPLY REMOVING ION
SUPPORT FROM THE MAIN
>> TREE, AND STICKING IT IN AN OVERLAY THAT COMES WITH
A BIG WARNING
>> TELLING USERS THAT THEY CANNOT EXPECT ANY LEVEL OF
QA FOR THOSE
>> PACKAGES.
> 
> COULD WE NOT SIMPLY RENAME IT, AS HAS BEEN SUGGESTED
MANY TIMES THUS
> FAR? THEN WE COULD MASK ION3 AND LET PEOPLE KNOW WHY
AND WHAT IT WAS
> RENAMED TO, ET AL.

AS FAR AS I CAN TELL, WE TRY NOT TO BE "UPSTREAM"
AS SUCH; JUST TO STICK
CLOSELY TO THE PACKAGE(S) UPSTREAM PUTS OUT UNTIL THE
SITUATION BECOMES
UNTENABLE.

I AGREE WITH CIARAN; REMOVING IT IS A GOOD IDEA AS LONG AS
UPSTREAM'S
LICENSING SCHEME IS RETARDED.

JUST KEEPING IT IN THE TREE (UNDER A NEW NAME) UNTIL IT
COMPLETELY STOPS
WORKING EVENTUALLY DOESN'T SOUND LIKE A BETTER IDEA THAN
REMOVAL.

CIARAN MCCREESH <CIARANMCIARANM.ORG> WROTE:
> SUPPORTING THIS WOULD BE A HUGE POLICY VIOLATION, AND
NOT SO MERELY AS
> A TECHNICALITY.

HOW'S THAT? I AGREE THAT THIS TIMELY RESPONSE CLAUSE WILL
MEAN ION-3 WILL
NEVER GO STABLE. THAT'S THE ONLY THING I COULD ENVISION TO
BE A POLICY
VIOLATION.

> I SUGGEST SIMPLY REMOVING ION SUPPORT FROM THE MAIN
> TREE, AND STICKING IT IN AN OVERLAY THAT COMES WITH A
BIG WARNING
> TELLING USERS THAT THEY CANNOT EXPECT ANY LEVEL OF QA
FOR THOSE
> PACKAGES.

CARE TO EXPAND ON "NO QA"? TUOMO FIXED SEVERAL QA
WARNINGS UPSTREAM (MISSING
STRLEN, ETC. INCLUDES) WHEN I TOLD HIM (THERE WILL BE
PATCHES ON OUR SIDE
UNTIL THE NEXT _RC).
ADDITIONALLY I'D LIKE TO POINT OUT THE BIT WHERE HE SAYS HE
DON'T WANT THIS
LICENSE TO HINDER DISTRIBUTIONS WHO JUST STICK WITH
UPSTREAM, WHICH OUR POLICY
EXPLICITLY RECOMMENDS. THAT'S WHY I'M TRYING TO REACH A
COMPROMISE ON THOSE
USE PATCHES WE APPLY. THAT'S WHY THE NEXT BUILD WILL TELL
PPL TO BUG ME FIRST.

IN GENERAL: I DON'T THINK FORKING IS AN OPTION. I WON'T BE
MAINTAINING A FORK
MYSELF TO BEGIN WITH. IF THE GENERAL FEELING IS THAT ION IS
UNACCEPTABLE IN
THE TREE, I'LL MASK IT PENDING REMOVAL.
-- 
REGARDS, MATTI BICKEL
ENCRYPTED/SIGNED EMAIL PREFERRED

On Sun, 13 May 2007 09:57:05 +0200
Matti Bickel <mabigentoo.org> wrote:
> Ciaran McCreesh <ciaranmciaranm.org> wrote:
> > Supporting this would be a huge policy violation,
and not so merely
> > as a technicality.
> 
> How's that? I agree that this timely response clause
will mean ion-3
> will never go stable. That's the only thing i could
envision to be a
> policy violation.

Right, and packages that aren't aiming for stable eventually
shouldn't
really be in the tree at all.

A larger issue, though... It requires some way of pushing
updates to a
user who hasn't synced for >28 days.

> > I suggest simply removing ion support from the
main
> > tree, and sticking it in an overlay that comes
with a big warning
> > telling users that they cannot expect any level of
QA for those
> > packages.
> 
> Care to expand on "no QA"? Tuomo fixed
several QA warnings upstream
> (missing strlen, etc. includes) when i told him (there
will be
> patches on our side until the next _rc).

If upstream release a new version that has a serious bug,
Gentoo would
be required to include it as the most visible package within
28 days,
even if it is completely unusable.

> Additionally i'd like to point out the bit where he
says he don't
> want this license to hinder distributions who just
stick with
> upstream, which our policy explicitly recommends.
That's why i'm
> trying to reach a compromise on those USE patches we
apply. That's
> why the next build will tell ppl to bug me first.

If he doesn't want to hinder distributions, get him to fix
his licence.
The way it is now makes it impossible for distributions to
do their job.

> In general: i don't think forking is an option. I won't
be
> maintaining a fork myself to begin with.

Probably true, from a Gentoo perspective. If there's a
significant ion
userbase, someone else will do the work.

-- 
Ciaran McCreesh

On Sunday, May 13, 2007 09:57:05 AM Matti Bickel wrote:
> If the general feeling is that ion is
> unacceptable in the tree, i'll mask it pending
removal.

Having read the threads you referenced, I don't think
there's much room 
for a compromise. 

In the conversation with you, Matti, he argues that elog is

not "prominent" enough, users don't read USE flag
descriptions, etc.
So those issues seem unresolved.

Reading the rest of those mail exchanges makes it even look
worse.

I don't think he'll ever really be satisfied. So I'd suggest
to drop ion3.

Best regards, Wulf

Maybe the following are also interesting in this context:

Debian:
   <http://womble.decadent.org.uk/blog/renaming-of-ion3>
   <ht
tp://forums.debian.net/viewtopic.php?p=69522>
Archlinux:
   <http://www.archlinux.org/pipermail/tur-us
ers/2007-April/004634.html>

I wonder if a package should be kept whose author is
threatening with
"legal repercurssions" [sic].

Ulrich
-- 
gentoo-devgentoo.org mailing list

CIARAN MCCREESH <CIARANMCIARANM.ORG> WROTE:
> MATTI BICKEL <MABIGENTOO.ORG> WROTE:
> > HOW'S THAT? I AGREE THAT THIS TIMELY RESPONSE
CLAUSE WILL MEAN ION-3
> > WILL NEVER GO STABLE. THAT'S THE ONLY THING I
COULD ENVISION TO BE A
> > POLICY VIOLATION.
> 
> RIGHT, AND PACKAGES THAT AREN'T AIMING FOR STABLE
EVENTUALLY SHOULDN'T
> REALLY BE IN THE TREE AT ALL.

POINT TAKEN. TBH, I DON'T THINK ALLOWING ION TO REMAIN IN
~ARCH WOULD BE
A BIG DEAL THOUGH.

> A LARGER ISSUE, THOUGH... IT REQUIRES SOME WAY OF
PUSHING UPDATES TO A
> USER WHO HASN'T SYNCED FOR >28 DAYS.

THE LICENSE EXPLICITLY MAKES A EXCEPTION FOR A USER WHO
HASN'T UPDATED
OR IS WITHOUT NET CONNECTION, DEMANDING THE NEW VERSION TO
BE SHOWN AT
NEXT INSTALL/UPGRADE CYCLE AFTER THE SYNC.

> IF UPSTREAM RELEASE A NEW VERSION THAT HAS A SERIOUS
BUG, GENTOO WOULD
> BE REQUIRED TO INCLUDE IT AS THE MOST VISIBLE PACKAGE
WITHIN 28 DAYS,
> EVEN IF IT IS COMPLETELY UNUSABLE.

IN THAT CASE, I WILL PROVIDE A PATCH OR PULL THE PACKAGE, IF
UPSTREAM
DISAGREES. HOWEVER, IF IT'S A CRITICAL FIX (SECURITY), I
TRUST UPSTREAM
TO RELEASE A NEW VERSION ASAP. ON THAT NOTE: THE QA WARNINGS
HAVE A
PATCH WITH GENTOO AND WILL BE INCLUDED IN THE NEXT UPSTREAM
RELEASE. I
INTEND TO HANDLE ANY OTHER FIX THE SAME WAY, AND UPSTREAM
HAS NOT SPOKEN
OUT AGAINST THIS.

> IF HE DOESN'T WANT TO HINDER DISTRIBUTIONS, GET HIM TO
FIX HIS LICENCE.
> THE WAY IT IS NOW MAKES IT IMPOSSIBLE FOR DISTRIBUTIONS
TO DO THEIR JOB.

WE ALL AGREE IT'S RETARDED. HOWEVER, I CAN'T CHANGE THE WAY
IT IS.

> > IN GENERAL: I DON'T THINK FORKING IS AN OPTION. I
WON'T BE
> > MAINTAINING A FORK MYSELF TO BEGIN WITH.
> 
> PROBABLY TRUE, FROM A GENTOO PERSPECTIVE. IF THERE'S A
SIGNIFICANT ION
> USERBASE, SOMEONE ELSE WILL DO THE WORK.

THERE'S ALREADY SOMEONE DOING THE WORK FOR GENTOO. LOOK AT
BUG
#136077, WHICH IS, TBH, ONE OF MY MAIN MOTIVATORS TO WORK ON
THAT
PACKAGE. I JUST FEEL THAT LETTING (CONTRIBUTING) USERS DOWN
WOULD BE
KIND OF A SHAME.
-- 
REGARDS, MATTI BICKEL
ENCRYPTED/SIGNED EMAIL PREFERRED

WULF C. KRUEGER <PHILANTROPGENTOO.ORG> WROTE:
> IN THE CONVERSATION WITH YOU, MATTI, HE ARGUES THAT
ELOG IS 
> NOT "PROMINENT" ENOUGH, USERS DON'T READ USE
FLAG DESCRIPTIONS, ETC.
> SO THOSE ISSUES SEEM UNRESOLVED.

WELL, THIS ARGUMENTS ARE NOTHING NEW, JUST READ THIS ML..
HOWEVER, I DON'T THINK THINK HIS REASONING IS JUSTIFIED
HERE. WE DO
INFORM THE USER, EVERYTHING ELSE IS NOT WITHIN OUR REACH.
AND IMHO THE
LICENSE DOESN'T REQUIRE MORE.
IF I GET A CEASE AND DESIST OVER *THAT*, WELL, SCREW IT.
-- 
REGARDS, MATTI BICKEL
ENCRYPTED/SIGNED EMAIL PREFERRED

On Sun, 13 May 2007 10:34:42 +0200
Matti Bickel <mabigentoo.org> wrote:
> > If he doesn't want to hinder distributions, get
him to fix his
> > licence. The way it is now makes it impossible for
distributions to
> > do their job.
> 
> We all agree it's retarded. However, i can't change the
way it is.

Well, you can drop support from the tree... I suspect
upstream might
change their tune if distributions stick their collective
feet down.

> > > In general: i don't think forking is an
option. I won't be
> > > maintaining a fork myself to begin with.
> > 
> > Probably true, from a Gentoo perspective. If
there's a significant
> > ion userbase, someone else will do the work.
> 
> There's already someone doing the work for gentoo. Look
at bug
> #136077, which is, tbh, one of my main motivators to
work on that
> package. I just feel that letting (contributing) users
down would be
> kind of a shame.

Move it to an overlay. People have far lower expectations
from
overlays...

-- 
Ciaran McCreesh

Rob C a écrit :
> Just my 0.02 chf

+0.02eur from me too.

This is going waaay beyond the FireFox/IceWeasle trademark
issue. Even 
closed source apps are less painful license-wise.

I'd advise all ion3 users from Gentoo (and maybe other
distros) to get 
together and fork it (ŕ la dhcpcd), doing everyone a favor.

Rémi
-- 
gentoo-devgentoo.org mailing list

On Saturday 12 May 2007, Donnie Berkholz wrote:
> Jan Kundrát wrote:
> > Matti Bickel wrote:
> >> It's main additions are a "timely
response clause", which
> >> requires us to get the same keywords for a
newly released version as the
> >> previous had within 28 days. Another point is
the "no patches" clause,
> >> which prohibits distributions from carrying a
"significantly modified"
> >> ion-3 release under the ion name.
> >
> > So just rename the package to something that
"clearly illustrates that
> > this isn't teh upstream Ion anymore!!!111one"
and be done with that. If
> > users complain, ask them to talk to Tuomo
Valkonen.
>
> Perhaps "atom," an uncharged single ion. =)

the words "uncharged ion" dont belong together as
an ion by definition carries 
a charge :p
-mike