Slashdot Mirror

The (weak) copyleft license of SDL also meant that games couldn't be recompiled for distribution on game consoles.

Uh, what? It's licensed under the zlib - license ( http://www.gzip.org/zlib/zlib_license.html ), how does that preclude game consoles?

They've already licensed it to NEC for commercial use.

They might have a patent for an actual implementation of the compression algorithm, but those kind of patents are a dime a dozen: http://www.gzip.org/#faq11
For the actual technique and there's copious prior art, for example here:

In this paper we discuss the use of compression techniques to make a more eective use of the
available RAM, thus reducing the need for secondary storage. We show that in many cases memory
pages contain highly compressible data, with a very large amount of zero-valued elements. This
suggests the use of very fast compression algorithms based on static Human codes, rather than
adaptive algorithms such as LZRW1 and similar ones
[...]
Using the proposed compression algorithm, it becomes possible to use a small portion of the
physical memory as a fast, low latency, compressed swap device. This technique can greatly reduce
the latency of page faults, thus improving program's performance

If you want to compress in a non-proprietary format, use *.bzip2 format or *.gzip. There are two windows programs you can get:

For Gzip: http://www.gzip.org/

For BZip2: http://www.bzip.org/

This application below will compress into Bzip2 format is more user friendly, has a GUI and will split files for you:
http://www.7-zip.org/

Either one will give you compression that can be opened on ANY operating system including
Linux, Mac OS, windows, Unix.

here is a general reference page for MANY comrpession tools. Personally, I like the non-commercial ones myself. ;-)

http://datacompression.info/Zip.shtml

Hope this is useful for all..

I'm involved with a project that is looking to develop an online community for technology oriented business customers.
Sell your idea to ebay, they might like you. (and the highest bidder wins!)


  If you could develop an online community to encourage collaboration and information sharing, what features would you want included?
That's easy, BitTorrent.


  How would you go about including features that are widely available in other places (weblogging, message boards, wiki) and generating buy-in from customers.
1) Visit homepages of said OSS
2) Get the sources
3) Right-Click Ctrl-V
4) Get headache integrating code from multiple projects^W4) Discover 'magical' missing libraries^W4) Consider rewriting everything with existing code as reference^W4) Give up^W4) ????
5) Profit!

• zip & unzip being available in all our other "favourite" operating systems (just check the list of platforms on the homepage)
  
• the creation of the very wonderful zlib (http://www.gzip.org/) - now an indispensible part of almost every system everywhere - not least the Intarweb itself - phew !
  

All it's lacked for ages now has been diskette spanning - though, as someone else points out elsewhere in this thread, in these days of USB flash drives and CDRWs there's much less need for that.

So Big Thanks, a Tip o' The Hat and a beverage of your choice to the Info-Zip folks.

The answer in all cases is to work around the problem by not storing the code in the format it supports.

Except that you like, totally blew it. One of the packages you mention is a counterexample. Witness: gzip downloads. Especially the part about "tar.gz (if you already have an old version of gzip)"

In other words, you seed the torrent from the ftp server (or similar) and everyone is happy.

Zip and gzip use the same compression.

According to the ZIP file format specification, ZIP can use a dynamic LZW algorithm.

The whole reason gzip exists is because the standard UNIX compress uses LZW - which, until recently, was protected by a patent (that was the problem with GIFs).

Instead of using LZW, gzip uses the unprotected LZ algorithm, which doesn't contain the improvements that Welch (the 'W' in LZW) made.

So not only do they not use the same algorithm, but that's the whole point of gzip in the first place!

Sadly, libraries aren't similarly short of security problems. This is what happens when a library that is commonly statically linked is found to have a security vulnerability.

Sadly, libraries aren't similarly short of security problems. This is what happens when a library that is commonly statically linked is found to have a security vulnerability.

--

Zlib is publically specified, the IETF has an RFC on it, and it has an open source reference implementation. You don't need this (relatively obsolete) algorithm for your research when better, more widely available algorithms exist.

GIF is interesting only for backward compatiblity, not for the algorithms that go into it (which were state-of-the-art at the time, mind you).

Zlib is publically specified, the IETF has an RFC on it, and it has an open source reference implementation. You don't need this (relatively obsolete) algorithm for your research when better, more widely available algorithms exist.

GIF is interesting only for backward compatiblity, not for the algorithms that go into it (which were state-of-the-art at the time, mind you).

"Just a question, though, are some of the changelogs ESR mentions available for easy download? The kernel changelogs are easy to find, but what about the changelogs for emacs, Gnome, gzip/gunzip, and all of the other GNU software?"

Does someone know better web-CVS repositories than I can find in a 3-minute google search?

[*] EMACS ChangeLog on the web

[*] GNOME ChangeLog on the web

[*] GZIP: Download it

[*] Other GNU software? See Savannah

Bonus points for anyone who can link to the Internet Explorer changelog...

You remember incorrectly. That looks like zlib (which gzip is based on). zlib's license is very flexible:

http://www.gzip.org/zlib/zlib_license.html

/* zlib.h -- interface of the 'zlib' general purpose compression library
version 1.2.1, November 17th, 2003

Copyright (C) 1995-2003 Jean-loup Gailly and Mark Adler

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.

Jean-loup Gailly jloup@gzip.org
Mark Adler madler@alumni.caltech.edu

*/

It'd be interesting to see exactly what the scope of the claims are in the patent, since this is a potential threat to encrypted gzip as well.

How?

Zip and gzip use the same 'deflate' compression alogrithm. In fact, zlib was based on the Info-Zip code, a free software/open source alternative to pkzip, and the GZip homepage specifically credits Info-Zip as where "all this started", and mentions that the decompression code was based on the code of the major author of Info-Zip. And WinZip's .zip support is another direct derivative of this Info-Zip code.

So, gzip, zlib, Info-Zip, and WinZip all share common code from common authors implementing the same algorithm. As a result, it would take a very narrowly-tailored patent to allow gzip-and-encryption without allowing Winzip's zip-and-encryption.

It'd be interesting to see exactly what the scope of the claims are in the patent, since this is a potential threat to encrypted gzip as well.

How?

Zip and gzip use the same 'deflate' compression alogrithm. In fact, zlib was based on the Info-Zip code, a free software/open source alternative to pkzip, and the GZip homepage specifically credits Info-Zip as where "all this started", and mentions that the decompression code was based on the code of the major author of Info-Zip. And WinZip's .zip support is another direct derivative of this Info-Zip code.

So, gzip, zlib, Info-Zip, and WinZip all share common code from common authors implementing the same algorithm. As a result, it would take a very narrowly-tailored patent to allow gzip-and-encryption without allowing Winzip's zip-and-encryption.

zlib is completely free (and hence is used in a LOT of comercial software)

There's no reason why linking against zlib would cause a product to become GPL'd, seeing as they use their own license anyway.

Linking != derivative product, so the GPL wouldn't get you there, TRY AGAIN ASSWIPE.

And I do not believe that it decompresses everything just to get that one file.

My belief in that particular idea is not as strong as yours is. gzip uses the "deflate" algorithm, which by nature compresses in a stream. Briefly, it continually examines the last 32kB of data it sent to see if the current string of bytes has occurred before (and recently). If so, instead of outputing the literal string, it outputs an {offset,length} pair. The offset indicates where the previous instance of the redundant data exists within the last 32kB, and the length indicates how long that string is. So, you can easily see that the correct uncompressed data is a function of the current data and the last 32kB of data. Since the last 32kB depends on the 32kB before that, it's proved by induction that a given byte depends on essentially all the data before it in the stream.

The simplicity of the above argument is complicated a little bit by the fact that gzip in fact deals with data in blocks. At block boundaries, huffman tables are regenerated, but are the 32kB windows reset? I don't know. Depending on various details like that, it may or not actually be mathematically possible to reconstruct part of a deflated file without decompressing all the prior data. Naturally, whether various actual software (like gzip and AVFS) does this is another question. Even if you can do that, there is another big problem for random access, which is that as far as I know, tar files don't have a central table of contents and instead have a header before each file's data. So, it isn't, as far as I know, possible to build a correct tar program that can extract without reading the whole file up to that point!

Having said all that, a big mitigating factor in all this is that with the deflate algorithm, decompression is actually quite fast. It's an order of magnitude faster than compression. Basically, all there is to do is read the stream, copying literal data to the output; if you see an {offset,length} pair pointing back into the 32kB buffer, you just copy bytes from that buffer instead. Actually, it's not quite that simple, because there are huffman trees involved as well, but there are some clever tricks available to make huffman really fast.

For more info on deflate as used in gzip, see here.

They seem to have their own license. I don't see any legal objection to use the lib.

Good idea. In the meantime, view this PNG with any of these apps. I promise it won't be a security problem - as long as you've already recompiled *all* of them

Bugs.

If there is a bug or a security problem in a DLL you only have to replace that DLL instead of all statically linked programs.

Remember the problems with zlib a year ago? Would you like to replace 500 applications or one library?

Bugs.

If there is a bug or a security problem in a DLL you only have to replace that DLL instead of all statically linked programs.

Remember the problems with zlib a year ago? Would you like to replace 500 applications or one library?

Jean-Loup Gailly, the author of gzip, tried to be both. He writes:

I have probably spent more time studying data compression patents than actually implementing data compression algorithms. I maintain a list of several hundred patents on lossless data compression algorithms, and I made sure that gzip isn't covered by any of them. In particular, the --fast option of gzip is not as fast it could, precisely to avoid a patented technique.

(from the gzip faq)

He also notes that the US patent office not only accepts "obvious" patents, but also obviously wrong patents -- see his analysis of two complete non-sense patents on data compression.

From the advisory

There have been no reports of any exploitations of this problem, but the vulnerability exists nevertheless.

I know most people here know this, but for some reason this bug has gotten an almost hysterical spin in the media. This is an example of the community responding to a potential risk, before any damage is done.

All these articles that rave about millions of systems being vulnerable seem to forget the fact that nobody has been affected.

Here is the license for zlib

The summary is:

1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.

zlib has it's own licence, which doesn't prohibit what MS have done. At the moment, that is... :)

Woops:
http://www.gzip.org/zlib

and the advisory on their site.

(BTW: The 'c' in your link was unnecessary and www.zlib.org resolved to www.gzip.org/zlib)

Woops:
http://www.gzip.org/zlib

and the advisory on their site.

(BTW: The 'c' in your link was unnecessary and www.zlib.org resolved to www.gzip.org/zlib)

FYI: http://www.gzip.org/zlib/advisory-2002-03-11.txt

See the gzip advisory here. And get the 1.1.4 binaries here.

See the gzip advisory here. And get the 1.1.4 binaries here.

Here is some more linkage to the navagationally impared.

Hell, a converted VCR using VHS as a backup medium can store like 100GB (saw one somewhere, I forget the link.)

Assuming 9 Mbps of raw data (half the data rate of HDTV, because garden-variety VHS is nowhere near broadcast-quality), and assuming some heavy-duty error correction reducing effective data rate to 6 Mbps, VHS's SP mode records for 7200 seconds, giving 5 gigabytes on a tape at a bare minimum. (For comparison, a single-layer DVD holds about 4 1/2 GB.) If we go to EP mode, increase the bandwidth to S-VHS levels, and apply 3:1 text compression (common with deflation of large Latin-alphabet texts, especially containing quoted material), we may be able to store even more data per tape.

How do I read the .gz file? I tried using Winzip 8.0, but got the message

Cannot open file: it does not appear to be a valid archive.

Then I downloaded win-gz and ran it. Win-gz claimed that the file (fasc2a.ps.gz) was not gzipped and refused to unzip it.

Thinking that the file might have somehow become corrupted on download, I downloaded the file a second time. The results were the same.

Does another Win98 user have constructive suggestions for gunzipping?

Virtually every license I've ever read has stated "Subject to change without notice".

Including the GNU General Public License, but not including the BSD license, the X license, or the zlib license.

What bothers me most about the Open Directory license is that the requirement to keep checking back home makes the license to use a specific version of the data non-perpetual and makes the license not a free documentation license.

Oh, you can zip it? Great, let me run out and link the zip libraries into my application. What? There's licensing issues? Well, what do I do know?

ZIP gzip and bzip are all available under very liberal free licenses (no copyleft restriction, OK to use in both closed and open source software).

gzip and bzip2 aren't difficult to use for intermediate (1 to 2 years of experience) C programmers either. I don't know about ZIP because I've never used it, but it's probably not much harder.