[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: orphaning fetchmail

On Sat, Dec 16, 2000 at 12:25:19AM -0700, John Galt wrote:
> > > Rewriting the damned GPL to be compatible with the rest of the
> > > world might be a good place to start rewriting.

On Sat, 16 Dec 2000, Raul Miller wrote:
> > If the damned GPL didn't have that "incompatibility" there would be
> > no Debian, BSD would probably still require you signed a license
> > agreement before you could look at it, and we'd probably be arguing
> > in some AOL chatroom about some Microsoft breakage.

On Sun, Dec 17, 2000 at 05:09:30AM -0700, John Galt wrote:
> But this isn't then. This is now, where the list of free licenses that
> the GPL is incompatible with is practically larger than the list that
> it is compatible with.

Did you know that, around 10 years before the GPL was written, almost
*all* software was freely distributed in source form, to those people
who were interested?

> If the GPL is truly the progenitor of the free software movement
> (damn, all those EULAS I had to have signed to read Byte back
> in the day must've killed my hand: no click-wrap licensing back
> then--clicking was still ten years in the future), then it's a
> dinosaur now, doing more harm than good.

I don't think of it as the progenitor of the free software movement. It's
a reactionary move, designed to "recapture the golden age".

I think the results justify its continued use.

> Time to relegate it to the shelves with the whole idea of licensing
> software: you don't go to the grocery store to get a license for
> food, so why should you go to the computer store to get a license for
> software?

Sure: after all, we're talking about technical designs here, not works
of literature. Copyright isn't designed for this, and we shouldn't have
to worry about it, right?

> > > > OpenSSL is doing something approximately in that direction, but
> > > > I don't see that it solves all the problems.
> > >
> > > Where's the technical issue? The only problem that's been
> > > postulated is the license combatibility.
> > 
> > See the message with the header:
> > Message-ID: <[🔎] 976974718.2f70b09e@debian.org>
> I could not find it in the thread.  lists.debian.org has no search by
> message-ID functionality, so you lost me here.

Well, were you reading the other messages posted to debian-legal that day?
This is the one I wrote about the race conditions in using a two way
pipe, how I wasn't confident of openssl's design for this context,
and how the docs indicate that s_client is for testing purposes only.

> > > > Non-GPL authors are perfectly free to reimplement GPLed works, if
> > > > they don't like the GPL license.  Why shouldn't GPL authors be free to
> > > > reimplement non-GPL works if they don't like the non-GPL license?
> > > 
> > > Are they?  Show me one successful case.
> > 
> > See the message with the header:
> > Message-ID: <[🔎] 20001216021741.W4445@osiris.978.org>
> Recieved about an hour after I said this...BTW, I doubt that it could be
> consdiered very successful: the usage of the replacement isn't exactly
> widespread.  It gives new meaning to the term "released to a chorus of
> yawns".  A fitting fate for all political rewrites, IMHO.

A fate which most software receives, until it satisfies some
personal need of the audience.

> > > > > Would it even have more difference than the legal minimum to
> > > > > make it a separate work?
> > > >
> > > > If it's an independent rewrite, perhaps to a different
> > > > underlying api, then it would pretty much have to be an
> > > > independent work.
> > >
> > > Aha! If the API is screwed, that isn't just a political issue now
> > > is it?
> >
> > Screwed? More like: in spite of all that you've tried to teach me, I
> > still have this underlying concept that there's more than one way to
> > do it.
> By all means do it a different way, just do it to sctratch an itch
> rather than to play political games. If the itch is bad enough,
> scratch away.

At the moment, it looks like someone else had an analogous itch
(ssltunnel).  So I might not have to scratch.

[That was posted to this list yesterday, by the way -- I don't
suppose you missed that one too?]

> > > > >  Would EAY recognize it as a different way to do it?
> > > >  
> > > > Copyright isn't about functionality.  It's about literal copying.
> > > 
> > > ...which you have every right to do ATM, just so long as you don't
> > > plagiarize.  My question still stands: if the programs are so similar that
> > > the author can't tell the difference, how technically oriented was the
> > > change?
> > 
> > What are you talking about?
> The ad clause is simply the Academic's viewpoint that one should not take
> credit for work that one hasn't done.  Failing to give credit to others in
> an academic arena is grounds for Not Very Nice Things to happen.

But that ad clause doesn't belong in the copyright statement -- at least
not in the U.S.  Advertisements are not redistribution.

That ad clause (or something similar, phrased more positively) should
probably go in the How-to-Use-this documentation.

> > > > > This just sounds like an Orwellian redefinition of the BSDL, not a
> > > > > different way to do things.
> > > > 
> > > > I suppose you could describe the openssl license as an orwellian
> > > > redefinition...  [To address the comment I think you were trying to
> > > > express, but did not: I don't see how you could describe someone else's
> > > > independent authoring of code as orwellian redefinition of the BSDL,
> > > 
> > > If it were truly independent, no. But what you're proposing isn't
> > > independent is it? The dependency lies in WHY the program was
> > > authored. If it were authored because the new author has a better way
> > > to do it, then we have the issue of the original author having the
> > > beholden right to do whatever they want with their code. If it was
> > > rewritten just because the author disagreed with the licensing terms,
> > > and the terms are DFSG free, it isn't Debian's place to encourage
> > > it--making free variants of non-free programs is well within the SC,
> > > making free variants of already free programs is something that Debian
> > > should accept if as a _fait accompli_ but not go out of its way to
> > > start.
> > 
> > I don't have a clue what you're talking about.
> Why should Debian get behind a rewriting of DFSG free software because
> of licensing issues? The license passes muster, end of story as far
> as Debian goes. My issue is not with the rewrite if that's what you
> want to do, my issue is that the reasons you cite for your rewrite are
> invalid on their face: openssl is already DFSG free.

What do you mean "get behind"?  

If you mean "distribute the final result", why not?  That's what Debian

If you mean "one, or maybe several debian developers do the development",
who cares?  Debian doesn't own the developers.

If you mean "all debian developers must contribute", why even bother?
That would solve nothing.  But, yeah, I agree that this non-solution
would be inappropriate for Debian.



Reply to: