httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] ap_add_filter
Date Sun, 20 Aug 2000 21:37:03 GMT

In a message dated 00-08-20 18:04:34 EDT, Jim writes...

>  > That still doesn't answer the question about will the inclusion
>  > of ZLIB with Apache source be AOK or not but it's a start.
>  not up to me. i don't see why there would be a problem.

Neither do I.
So... if a filtering patch showed up tomorrow at Apache with a full 
ZLIB code dump in it... would it be rejected for that reason alone?

That's simply a YES or NO question. ( See below )

>  > What about 'deflate' and 'inflate' which is what ZLIB uses?
>  deflate (and inflate) are algorithms. well-documented in rfc 1951
>  ( according to the
>  prevailing wisdom, it is possible to implement those algorithms
>  without infringing any patents, and the zlib implementation of
>  them does not infringe any patents.

Yes, yes... I know they are just algorithms... but it is CODE I 
was talking about. The actual 'official' inflate and deflate base
including the actual 'C' code that's sitting at UUNET and is inside 
GZIP is all covered under GNU. No question. So just dropping 
inflate.c and deflate.c into Apache is, obviously, never going
to happen. That would be a GNU code dump. 

That leaves ZLIB as the only option for a code drop.

The copies of inflate.c and deflate.c sitting in ZLIB are, apparently,
not GNU so should be OK for Apache even though it's pretty obvious 
it's all the same source code.

The ZLIB rewrite of inflate.c and deflate.c ( Actually... deflate.c
retains a Jean-loup Gailly (c) copyright and inflate.c retains
a Mark Adler (c) copyright in both GZIP (GNU) and ZLIB ) 
was apparently just enough different from the GNU stuff that 
it can be claimed to be a 'new' implementation based on RFC's 
and not pre-exisiting GNU code... even though it's quite obvious 
that's not the way it happened.

When is the implementation of an algorithm that is simply
defined in an RFC similar enough to actual GNU code that it 
is obviously still protected under the GNU license? That's for 
our next contestant on 'IP lawyer for a day' to decide, not me.
No one has brought that challenge up so far so it can be 
assumed that no one really wants to 'go there'. That's good.

The inflate and deflate stuff and the LZ77 contained in it has
already passed the 'sniff' test regarding the deadly IBM and Sperry
Rand patent and although it's been challenged in court a
few times it looks like the LZ77 in inflate/deflate is, in fact, safe 
from actual patent infringement. The whole GNU thing is really
just another legal layer apart from that with its own implications.

If anyone was going to challenge all this it should actually be
the OSF ( Open Source Foundation ) itself or whoever it is that
is supposed to police the GPL. The real issue is whether or
not current ZLIB was really just a code dump of GNU inflate.c
and deflate.c and is still, therefore, technically under the GNU
license. I'm not sure the fact that the authors for both the GNU
stuff and the ZLIB psuedo-rewrite are the same 2 guys even
has much bearing on that.

Matter of fact... just get into the habit of searching the binaries
for some MAJOR applications and you will NOT see the
ZLIB copyrights... you will see the actual GNU inflate.c and
deflate.c copyrights but not one drop of source code for that
application is available to you or anyone, as the GNU license
which is obviously there would seem to require. 

Does anyone seem to care about all this? Nope.

There is an old saying in IP law about 'When is a patent not
a patent?'... Answer: When the holder refuses to enforce it.
If Jean and Mark never had any intentions of ever enforcing any
of this I wish they would pull all copyrights from both GNU and
ZLIB versions of their code and just say so.

There is no way in hell I can see the OSF itself getting into some
kind of vauge legal fight with the ZLIB project over whether or not
ZLIB still contains some GNU code dumps, especially since the
individuals who would be called to testify would be the same 2
guys ( Jean and Mark ) that wrote both the GNU and ZLIB
versions of inflate/deflate so it's pretty safe to say that the ZLIB 
license is valid and means what it says.

>  > ALL of Apache is already open-source and public anyway so why
>  > should there ever be a concern about dumping GNU code 
>  > into Apache itself? You have nothing to lose. Or am I still
>  > totally missing something about ASF license versus GNU?
>  the gpl restricts recipients of the code from using it in a derivative
>  product without having to gpl that derivative (it requires people who
>  use your code to make their code free (and that free quality cascades
>  out from there to twice/thrice/whatever-removed derivatives)).

Of course. This is all I am saying. Mark and Jean had to 'rewrite'
their own deflate.c and inflate.c code ( respectively ) to get around
that very thing for the ZLIB project. Question is... did they do enough?
Is the inflate.c and deflate.c actually ZNGNU ( Zlib's Not Gnu ) or 
still just a code dump from GNU inflate.c and deflate.c. See above
about not wanting to be a contestant on 'IP lawyer for a day'.

>  people see that as the gpl's advantage over licenses like what is
>  used for apache and bsd, some people see it as a disadvantage.

It all depends on your level of religious fervor over the whole open
source thing. If we all had the passion that Chamberlain did when
he couldn't get the source code for some stupid printer program he
wanted at MIT and ended up quitting MIT and starting the OSF over
it ( that's the story he tells himself about OSF origins ) then
everything would be GNU and copyleft all the time.

When is free not really free? When you have to make it not really 
free to protect it against ever becoming not really free.

Pretty strangely shaped logic... but that's the GPL in a nutshell.

>  (you know, in writing what i think is a fairly neutral description
>  of the gpl vs. apache/bsd licenses (a discussion really not worth
>  getting into here, since as rasmus points out, it has been well-hashed
>  elsewhere), i almost let a small typo through that would have
>  changed the whole nature of the paragraph by saying "some people
>  see it is a disadvantage". words are such tricky business.)

Yes, they are... and so are code dumps from bases protected by
one license into code bases protected by another.

Look... forget GNU ( Gnu's Not Unix ( actually it is since 
they went for Linux as the kernel instead of original plans )
and/or ANG ( Apache's Never Gnu )....

Obviously for Apache to have any native deflate compression support
it has to be from scratch with RFC in hand or a ZLIB code dump...

So my only question ( as related to FILTERING ) is still the same
one posted at top of this message...

Now that filtering is in Apache... if a PATCH showed up tomorrow
with a full ZLIB source code dump in it... would that PATCH be
rejected for that reason alone?

That's a YES or NO question.

Rasmus ( or any other VOTING member ) ?

Kevin Kiley
CTO, Remote Communications, Inc. - Online Internet Content Compression Server

View raw message