Slashdot Mirror

Release it under AGPL. If anyone wants a more permissive license (that is, if they don't want to release their own source code), then charge them for that.

LZO does similar things, but also has some enhancements over the open source version. The open source version is still very good.

A lot of these questions are answered on the philosophy section of his page.

Basically, RMS derives everything from the four freedoms: the freedom (0) to run the program, (1) to study and change the program in source code form, (2) to redistribute exact copies, and (3) to distribute modified versions. If you accept those freedoms, it makes sense to avoid the BSD licenses, because they allow middle-men to deprive end-users of some of these rights. Of course, not everyone thinks those freedoms are important.

Secondly, monetizing is actually easier under the GPL. If that is your goal, you can follow the example of this guy, or QT, or MySQL, and dual-license your code. Those who are willing to preserve the freedoms can have it for free. Those who aren't, can pay. I can't think of any BSD products that have been able to make money like this (maybe there are some).

This one is really funny. Of course, given it's Stallman, he'll probably go on a crusade against the US government and want Iran to get the source code. But the source code of the library is already here. So he can demand the full thing, and both the CIA and Mossad can deny that they distributed it in the first place, leaving the burden of proof on RMS. Maybe he'll then find a way to introduce an anti-CIA clause into GPL4.

AARGH should have used preview. LZO Professional.

Hard Drive DVD ROM Case

Other software:

0. Install DSL to hard disk, reboot, and configure

1. Upgrade (Apps->Tools) to gnu utils

2. Install gcc

3. Install zile (MyDSL) for editing convenience

4. Other software (for building natively and installation):

http://www.kernel.org/pub/linux/kernel/v2.7/linux-2.6.23.tar.bz2

ftp://alpha.gnu.org/gnu/grub/grub-1.95.tar.gz

ftp://ftp.gnu.org/gnu/bison/bison-2.4.tar.bz2

ftp://ftp.gnu.org/gnu/m4/m4-1.4.tar.bz2

http://www.oberhumer.com/opensource/lzo/download/lzo-2.02.tar.gz

http://www.zlib.net/zlib-1.2.3.tar.gz

http://www/perl.com/CPAN/src/perl-5.8.8.tar.bz2

http://ftp.gnu.org/gnu/autoconf/autoconf-2.61.tar.bz2

http://ftp.gnu.org/gnu/libtool/libtool-1.5.24.tar.gz

http://xorg.freedesktop.org/archive/X11R3/src/everything/index.html

`grep bz2 index.html | sed s/^.*\.bz2\"\>// | sed s/\<.*// | sed s,^,http://xorg.freedesktop.org/archive/X11R7.3/src/everything/,`

http://gitweb.freedesktop.org?p=xorg/util/modular.git;a=blob_plain;f=build-from-tarballs.sh

http://downloads.sourceforge.net/expat/expat-2.0.1.tar.gz

http://downloads.sourceforge.net/libpng/libpng-1.2.24.tar.gz

http://www.fontconfig.org/release/fontconfig-2.5.0.tar.gz

http://download.savannah.gnu.org/releases/freetype/freetype-2.3.5.tar.bz2

http://xcb.freedesktop.org/dist/libxcb-1.1.tar.bz2

ftp://xmlsort.org/libxslt/libxslt-1.1.22.tar.gz

ftp://xmlsort.org/libxslt/libxml2-2.6.30.tar.gz

http://xcb.freedesktop.org/dist/xcb-proto-1.1.tar.bz2

http://www.paldo.org/paldo/sources/pthread-stubs/libpthread-stubs-0.1.tar.bz2

http://www.paldo.org/paldo/sources/xau/libXau-1.0.3.tar.bz2

http://www.paldo.org/paldo/sources/xproto/xproto-7.0.11.tar.bz2

You should've given PAQ a try too. From what I understand PAQ compression uses adaptive switching between multiple compression algorithms on the fly based on which produces the best result for a current block. Be warned that it is pretty slow and memory intensive.

Another one to try is UCL . This is a compression engine behind UPX, executable file compressor. It has a remarkable property of having super-fast decompression.

If anything supported LZO, that might help with the CPU usage.

What about hiring the guys who did lzo and have them write a plugin for rsr4 tuned for your video data?

Please, that will stop you complaining and give the world a great compression plugin that will "help the cause". For publicity, put up a few hundred/thousand $$ for a bounty, it has to be worth the cost of a few harddisks, yes?

Then when it comes together please submit it here as a story. TIA.

If you like card games, try this or this.

PySol; Free software wins again.

Since everyone knows that solitaire is one of the measures of a real computer, you need a better solitaire to show how much better your computer is.

Go with PySol.

Free and can keep you busy for hours and hours and hours and...

and what else do most (90% of corp users) need?

Me! Me! I know. It's solitaire, isn't it?

You're forgetting that it's the LZW compression algorithm that's patented, not the GIF image format or the images per-say.

And, when you look at it, LZW is actually quite a nice algorithm to use. It offers incredibly high speed compression and decompression, but performs better than run-length encoding. In case you hadn't noticed, many computer games use decompressed-on-the-fly graphics in their games. While it's no use for video and audio compression compared to lossy algorithims, patent-free LZW would be useful to game developers as it could improve on their often abysmal realtime compression/decompression. Many game houses are still using RLE compression. Personally, I'd recommend LZO rather than LZW, but that's just me.

I guess you haven't tried PySol then...

True. And who in their right mind would change from PySol to Solitaire?

They can use different compression schemes to trade off space vs the size of backups. They already offer gzip and bzip2, I think, so lzop should be easily added - that is very quickly compressible and decompresses obscenely fast, several megabytes per second on a P133.

Solitaire, written in Python. Better than any other solitaire games I've seen (including some commercial). There are something like 200 different solitaire games built in.

It can be found here.

There isn't a windows build on the page, it's python, dude.

Knowing how much Windows users like their Solitaire, I recommend PySol. Written in Python and Tk, it has over 200 unique soliatire games. My mother-in-law is addicted to Spider solitaire and absolutely loves PySol.

Unfortunately, the site doesn't have an up-to-date py2exe package of it (for non-Windows Python programmers, py2exe allows you to make a Windows EXE of a Python program, including the interpreter). You'll have to Google it to find it.

Any Windows machine would be useless without a copy of solitaire, although you will need Python.

You could try showing her PySol. Just about every known solitaire variant is in there, coupled with beautiful cardsets (some of them scanned versions of antique designs).

Just play KMines. And PySol is the best solitare game EVER (and cross-platform to boot!)

-Peter

The sheer size of the source code may prohibit me from distributing the software electronically at all.

So don't distribute your work electronically. Distribute source and binaries together simultaneously by burning both onto CD-Rs. Someone else might volunteer to redistribute the work electronically for you. So much of this issue centers on your erroneous belief that the GNU GPL requires you to distribute electronically.

I am not [the only copyright holder to this work]. Read what I had written...

I did read it, quite carefully. I figured at least one of the following things might have occured to you:

• The last paragraph of section 3 of the GNU GPL says that "offering equivalent access to copy the source code from the same place" will meet your requirement to distribute complete source code to your work. That place can be a CD-R.
• If you really want to contact Oberhumer (which no longer seems necessary), you could try e-mailing plaintext because Oberhumer's "...mailfilter may throw away messages from unknown senders unless you do use this key." (emphasis mine). You may get lucky.
• You could accede to Oberhumer's wishes and try GPG. Contrary to your claim "I cannot contact Mr. Oberhumer because he does not accept mail not encrypted with PGP", there is no requirement to use PGP. Oberhumer supplies information for contact with GPG on the page you pointed me to. GPG is a a Free Software PGP replacement.
• You could see if Oberhumer supplies a postal address with your copy of the software then try sending a letter. Low-tech, yes, but it could work to make initial contact.

This is a non-problem if and only if reversibly concatenating an executable with asset files counts as either "mere aggregation" and/or "just data" under the GPL.

I very much doubt that distributing a single file would count the way you want it to be counted. That's a question for the FSF, albeit a rather academic one considering that this whole issue is a non-problem if you drop the phony electronic distribution requirement (that never really existed) and distribute your program via inexpensive CD-Rs (which have approximately 600MB more capacity than you said you need to distribute your program).

The sheer size of the source code may prohibit me from distributing the software electronically at all.

So don't distribute your work electronically. Distribute source and binaries together simultaneously by burning both onto CD-Rs. Someone else might volunteer to redistribute the work electronically for you. So much of this issue centers on your erroneous belief that the GNU GPL requires you to distribute electronically.

I am not [the only copyright holder to this work]. Read what I had written...

I did read it, quite carefully. I figured at least one of the following things might have occured to you:

• The last paragraph of section 3 of the GNU GPL says that "offering equivalent access to copy the source code from the same place" will meet your requirement to distribute complete source code to your work. That place can be a CD-R.
• If you really want to contact Oberhumer (which no longer seems necessary), you could try e-mailing plaintext because Oberhumer's "...mailfilter may throw away messages from unknown senders unless you do use this key." (emphasis mine). You may get lucky.
• You could accede to Oberhumer's wishes and try GPG. Contrary to your claim "I cannot contact Mr. Oberhumer because he does not accept mail not encrypted with PGP", there is no requirement to use PGP. Oberhumer supplies information for contact with GPG on the page you pointed me to. GPG is a a Free Software PGP replacement.
• You could see if Oberhumer supplies a postal address with your copy of the software then try sending a letter. Low-tech, yes, but it could work to make initial contact.

This is a non-problem if and only if reversibly concatenating an executable with asset files counts as either "mere aggregation" and/or "just data" under the GPL.

I very much doubt that distributing a single file would count the way you want it to be counted. That's a question for the FSF, albeit a rather academic one considering that this whole issue is a non-problem if you drop the phony electronic distribution requirement (that never really existed) and distribute your program via inexpensive CD-Rs (which have approximately 600MB more capacity than you said you need to distribute your program).

I'm not aware of the part of the GNU GPL that requires "electronic" distribution.

But the GPL FAQ states that if the binaries are distributed electronically, the source code must also be distributed electronically. The sheer size of the source code may prohibit me from distributing the software electronically at all.

Also, if the work is not a derivative of anything GPL'd, the GNU GPL would not apply to you (assuming you are the copyright holder on this work)

I am not. Read what I had written: "I can't re-license the software because it uses the LZO compression library, which is licensed under the GNU GPL." The LZO library was written by Markus F.X.J. Oberhumer, who does not have a plain e-mail address.

This is a non-problem if and only if reversibly concatenating an executable with asset files counts as either "mere aggregation" and/or "just data" under the GPL.

I'm not aware of the part of the GNU GPL that requires "electronic" distribution.

But the GPL FAQ states that if the binaries are distributed electronically, the source code must also be distributed electronically. The sheer size of the source code may prohibit me from distributing the software electronically at all.

Also, if the work is not a derivative of anything GPL'd, the GNU GPL would not apply to you (assuming you are the copyright holder on this work)

I am not. Read what I had written: "I can't re-license the software because it uses the LZO compression library, which is licensed under the GNU GPL." The LZO library was written by Markus F.X.J. Oberhumer, who does not have a plain e-mail address.

This is a non-problem if and only if reversibly concatenating an executable with asset files counts as either "mere aggregation" and/or "just data" under the GPL.

Stick the video and sound assets into a seperate file

The target system uses interchangeable ROM cartridges and has only one ROM connector. I don't want the user to have to swap cartridges several times during game play, and I don't want to have to provide two expensive ROM cartridges in each package.

(like iD did with their .pak files with quake)

I'm already storing asset files in .gbfs archives. (The .gbfs format is an archive format I designed, somewhat similar to .tar, .pak, .zip, .jar, .dat used by other programs.) However, because a program on the target system can access only one file (the ROM), I have to concatenate the asset files to the end of the executable. Does concatenating several files count as "linking" if I also provide a tool to extract the individual .exe and .gbfs files?

If you want to (and I presume you do), provide compressed versions of the assets (eg make the asset library a simple zip file).

I already do that, but the assets are already 20 MB zipped before counting the lossy compression used to pack the assets into the pak file. Lossy compression of source code is not permitted by the GPL, as a lossy compressed audio or image file is no longer "the preferred form for making modifications to the work."

If you are concerned about that, just write an exception into your copy of the GPL.

I am not authorized to do that. The program includes a library (M.F.X.J. Oberhumer's LZO) under the GNU GPL, and I am not permitted to link it against anything not under the GPL. I cannot contact Mr. Oberhumer because he does not accept mail not encrypted with PGP, and I cannot use PGP because I don't know anybody who would sign my keys.

If concatenating several files in a reversible manner does not count as "linking," then I don't have a problem.

Stick the video and sound assets into a seperate file

The target system uses interchangeable ROM cartridges and has only one ROM connector. I don't want the user to have to swap cartridges several times during game play, and I don't want to have to provide two expensive ROM cartridges in each package.

(like iD did with their .pak files with quake)

I'm already storing asset files in .gbfs archives. (The .gbfs format is an archive format I designed, somewhat similar to .tar, .pak, .zip, .jar, .dat used by other programs.) However, because a program on the target system can access only one file (the ROM), I have to concatenate the asset files to the end of the executable. Does concatenating several files count as "linking" if I also provide a tool to extract the individual .exe and .gbfs files?

If you want to (and I presume you do), provide compressed versions of the assets (eg make the asset library a simple zip file).

I already do that, but the assets are already 20 MB zipped before counting the lossy compression used to pack the assets into the pak file. Lossy compression of source code is not permitted by the GPL, as a lossy compressed audio or image file is no longer "the preferred form for making modifications to the work."

If you are concerned about that, just write an exception into your copy of the GPL.

I am not authorized to do that. The program includes a library (M.F.X.J. Oberhumer's LZO) under the GNU GPL, and I am not permitted to link it against anything not under the GPL. I cannot contact Mr. Oberhumer because he does not accept mail not encrypted with PGP, and I cannot use PGP because I don't know anybody who would sign my keys.

If concatenating several files in a reversible manner does not count as "linking," then I don't have a problem.

Here is my list:

1. Freeciv - the open source flavor of the epic strategy game. I purchased Civ3 when it came out, but TBHWY, it doesn't provide a compelling reason to reboot into Win-doze, and I still opt to play freeciv. Freeciv is much more customizable and plays quicker, allows multitasking, and was set up specifically for mulitplayer (even if I haven't ventured online to play much MP). I hope the freeciv team is entertaining notions of a Civ3 ruleset, or some variation ...
2. Kohan: Immortal Sovereigns - innovative, evolutionary RTS (real time strategy) game - instead of the "Age of Buildings", clickety-click nature of other RTS games in the genre, Kohan is the wargamer's RTS, with company-based battle, zone of supply, and zone of population constructs, and as opposed to the micromanagement of resource collection, resources are earned/spent on a per minute basis, and constructed companies have a maintenance cost. Plus you have magic wielding units that gain XP and cast some cool spells. Multiplayer with Windows gamers is possible (though with large maps you won't be able to view films after)
3. Pysol - the vastly superior Linux alternative to solitaire
4. Sid Meier Alpha Centauri Planetary Pack - great game, but I have a big beef with the multiplayer support - you can only MP against other Linux users, unlike Kohan. So it gets downgraded to the bottom of the list for that reason.

In no particular order... Chromium, Tux Racer, GLJewel, KShisen, PySol.