[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-licensing
Subject:    Re: KDE tries to silence editorial's author
From:       forge <forge () myrealbox ! com>
Date:       2000-06-19 10:45:30
[Download RAW message or body]

One thing though.  What's wrong with section 4 ?

Joseph Carter wrote:
> 
> On Sun, Jun 18, 2000 at 06:38:14PM -0400, forge wrote:
> > > You're far more optimistic than I am.  Part of the KDE project?  Ick,
> > > don't say that.  I just came in here to help people wash up muddy
> > > licenses (or so I thought..)
> >
> > I am a pessimist by upbringing actually.  ( I live in Jamaica.  The
> > weather is nice, the women are beautiful and everything else tries to
> > make you hide behind the excellent Rum and Ganja :).  My optimism is
> > born of the notion that this might all work out.
> 
> After 3.5 years of hostility, more than 2 of that with me at the center?
> I was optimistic then.
> 
> > > Therefore we're paranoid bastards.  It's not political, it's us covering
> > > our collective asses so to speak.  As for me personally, um, well, I
> > > didn't let ITAR stop me from distributing strong crypto worldwide, do you
> > > think a silly little patent interfere with my life?  Good guess.
> >
> > Good.  So keep focused on why you do this.  It's the principle.
> > Nothing more or less.
> 
> Principle has a lot to do with the reason why we don't accept implicit
> licensing, The problems with making it explicit (or unnecessary) are what
> concern me individually.
> 
> > > A couple in sections 3 and 4, 6(c) could be real easily fixed by changing
> > > the wording a bit to allow pretty much anyone access to the source code if
> > > the binaries are distributed.
> >
> > 3. You may make modifications to the Software and distribute your
> > modifications, in a form that is
> >   separate from the Software, such as patches. The following
> > restrictions apply to modifications:
> >
> > 3. You may make modifications to the Software and distribute your
> > modifications, in a form that is easily distinguishable from the
> > Software, such as patches. The following restrictions apply to
> > modifications:
> 
> I'd have tacked "original" before the second instance of "Software".
> 
> > 6c. If the items are not available to the general public, and the
> > initial developer of the Software requests a copy of the items,
> > then you must supply one.
> >
> > 6c. If the items are not available to the general public, and the
> > initial developer of the Software requests a copy of the items,
> > then you must supply one.  For items under the GPL we may instead
> > check to see weather your distribution is in compliance with the
> > terms of the GPL.  This includes not obstructing anyone who may
> > wish to redistribute.
> 
> That's crazy enough (you'd have to spell out GNU General Public License
> most likely) that it may just work.  I still think it could probably serve
> with a rewrite though.
> 
> > The changes to section 3 are cosmetic but make it a little clearer
> > that patches are mearly preferred.  pointing to the original source
> > and instruction on running "diff" would also work.
> 
> This was my intent with the original drafts.
> 
> > The changes to 6c are a little crude.  The idea is that compliance
> > with the GPL becomes something Troll can investigate since
> > violating the GPL on something linked to QT means also violating
> > the QPL.  sending source code to all the employees for your
> > internal custom apps is not something companies do.  least of all
> > ones likely to try cheating Troll out of a few bucks.
> 
> If you seriously, honestly think there's a chance in hell that anybody at
> Troll Tech is actually likely to take it seriously, I can put the QPL
> through the wringer again and see what comes out.  I don't have your
> optimism though, so don't expect any serious fight from me to see it
> become more than a simple draft of what could end this.
> 
> --
> Joseph Carter <knghtbrd@debian.org>               GnuPG key 1024D/DCF9DAB3
> Debian GNU/Linux (http://www.debian.org/)         20F6 2261 F185 7A3E 79FC
> The QuakeForge Project (http://quakeforge.net/)   44F9 8FF7 D7A3 DCF9 DAB3
> 
> <Knghtbrd> it's too bad most old unices turned out y2k compliant
> <Knghtbrd> because it means people will STILL BE RUNNING THEM in 30 years
>            =p
> <Knghtbrd> it would have been so much nicer if y2k effectively killed off
>            hpux, aix, sunos, etc  ;>
> <Espy> Knghtbrd: since when are PH-UX, aches, and solartus "old"?

[prev in list] [next in list] [prev in thread] [next in thread]