Here is another change to a system which seems very likely to generate more cash for those starving lawyers...

The Register reports that the UK Trade Marks Registry will no longer oppose applications for marks that are similar to marks already registered. That job will now be down to the holder of any existing mark.

So, the government department is stepping back from helping trade mark holders to enforce their mark. It seems to me that we will see lawyers swinging into this space. Lawyers already offer services to monitor marks, but now it will be so much more important - because the government have stopped providing that service.

I can also see opportunities for lawyers to become predatory in the trade mark space as they are with patents. I can see the rather shady lawyers looking out for small-time trademark holders that are doing quite well, but whose trademark can be diluted by a carefully targeted new trade mark application. And if you want to fight, you have to pay the lawyers. Only the big guys win. Again.

It seems that more and more the protection for copyrights patents and trade marks is drifting away from what they should be doing:

Trade marks should help provide clarity and minimise confusion in the market place. But now the government is stepping away from helping to ensure clarity is maintained. More predatory action by lawyers means less market clarity and more dilution of brands, unless you pay the lawyers to protect your trade marks.

Patents should reward R&D investment with a guaranteed but time limited monopoly on the ideas embodied in an invention. Increasingly though half baked ideas are being patented without any originality or actual implementation. Rather than encouraging investment in R&D patents are now about who has the most money to pay the lawyers. (deffinitely the case for software idea patents, other areas may not be so bad).

Copyright should reward authors for making their works publicly available by granting a time limited monopoly on making copies of their works. It should be simple: if you make a copy of my work without my permission (license) I can sue you in the civil courts. Now, with DMCA, DRM etc. making a copy without permission becomes a crime and another high-stakes lawyer game in which we are all presumed to be guilty.

It seems the the public benefit that should flow from trade marks, patents and copyrights have been completely lost, and instead we have a massive gold mine for lawyers.

BTW, I don't believe that the above problems are of the lawyers making. Rather we have to look to lobby led decisions by legislators ... which, of course, the lawyers take advantage of (because if lawyer A wouldn't, then lawyer B would ...).

I have been spreading the word about the anti-software idea patents petition on the Prime Minister's web site , and it seems that others have too as the number of signatures creeps up.

I got a response from a friend saying he had signed the petition, but that he felt that it was so badly worded that it may put people off signing, even if they agreed with the elimination of software idea patents. My friend then went on to say that perhaps patents on software would not be so bad if they were properly administered, and in particular if all patents are required to show:

• Originality. It must be original work of the patentee.
• Novelty. It must actually be something new, not an obvious refinement of an existing technique, process, or gadget.
• Actuality. It must actually exist. You cannot patent an idea. You have to build a working version.
• Replicability. Explain with the utmost clarity how others can duplicate it (and by implication what they have to avoid doing to avoid trampling on your patent) .
• Precision. No wooliness or secrecy permitted.

Good points. I responded (approximately) as follows:

I agree that the petition is very badly worded.

My take on this is that software should either by up for copyright protection *or* patent protection. Not both. Copyright protection makes sense for software because it's a written work (the bit that humans create is). Patents make much less sense because software is much more like a mathematical thing or an idea than it is like a machine.

There are many potential problems with software idea patents, but we can see some of them are exploited already. There are companies whose primary "products" are patents designed to extract licence revenue when an idea is actually implemented ( c.f. submarine patents). This is just one way that the software idea patent turns out to be a better tool for predators than as a tool to encourage creativity.

One may argue that only concrete implementations (ones that meet the list of criteria you specified) should be patened to avoid the above ... but concrete implementations of software ideas are *already* protected - by copyright. So what does patent protection add? I think it adds confusion which can be exploited by patent lawyers.

I really can not see a positive side to software idea patents. I can't imagine any software I might create that I would want to protect beyond the protection offered by copyright.

And as for the petition, even though it is poorly worded my hope is that it will open up the debate a bit, because what we really need is for the issues to be widely aired, rather than decided in a committee room by ... patent lawyers (which is what seems to be happening in the EC and other legislatures).

p.s. Have a read of this Register article on software idea patents. It's from 2003, and warns of something that did not actually happen, but the analysis is very interesting.

Those of you who think software idea patents are a bad idea and who are British citizens or residents of the UK might like to sign this petition:

We the undersigned petition the Prime Minister to make software patents clearly unenforcible.

The supporting text of the petition is:

Software patents are used by convicted monopolists to threaten customers who consider using rival software. As a result, patents stifle innovation.

Patents are supposed to increase the rate of innovation by publicising how inventions work. Reading a software patent gives no useful information for creating or improving software. All patents are writen in a sufficiently cryptic language to prevent them from being of any use. Once decoded, the patents turn out to be for something so obvious that programmers find them laughable.

It is not funny because the cost of defending against nuicance lawsuites is huge.

The UK patent office grants software patents against the letter and the spirit of the law. They do this by pretending that there is a difference between software and 'computer implemented inventions'.

Some companies waste money on 'defensive patents'. These have no value against pure litigation companies and do not counter threats made directly to customers.

I have signed this, and I would urge anyone in the UK or with a UK passport to sign too. I would have worded the supporting text differently but no matter how you phrase it, software idea patents are bad for everyone (except patent lawyers and perhaps large companies able to pay for a stable of patent lawyers).

I wanted to write a very brief note on the version naming scheme I tend to use and why I like it. But it turned into this rather long piece. Sorry ...

Some version names carry a great deal of baggage. Version 1.0 springs to mind as a version name that causes enormous angst. It seems to be held in reserve for use when the particular lump of software is first "ready" or "complete" or something of that ilk. Some projects have decided to avoid 1.0 completely and always have version numbers less than one.

Dave Thomas of Smalltalk and Envy fame once gave a talk about the version numbering scheme used at OTI, and I have used it ever since - whenever I get to choose version names. It's a simple technique that calls for the numbering of goals and steps towards those goals separately. A version name in this scheme looks like "g iii" where g is the number or name of the goal (or intent) and iii is a simple integer increment which indicates the committed (from a version control point of view) step (or attempt) towards attaining the goal.

I tend to just use integers as the goal names, so the first goal name I use for a project is 1. The first increment would be 001 (I use the leading zeros because it appeals to me - and tends to sort better with some tools). So, the very first version name on a new project will most likely be simply 1 001 (the first attempt to get to the first delivery goal). It requires no thought or agonising about the meaning of the numbers, it's just the first go at making the first deliverable.

Delivery of a system will either be time-boxed or functionality-boxed, i.e. it's got to go out on such and such a date, or it must have this list of features. Who can say how many attempts it will take to build a system in these different situations? Not I, and I don't care. It'll take what it takes. When the system is ready, by whatever criteria, I'll release it and note that it was attempt iii that was the first release of the system. For example, 1 132 would not be an untypical number for a substantial system built over several months. If that delivered system needs fixing then it's just a further attempt at the same thing, so perhaps a fixed version would have the name 1 138 if the fix itself took a few attempts.

Deciding that there is a new goal is art. The question will be: is this work we are about to do merely fixing or slightly enhancing the existing system as delivered or is this a new goal that deserves a new major number? I mostly work on database systems and tend to follow the rule of thumb that a major version corresponds to a schema (or object model) shape, and that a schema change implies a major version increment. But that's just me, and even then things are rarely satisfyingly back and white - so it's still art, as is deciding on the name/number for a new goal.

On top of all of the above we have the idea of a branch in project work. This may occur because work starts on version n+1 before version n is ready, or because version n-1 needs a fix. In many version naming schemes one can see astonishingly long version names made up of integers letters and dots all trying to convey where the version fits in to the history. In the above "g iii" scheme, every g is a branch. So, if we release version 1 032 as above and move on to 2 001 and then find a problem with the g=1 system, we just move on to 1 033 etc. If we need to start working on g=3 while g=2 is just being rolled out and g=1 is still in production, still no problem everything is clear. We might have 1 056, 2 021 and 3 002 all being worked on at the same time with the objectives and intent of each branch being clear.

Then we have composition. Projects are not single monolithic blobs, not even small projects. I'll use VisualWorks Store terminology here, which is pretty straight forward - At the top of the grouping pile we find Bundles. For every project I deliver I have a single bundle that contains all the bits that make up the system. Bundles can contain other bundles (for big projects layers help) and Packages. Packages contain code, for example a class definition or a method. So, we have a tree with a single bundle at the root and bits of code at the leaves.

As I work I version the things I'm working on (i.e. I make an immutable copy and assign a version name to that copy - my version crontrol system does most of this work for me). If I'm the team leader of a project I version the top bundle containing a version of the entire system. I do this often and I use SUnit to check the state of each new version, beating people if things have regressed.

Everyone in the team knows the goal so we all agree on a "g" number. I don't care about the increment numbers for any of the bits, other than that they must be sequential (i.e. always going up. I don't mind gaps) - the version control system remembers which versions of what go to make up the whole tree. So, for example, the root of the tree might be at 1 012 but a particularly tricky class might be at 1 046. No worries.

I don't force new version names upon things that have not changed. If I'm working on version g=2 of the system, I'd expect to start off with most components having version numbers like 1 iii. In the future if I find I'm working on version g=42 (the ultimate version of the system, of course) and I find a component with a version number of 1 046, that just shows that the original work was good (well, after ~46 increments it was).

Of course, sometimes we do need to have spontaneous branches. For example, if I find myself fixing a system in the wee small hours, I'm not going to hold back on making a fix and I don't want to worry about any version naming stuff. In these cases, I just append my initials and another increment to the version name. This is saying: This is a fix done by someone other than the agreed maintainer of this code and it's my nnnth attempt, so for example I might have 1 046.bb05 (it took me 5 goes to get it right in this case). As soon as possible I try to have the agreed maintainer of the code adopt (or reject) the changes and merge them in with the body of work for all the "g"'s affected.

Lastly, while some may worry that version numbers get big and even coin phrases like "version number inflation", I don't mind if the g or iii version numbers gets big. Why should it matter? It's just a counter of the number of goals and increments I've worked through.

... and this was a tad longer than I planned. All I wanted to say was I use the Dave Thomas version naming scheme that looks like "g iii" and it works really well for me. There you go.

While I was taking a month off traveling Australia prior to our move to London, a chap called Aik-Siong Koh was working away on 4 screen casts that go over:

• Obtaining and installing PostgreSQL (and un-installing it too).
• Configuring PostgreSQL for use with Store. You need to watch the last screencast to see why Aik-Song sets up the accounts he does.
• Installing Store and the PostgreSQL drivers into VisualWorks and creating a new empty Store repository.
• Using Store. Here Aik-Siong commits a few things to Store including the VisualWorks base classes.

There are many ways to work with PostgreSQL and Store. Aik-Siong shows us exactly how he gets started, and gives us a view of how he uses Store with PostgreSQL to manage Smalltalk source code. I think he's done a really excellent job with these screencasts.

I have added links to Aik-Siong's screencasts to the relevent bits of the PostgreSQL driver documentation on the UIUC VisualWorks wiki.

Prompted by the trickle of 'we heard a rumor that you have moved...' emails turning into a flood, I just thought I'd mention here that we have indeed moved to London.

The move was horrible, but not unusually so. We now have a home with all our things in it approximately here.

Have a look at what the Dutch have done to address spam as reported in this Computing article.

In short, the Dutch have thought about how much spam is a problem for them, had a think about how much they want to spend every year on addressing it and gone ahead and set up a team to tackle spam and given them a budget.

I don't know exactly what the Dutch team do, but I hope it is something like have a system that accepts streams of spam from citizens and dumps them into a database for analysis. I imagine that such a team would spend some time refining the way that the data is analysed, and some of the time taking the most Obvious Problems (whether specific spammers, ISPs, operating systems or people trying to fool the team themselves) and trying to do something about it.

Doing something about it is tricky for a lone country (though the article says the Dutch have had significant success). I think what would be needed would be an Interpol like body with a similar structure to the country team which would act as a clearing house for the Obvious Problems mentioned above. The clearing house would pass the information to the team in the country from which an Obvious Problem originates.

Spam is a tricky and evolving problem so the solution needs to be flexible too. I think a network of teams like the Dutch one could make a significant contribution to the process of minimizing spam.

Here's hoping.

Runar Jordahl posted about VisualWorks and multiple CPU cores, which is a subject that has interested me, so I felt I wanted to write something in response - not that I disagree with Runar at all, I am hopefully just re-enforcing what Runar has already said.

It used to be simple. A computer had a CPU that did the work supported by a host of other bits and pieces like memory, disks etc... Today computers are tending to have many CPUs. In the future they may well have swarms of CPUs each.

Smalltalk took shape in the 1970s, well before the advent of multi-core chips and most Smalltalk implementations, even today, run on a virtual machine that runs in a single operating system process using "green threads"; which means that the VM schedules the work in the image with only one Smalltalk process running at a time.

The memory space occupied by a running Smalltalk system is called an image and is much like the memory space occupied by any running program regardless of language , i.e. there is code and data in there. In Smalltalk it's all objects with some of the objects being code (bytecodes). (As a bonus a Smalltalk image can be saved in a running state to be later resumed.)

Having a single image make use of many CPUs requires that the VM run more than one Smalltalk process at a time (typically as native threads) and allow the operating system to do the scheduling (sharing the CPUs among the processes). The problems here are that the running processes are operating on the same set of Objects (i.e. in the same image) so great care must be taken to ensure that the activities of one process do not intefere with or corrupt another and also that the timing of execution is out of the hands of the VM so things may not happen in a repeatable order (i.e. the system may become non-deterministic).

One way to address these issues is to avoid them. Don't run many processes in one image but rather run many images. In this way each image continues to run in a (largely) deterministic fashion using green threads. This solution can be inefficient in it's use of memory. The set of data being actively operated upon in an image is often a very small subset of the whole image so having many images means duplicating things unnecesarily, and while running two such images might be tolerable, running 10s or 100s would be crazy (I think we can expect servers to have 100s (or more) CPUs in the not too distant future).

Another approach is to use flags or semaphores to stop processes from stepping on each others toes. So, we could lock the root of an entire object model while our process is operating on it, thereby preventing any other process from making changes until our guy has finished - but this probably means processes will have to queue to get access to the model (even read access because we want to have read consistency) which means we really only have one process actively doing anything at a time. Back to square one. A variant of this is to make the locks more fine grained so that each process will only lock a part of the model allowing others to work on other parts of the model but this makes a system harder to code and debug, perhaps much harder.

How about if we could mix the above two solutions and have have many operating system processes all running Smalltalk in the same image and have a ready made mechanism to help avoid processes treading on each others toes?

Such a system already exists in GemStone which is both a Smalltalk implementation and a DBMS.

A running gemstone instance is a single Smalltalk image which is backed securely to disk (that's part of the database-ness of GemStone). Many operating system processes can be started in the context of this image and all of these share the same pool of objects via shared memory (this is the Shared Page Cache). Each of these processes may run at the same time on any number (well, up to ~2000 with the version of GemStone we use) of CPUs. Transactions prevent one process from treading on the toes of another (another bit of database-ness).

GemStone is an excellent environment for running headless applications such as web servers (e.g. the OpenSkills SkillsBase). If you need a GUI and also want to use lots of CPUs, GemStone can't help ... which brings us to exactly the same conclusion that Runar reached.

As GemStone demonstrates, transactional shared memory is a viable way to go. I too hope VisualWorks moves in this direction.