My toy scripts - now available on SourceForge!

I've decided to make good use of SourceForge's per-developer project space - a really nice feature, by the way - and upload all the toy scripts I've made over the years to https://sourceforge.net/u/openblocks/code/. All the scripts are licensed under the 3-clause BSD license, so feel free to give them a look and make your own modifications. :)

Keep in mind that since I use Linux as my main operating system, some of the toys that are shell scripts won't work on Windows, unfortunately.

The hashcash algorithm

Yeah, it has a weird name, but it's one of the most interesting (and effective) anti-spam algorithms out there: Hashcash. How does it defeat spam without the end-user even knowing a spam check is taking place? Read on.

No, this isn't a Bayesian filter-like algorithm; this is something completely different. Hashcash involves inserting a piece of Javascript code into your site's comment form that sends a server-generated key as part of the comment form's data. If the sent key doesn't match the one the server sent as part of the comment form, the comment is marked as spam and not posted. Amazingly simple. And this all happens behind the scenes, without your users even knowing a spam check is going on!

Now, this algorithm works solely on the premise that spambots are incapable of running Javascript, so if spammers come up with a spambot that is capable of running Javascript, Hashcash would be in hot water. But again, no such spambot currently exists, so Hashcash is currently a viable spam-blocking algorithm.

I think Hashcash is such I good idea, I'm going to give it a test run on this site using the WP Hashcash plugin for WordPress. Hopefully I won't have to manually deal with spam for a long time to come. :)

Do we need a new FOSS license?

Come on, admit it: You've been involved in at least one (probably 3 or more) licensing "discussions" with your fellow FOSS peers. :P Like you probably already know (and like I covered in one of my previous posts), these "discussions" revolve mainly around whether or not the GPL is, in fact, a truly free license. I'm not going to discuss that here (for brevity), but what I will discuss is whether an "compromise" license that sits right between the GPL and a permissive license in terms of restrictions is possible.

First, we need to know what our new license can and cannot do. According to the Open Source Definition (which you can read for yourself here), here are some things our new license couldn't do:

• Prevent commercial re-distribution. Commercial re-distribution is very different from proprietary re-distribution, by the way


• Prevent (possibly derivative) products issued under the same license as ours


• Restrict other software distributed on the same medium as ours

Okay, so now we now what we can't do, let's figure out what we can do.

• The biggest problem most people have with the GPL is that it prevents other, non-GPL, FOSS software from using GPL'ed products (because the licenses are incompatible). We need to figure out a way to solve this issue in order to come up with a true "compromise" license.


• The counter-argument against permissive licenses is that they allow proprietary derivatives of your project. Whether or not this is an issue is completely up to you, but for the purposes of this post, I'll assume the answer is "yes."


• The Open Source Definition does allow open-source licenses to "pick and choose" what derivative projects can be licensed under; the most notable open-source license that does this is the GPL - you can derive from a GPL product and use the AGPL for your code if you so choose

What if we could allow anyone to derive from a product licensed under our hypothetical license as long as they used our new license, or an OSI-approved license? While this has the obvious disadvantage of preventing a BSD-licensed project which uses our hypothetical project from being used in a proprietary product, it's a pretty big step towards an actual "compromise" license.

That's as good a compromise as I can think of for now. Hopefully I can think of a better one in the future. :)

Setting up MinGW32 on Ubuntu

Finally, a non-controversial topic :)

Having a cross-compiler that can compile Windows executables on a Linux machine can be an extremely useful tool to have, since it prevents you from having to install WINE or a virtual machine just to generate Windows executables for your software project. I find myself often in need of such a tool, and since there doesn't seem to be any up-to-date tutorial on how to set up a MinGW32 cross-compiler, I decided to write one. :)

Okay, so here we go: First, install the gcc-mingw32 package with the following command:

sudo apt-get install gcc-mingw32

And we're basically finished. To use your newly-installed cross-compiler, use the following command:

i586-mingw32msvc-gcc

As a final finishing touch, I add a soft link that allows me to access my new cross-compiler with shorter name, like so:

ln -s $(which i586-mingw32msvc-gcc) gcc-mingw32

If you execute that command in your $HOME/bin directory (assuming, of course, that that directory is on your $PATH), you can access your cross-compiler via gcc-mingw32 instead of the longer i586-mingw32msvc-gcc.

Let's test our cross-compiler on a simple piece of software: Lua 5.1. I'll assume you've already unpacked Lua into some convenient directory, and have opened a terminal there. I'll also assume you made the soft link I talked about earlier, but that's no big deal - if you didn't, just replace gcc-mingw32 with i586-mingw32msvc-gcc.

Lua makes things easy on us by having 99% of the compiler options already set up for us; we just have to tell it where to find our cross-compiler - otherwise, it will find the non-cross-compiling installation of GCC:

make mingw CC=gcc-mingw32

That wasn't too hard either. :) Here's what that command outputs on my system:

cd src && make mingw
make[1]: Entering directory `/home/(my username)/Downloads/lua-5.1/src'
make "LUA_A=lua51.dll" "LUA_T=lua.exe" \
"AR=gcc-mingw32 -shared -o" "RANLIB=strip --strip-unneeded" \
"MYCFLAGS=-DLUA_BUILD_AS_DLL" "MYLIBS=" "MYLDFLAGS=-s" lua.exe
make[2]: Entering directory `/home/(my username)/Downloads/lua-5.1/src'
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lua.o lua.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lapi.o lapi.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lcode.o lcode.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ldebug.o ldebug.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ldo.o ldo.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ldump.o ldump.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lfunc.o lfunc.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lgc.o lgc.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o llex.o llex.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lmem.o lmem.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lobject.o lobject.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lopcodes.o lopcodes.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lparser.o lparser.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lstate.o lstate.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lstring.o lstring.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ltable.o ltable.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ltm.o ltm.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lundump.o lundump.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lvm.o lvm.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lzio.o lzio.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lauxlib.o lauxlib.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lbaselib.o lbaselib.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ldblib.o ldblib.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o liolib.o liolib.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lmathlib.o lmathlib.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o loslib.o loslib.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ltablib.o ltablib.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lstrlib.o lstrlib.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o loadlib.o loadlib.c
gcc-mingw32 -O2 -Wall -DLUA_BUILD_AS_DLL -c -o linit.o linit.c
gcc-mingw32 -shared -o lua51.dll lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o
strip --strip-unneeded lua51.dll
gcc-mingw32 -o lua.exe -s lua.o lua51.dll -lm
make[2]: Leaving directory `/home/(my username/Downloads/lua-5.1/src'
make[1]: Leaving directory `/home/(my username/Downloads/lua-5.1/src'

Hey, looked like it worked. Let's try running our new executable with WINE:

wine src/lua.exe
fixme:advapi:RegisterTraceGuidsW (0x100778a, 0x100a060, {485e7de8-0a80-11d8-ad15-505054503030}, 1, 0x33fe00, (null), (null), 0x100a068,): stub
fixme:advapi:RegisterTraceGuidsW (0x100778a, 0x100a080, {485e7de9-0a80-11d8-ad15-505054503030}, 1, 0x33fe00, (null), (null), 0x100a088,): stub
fixme:advapi:RegisterTraceGuidsW (0x100778a, 0x100a0a0, {485e7dea-0a80-11d8-ad15-505054503030}, 1, 0x33fe00, (null), (null), 0x100a0a8,): stub
fixme:advapi:RegisterTraceGuidsW (0x100778a, 0x100a0c0, {485e7deb-0a80-11d8-ad15-505054503030}, 1, 0x33fe00, (null), (null), 0x100a0c8,): stub
fixme:advapi:RegisterTraceGuidsW (0x100778a, 0x100a0e0, {485e7dec-0a80-11d8-ad15-505054503030}, 1, 0x33fe00, (null), (null), 0x100a0e8,): stub
fixme:advapi:RegisterTraceGuidsW (0x100778a, 0x100a100, {485e7ded-0a80-11d8-ad15-505054503030}, 1, 0x33fe00, (null), (null), 0x100a108,): stub
fixme:win:RegisterDeviceNotificationW (hwnd=0x14fae8, filter=0x65e93c,flags=0x00000001) returns a fake device notification handle!
Lua 5.1 Copyright (C) 1994-2006 Lua.org, PUC-Rio
>


And there you have it: We went step-by-step through the process of installing MinGW32, adding a convenience soft link, and compiling a simple piece of software - Lua.

Happy cross-compiling!

On piracy

Yes, another controversial topic: Piracy. It's pretty prevalent today - you probably know at least 5 people that have pirated software, and you might have pirated some software yourself; I myself have pirated software in the past, albeit before I knew of the legal and moral issues surrounding it.

So what makes piracy so popular? The most obvious reason is you get a piece of software you'd normally have to pay for for free, and everyone loves that. Except the people who wrote the software, and that's what this short essay is going to be about.

First let's get our terms straight: What is piracy? It's basically the act of downloading a copy of a piece of software that was not made by the software's author - in other words, copyright infringement. Now, is there anything legally wrong with piracy? Quite a bit. How about morally? Er, that's not so clear in some cases.

When you pirate a piece of software that's still being distributed in some legal form, you're basically saying: "Mr. Software Author, I like the software you wrote, but I don't like xxx about it (price, DRM, etc...). Shame on you, so I'm going to take your software and use it for free." I can't really see any way to justify this line of thinking, at least from Mr. Software Author's point of view.

You might say you're not hurting Mr. Software Author by pirating his software, and you might be right, depending upon how rich he is. But that doesn't change the fact that you took something that wasn't yours. You're not entitled to Mr. Software Author's product, and if you don't want to use it the way he wants you to use it, don't use it at all.

If Mr. Software Author's product is tainted with DRM, and that's the reason you're giving for pirating his product, consider this: Will your circumvention of the DRM Mr. Software Author set in place cause him to remove the already present DRM? No - on the contrary, he'll probably add more! Instead of pirating a DRM'ed product (which is still taking something that isn't yours), support a non-DRM'ed one instead. Lack of customers will change Mr. Software Author's opinion on DRM more than anything else.

Now, what do you do in the (very common) case of software whose parent company is either defunct or no longer distributes the software in question? This is both a legal and moral gray area. I mean, technically you're still guilty of copyright infringement, but the copyright owner no longer exists, so it's a legal gray area. It's a morally gray area because while you're still taking something that really isn't yours, you're offered no alternative method to download the software in question.

What about if the parent company exists, but they no longer distribute the software in question? You often see this sort of thing happening with arcade ROMs. My personal take on this case - IANAL - is it's fine (morally so - this is a legal gray area) to pirate arcade ROMs, but only if the parent company offers no way to get the ROMs via other means. For example, Capcom offers Street Fighter Alpha 2 on the Wii Virtual Console platform, but not Street Fighter Alpha 3. So pirating Alpha 3 would be fine by me, but I wouldn't pirate Alpha 2.

I hope this essay on piracy has been an interesting read for you. I also hope it makes you think about the moral and legal implications of piracy a bit more - hey, you might even solve this whole legal mess. :)

On permissive and copyleft licenses

As you probably know, FOSS licenses are a touchy subject - I've seen some people who won't use or contribute to a project if the project uses a license they do not like. In my humble opinion, licenses aren't a major issue (except for projects you lead) and I'll attempt to explain why below.

Let's start with the (A)GPL. This is probably the most loved/hated license of all time, for 2 major reasons:

• The GPL is a strong copyleft license: Any derivative product must also be covered under the GPL.


• Even if you leave the GPL code alone and build your own code on top of it - even with dynamic linking - your code must also be covered under the GPL.

For those of us who primarily develop GPL'ed code, this isn't really an issue (in such a case, you'd license your derivative product under the GPL anyway), but using the GPL prevents your code from being used in a non-GPL FOSS project, which may or may not be what you intended.

This is the biggest argument against the GPL in the license debate by far, and for obvious reasons. However, unlike permissive licenses, GPL'ed code cannot be used in a proprietary product, no matter how many times it is derived from, which is the point brought up by those who do like/use the GPL.

So if you don't want your code to be used in a proprietary product, or you only want your code to be used in other Free software projects, the GPL is the way to go. Otherwise, you might want to read on.

Now, let's take a look at permissive licenses. There are quite a few of these, most notably:

• 3-clause BSD


• 2-clause BSD


• MIT/X


• Apache

All of them differ in subtle ways (the Apache license includes a patent indemnification clause, for example), but they all have the same basic premise: Use, modify and redistribute this code however you like, but:

1. Don't change the license on the original code


2. Distribute a copy of this code's license along with your product


3. State unambiguously (none of the licenses specify where) that your product uses my code

Quite a bit more permissive (hence the name) than the GPL, don't you agree? These sort of licenses are used primarily by those who aren't concerned about possibly proprietary derivative products. As far as I've seen, the permissive licenses receive the most flak for not ensuring that derivative products are FOSS as well, something the GPL ensures. In my opinion, whether or not this is a problem is something that has to be decided by the author of the code in question: Am I fine with people making a proprietary (and most likely commercial) derivative of my project? The way I normally go about deciding between using the (A)GPL or a permissive license in a new project - yes, I use both :) - boils down to four questions:

1. Is the code I am going to license constitute a product that others could make a proprietary (and most likely commercial), standalone derivative of by copying verbatim?


2. How much time have I spent on the code I'm licensing?


3. Am I trying to use this code to advance the cause of FOSS, i.e, I'm making a FOSS application in a problem domain where no other FOSS application currently exists?


4. Are there already currently better FOSS applications in the problem domain for my new project?

Questions 1 and 3 are probably the most significant: If the answer to either question is "yes", unless the answer to Question 4 is "no", the code for the new project will almost certainly be under the GPL - if my project is the only FOSS application in its problem domain, I want to make sure that everything that touches it stays FOSS, for obvious reasons. Question 2 and 4 are somewhat less important, but still bear some weight: If the answer to Question 4 is "yes", I'm probably going to use a permissive license - there wouldn't be much point to someone ripping off my project with there being better FOSS applications in its problem domain anyway.

Besides, as long as I'm the sole copyright holder (or have all contributors sign a CLA assigning copyright to me), I can change the license in the future if my FOSS project becomes the best in its problem domain or other FOSS projects in my project's problem domain become defunct.

You've probably noticed by this point at least three of the four questions have to deal with whether someone will come along and make a proprietary, commercial spinoff of my project. I notice quite a few people in the FOSS community stating that since I wrote my code for "free", i.e, without any monetary fees being incurred from development of the code in question - which often isn't true anyway, otherwise so many projects wouldn't have a "Donate" button displayed conspicuously on their home page - I shouldn't care whether someone else makes money off of my code.

And that's where Question 2 comes into play: At the very least, whenever you write code, you spend time. Time isn't free - as a matter of fact, it can be considered more precious than money; time spent doing anything is part of your life you'll never get back, ever. And if you've spent a significant amount of time working on your FOSS project (or you're about to start a new one, and are pretty sure you're going to spend a lot of time on it), you probably want to think about whether you're fine with someone spending perhaps an hour re-branding your product and making a profit with it.

Enough theory. How do you license a FOSS project in practice? I have one major FOSS project that I lead at the moment - OpenBlox - so I'll go through how I came up with a licensing scheme for that project.

How does OpenBlox do with those four questions we talked about earlier?

1. Is the code I am going to license constitute a product that others could make a proprietary (and most likely commercial), standalone derivative of by copying verbatim? In its current state, no, but very soon (most likely in 6-8 months), yes.


2. How much time have I spent on the code I'm licensing? Quite a bit - I estimate I've spent around 5,500 hours on OpenBlox so far (and it's only existed for around 2 and a half years)


3. Am I trying to use this code to advance the cause of FOSS, i.e, I'm making a FOSS application in a problem domain where no other FOSS application currently exists? Yes, definitely. There is not a single other FOSS project in OpenBlox's problem domain, although there are at least two proprietary products sharing OpenBlox's problem domain.


4. Are there already currently better FOSS applications in the problem domain for my new project? Because of the answer to Question 3, the answer to this question is of course "no."

Due to how I answered each of the four questions, the GPL looks like a pretty good choice for OpenBlox, and due to its nature as a relatively extensible and unique game engine, a permissive license works great for bundled extensions/plugins. And that's exactly what I use for it now: GPL for the main engine, with plugins and support scripts (save for core plugins that handle things like rendering) under the Apache license.

Quick note before I sign off: The LGPL is a great compromise between a strong copyleft like the GPL and a permissive license like the BSD license: People can use your code without having to change the license of their code (just like a permissive license), but all their modifications to your code must fall under the LGPL, which is pretty neat.

What is programming?

What is programming? I get that question a lot from my non-programmer friends. The interesting thing is, I had never really asked myself that question - and if my Google-fu hasn't failed me, no-one else has really answered this question, either (at least in a way a beginning programmer or non-technical person can understand ). So I'll do my best to do answer that now, and I'll voice my thoughts about the answer a little too :)

First off, what are programmers trying to accomplish when they write a program?  They're trying to solve some problem. Even when you're writing a small one-page script for fun, you've set some problem up for yourself to solve. For example, I wrote an RSS reader in Python a while ago, that notified me of new news items via libnotify - a program/framework that lets you make pop-up alerts on Linux.

Even with such a small utility (it was under 300 lines of code, if I recall correctly), there was a problem for it to solve: Check a list of site's RSS feeds every so often, and if there are any new items, set up a libnotify alert. Yes, it's a small problem, but it is a problem to solve nonetheless.

So, now we know what programmers are trying to accomplish when they write a program, how do they write the program itself? This is another question I get often - how in the world do you write a program?

Well, now the programmer knows the problem he/she is trying to solve, the programmer must now come up with a solution to that problem. Going back to my RSS reader example, my solution was for my reader script to be called via cron (a UNIX/Linux program that runs other programs every so often), and save the etag (basically a hash of a RSS feed's contents) of each feed, and check them against the current etag of the feed we're trying to update. If the etags are different, that means there is new content, so fetch the new content and make a libnotify alert.

Note that the solution to our problem is not code, and it's not UML or anything. It's just a simple, step-by-step, human-readable solution. That's how solutions to the problems your program is trying to solve should be - simple sentences, nothing more. UML and code snippets are useful, but if your solution cannot be explained in plain English (or your native language, if that's not English), you most certainly will not be able to implement it in code. I like the way the Zen of Python puts it:

If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.

So, now we know what we're trying to solve, and how we're going to solve it, we have to convey our solution to the computer in a way it can understand and run - in other words, actually implement our solution in some programming language. This is the most complicated part of programming, and the most error-prone - most software bugs are created during this step, so programmers must use extra caution while performing this task.

Unfortunately, Murphy's Law often hits hard during this step.

No matter how careful you are while actually writing your solution in some programming language, you will make mistakes. When this happens, you'll have to find where the bug occurs, figure out why the bug occurs in the first place, and then devise a way to fix the bug. Again, going back to our RSS reader example, I made a mistake that caused the RSS reader to make a pop-up notification for every news item, even for old items. My solution was fine, but I made an error implementing my solution, so I had to fix it.

Now we've answered the question of what programmers are trying to accomplish when they write a program, and then how they convey that solution to the computer in a way it can understand, we can answer our original question: What is programming?

It is the act of finding a solution for a problem, and then implementing that solution in a way a computer can understand - nothing more, nothing less. Whenever you sit down to write code, you're trying to solve some problem. This is practically identical to what mechanical and electrical engineers do for a living, which is quite interesting: Are programmers "software engineers"? Should they treat every line of code they write with the same amount of professionalism and excellence a mechanical engineer treats the design of a suspension bridge he's made that some construction workers are going to build? Those questions have been the subject of much debate in the software industry for more than a decade.

If you're not a programmer, now you see there's no "black magic" in programming. All that a programmer does while he programs is solve problems. Who knows, now you know programming isn't as complicated as most non-programmers make it out to be (it's still not a breeze by any means :)), you just might want to try programming out for yourself. :)

If you're a programmer, the next time you sit down to write some code, think about the answers to the above questions, and remember what you're doing when you're writing code - you're solving a problem. You just might be surprised how much more carefully you write code. :)