Re: Copyright response from Pine Development

[Raul Miller <rdm@tad.micro.umn.edu>]

Mark Crispin:
	   2) for-profit organizations must ask UW for permission
	      before distributing Pine.  All this means is that they
	      must recognize UW's rights.  They can not claim to have
	      "taken over Pine" and then sue UW to stop Pine work at
	      UW.  UW has never said "no", and never intends to say
	      "no".

NO!

That's not what it says, so that's not what it means in a contractual
sense.

What it *means* is that no one is allowed to distribute this program
in a commercial environment without the permission of UW.

Thus, if UW changes their policy at some future time (say, if pine
should ever become a de-facto standard), then UW can begin limiting
commercial distribution of pine.  Given a few major releases, everyone
using pine would start getting locked into this deal.  [Note that UW
has never given anyone blanket permission to redistribute pine, in the
fashion of BSD or GNU.]

Mark Crispin:
   The GPL is much more restrictive.

This is pure PR flack.  The GPL is more restrictive in certain
contexts, and less restrictive in others.

   The GPL prohibts people from modifying Pine and distributing it
   unless they also give out sources.  It makes it impossible to build
   any derivative proprietary products if any GNU code is present.

This is completely false.  The GPL makes no such restriction.

This statement *would* be true *if* pine was only available under the
terms of GPL and UW wouldn't make it available under any other terms.

This doesn't even make sense in the context of a letter that implies
that UW will grant reasonable permissions "indefinitely" to commercial
vendors.

Bruce Perens writes:
 > I think it's symptomatic of the problems Richard has created for himself.

I think he's had a lot of help creating these problems.

Personally, I dislike the very concept of attacking a person for their
views.  I much, much prefer to attack their views.

I hate having to waste my time pointing out these logical flaws.

But, what alternative do I have?  I suppose I could leave Debian, but
I also dislike that kind of tactic.  [My approach would be to simply
treat Debian with lower priority.]

 > We have to face that Richard Stallman is a tremendous public
 > relations liability. Nobody rails about the Artistic or BSD
 > licenses the way they do about the GPL - they are really objecting
 > to Richard's modus opperandi, not anything they read in the GPL.

I think you're pretty close to the truth here, but I think you're off
the mark a bit.

Richard is, as I understand it, arrogant.  But I've dealt with lots of
arrogant people -- some far more arrogant than him.  In past dealings
with the people at UW, they've come across rather arrogantly as well.
Larry Wall would even classify arrogance as a virtue in a developer.

Linus uses the GPL, and also is very high-handed at times, but since
we're within the community of Linux users, we don't see people
complaining about that.  Mostly, because Linus is providing a constant
stream of changes, people have a reasonable expectation that their
concerns will be addressed as soon as is reasonable.

Richard, if I understand correctly, has a problem with his wrists.
So, he is not as productive as Linus.  So, people don't see him as
being particularly competent.  And, maybe at this stage, maybe he
isn't...

Anyways, Richard has a fair level of help in creating his reputation.
He's been around for years, and his views have a significant (not
overwhelming, but significant) effect on the success/failure of
commercial products.  Thus, you see people using turf tactics in the
definition of the issues around commercial products...  Some of this
has validity.  A lot of it is pure bullshit.

 > Thus, our negociations should give us both association _AND_ distance,
 > so that we don't have to support everything he says.

I thought this was already the case?

Anyways, I prefer to leave things like rms's differences with debian
on "how things should be done" on the priority list, but to demote
them below other (related or conflicting) issues.

For example, there are some real physical problems with storage
management in the context of unstripped binaries.  There are some real
advantages to having unstripped binaries.  At the moment, the physical
problems outweigh the advantages.

Ideally, we'd file this as "can't do it now", not "we'll never want to
do this".  Technical issues can change.  User needs can change.  Also,
I can see defining an official "beta release" state for a package
where it *is* distributed with unstripped binaries, and a "stable
release" state where it *isn't* -- however, I wouldn't want to tackle
that right now.

See what I'm saying?

If we make this into personal issues, we lose.  Flat out.  Personal
issues result in disrupted relationships [technical relationships and
otherwise].

If we leave this stuff as technical issues, we win.  Technical issues
are solvable.

-- 
Raul