Bobulate

It’s interesting to see Hugin show up twice in one day: Ken Wimer describes how he produced the UDS group photo with it — he focuses on the use of Hugin and the user interface — while Michael Kesper has made a panorama in Tromsø. But Michael points out an interesting issue with Hugin: a patent that may apply to the panoramic-stitching algorithm. Hugin prints a warning when using that tool, apparently.

This gives me an opportunity to talk about patents a little bit — a refreshing change from OpenSolaris packaging, even if I spend more time on the latter these days.

So, first off, the GPL (version 2, but version 3 has similar language) has an interesting clause about patents that many people forget about. It’s clause 8:

8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

So supposing you knew in advance that a patent applied to an algorithm used in your piece of GPLv2-licensed Free Software, you could exclude those areas where the patent applies. In other words, you could have something like “Hugin is Free Software, but may not be used in the United States as a consequence of US patent #N”. A surprising idea, no? That’s one special case where Free Software isn’t necessarily Open Source software (the Open Source definition disallows restrictions by country).

Source code as such (certainly in the case of compiled languages) does not implement an invention — it merely describes an algorithm. As such, I believe that the source code of a Free Software implementation of some patented algorithm (as if it makes sense to patent an idea, but hey, some patent offices hand these things out) cannot infringe the patent even if you accept the validity of algorithmic patents because it’s just describing something that has already been published — the patent text itself! On the other hand, compiled forms of the same do implement the algorithm in a machine and might be covered. I’m not sure if anyone has really dug into the implications of the division between source and object code in this area.

In cases like this, the Open Invention Network might be of use. It’s a patent pool organization for Linux. Since Hugin isn’t part of Linux (as in, the kernel bits) it’s unlikely to be helped out directly. The OIN folks are some of the most pragmatic and sensible people I’ve talked to about the effect (negative) software patents have on us all.

A brief patent search (ah, for people who think this might disqualify me forever from participating in development, I’ll point to Andrew Tridgell’s talk on reading patents — also on OSNews) didn’t turn up anything filed by the University of British Columbia that seems to apply. However, it might have been way too brief a search, as there’s darn little to go on based on the warning message from Hugin. To do it right the warning would have to be far clearer, possibly pointing to the actual patent number. Otherwise, calling the UBC patent licensing office (actually, you need to email Greg Lowe directly) for information is a little difficult.

One article on SIFT (Scale Invariant Feature Transform?) panorama stitching can be found at Springer, although the research page for SIFT from Greg Lowe is more interesting. It at least lists the exact patent number and stuff like that. Frankly I’d rather read the research papers than the patent text — at least the papers have as goal to share knowledge with the research community, as opposed to obfuscating the invention to make it broadly applicable in courts of law. However, one could apply the mechanisms Andrew Tridgell describes to the patent, and develop a stitching algorithm not covered by the patent simply by not doing something from the method described there. For instance (I’m not an image processing guy here) finding difference images in a different way.

Kudos to the patent writer, anyway, for claim 20 “A computer readable medium comprising codes for directing a processor circuit to execute the method of claim 1”, so that the patent covers the method, apparatus for implementing the method and computers doing the same. That’s surely a convolution caused by the way the patent system works (again, Tridgell: if the patent didn’t cover computers explicitly, then you could argue that implementing the method with a computer is not what is claimed, ergo you’re free).

Ugh. Too much time spent trying to understand the whole “this is my idea and you can’t have it” (as opposed to expressions or performances of an idea) culture.

While looking for the SIFT patent, I did find US patent numbers 7,639,897 and 7,711,262 which both cover guiding a user of a digital camera in making a panorama photo. They seem awfully similar to me, although obviously there’s a giant difference (sarcasm doesn’t work in writing unless Penny Arcade does it) between sweeping a scene and then re-photographing it and indicating already-photographed areas as the scene is swept. I guess there’s no patent yet on not helping at all.

A somewhat odd article that touches on patents and science crossed my desk last week in the weekend science section of my newspaper, the NRC. It’s about an experiment used to detect dark matter, the DAMA experiment undertaken under the Gran Sasso mountain. Science is largely about reproducibility, at least in the physical sciences: an experiment must be repeatable for it to have any weight as a data point. The reporting might be a little sketchy here, but it claims that the experiment is not repeatable (by researchers elsewhere) because there’s a *patent* on some parts of the original experiment and no-one can deliver the parts to another group of researchers without violating the patent license. The patent holders in this case are the research group who did the experiment in the first place.

Now, this might simply come down to a basic patent licensing dispute (which might be resolved either by granting special permission by the patent holder to another research group, or by re-using some of the original equipment, or by working around the experiment design entirely), but it’s certainly an illustration of how patents can stand in the way of even basic science questions asking “is this true?”

On the open-* front, it turns out that next week is officially Open Access Week, pushing for open access to the results of scholarly work. I would venture that publicly paid research belongs to the public, and part of the social contract in supporting institutes of learning is that the results become evailable to the public quickly. That means I’m against patents on the results of publicly funded research as well. The results should be patent — make public, published, obvious — but I can’t support further restrictions on that, as the contract around patents is a trade off between the public good and risk in investment. And for public money, that risk is non-existent.

But I digress. Open Access week. I actually found out only because one of the institutes at the faculty of science where I used to work won a prize around Open Access; of course the event around the prize is closed.

I’m in Grenoble this week for the ELCE conference, where I’m mixed in with hordes of kernel hackers and embedded device manufacturers. I feel slightly out of place as a userland-and-legal guy. I had a nice chat about patents with a gentleman from a consortium working on ultra-low-power communications; in particular when casting a specification as a standard I feel that patents which may restrict the use of the technology or prevent certan kinds of implementation (e.g. Free Software implementations) have no place whatsoever in standards. It seems like we agree on that topic; I will continue to ask people carrying ‘open standards’ on their banners to explain what they mean.

For the Open Web, two weeks remain for registration.

There have been two posts about C# and mono on PlanetKDE this week (e.g. Richard and Andreas). The comments on Andreas’ entry are quite cogent, as are those replying to Richard, but it deserves a wider audience. As far as asking RMS at Gran Canaria this weekend, it’s worth a shot if you abstract the question away from specifically-C# and specifically-mono.

At issue is the notion of a Free Platform. Or perhaps an unencumbered platform. The latter is a weaker term because it does not stress the Freedom aspect of the software we write, but it might better express the uncertainty around what constitutes such a platform. There are many things that might encumber a software program or software platform. Dictionary check:

encumber 1. weight down, burden 2. to impede or hamper the function or activity of 3. to burden with a legal claim (as a mortgage)

Here’s a non-exhaustive list:

1. Technical inadequacies (functional)
2. Technical inadequacies (maintainence)
3. Poor documentation
4. Lousy management structure
5. Licensing troubles
6. Copyright management trouble
7. Patents

To phrase the first four even more informally, that’s “it doesn’t work well”, “the code inside it sucks”, “i can’t figure out how to use it”, “the people working on it are jerks”. They are technical or organizational and well outside the scope of what the FSF (and sister organizations FSFE, FSFI and FSFLA) are normally involved in. Comparisons between C# and other languages on the first three points (Objective-C has a defrobnicator and C# doesn’t, nyah nyah nyah) miss the point. Project management is, I think, largely a personal choice and unless there are other indicators, I don’t think you can say “community management is better than having a single entity”. So contrasting Java’s Sun^WOracle^WJCP management process with whatever C# / mono uses misses the point again, except where it touches on those other indicators.

But then we get to licensing, copyright consolidation and patents, and these are the relevant indicators for determining whether a platform or software program is encumbered (vs. Free). For licensing, the question to ask is “is this a Free Software license?”. If you’re cheeky, you could check the Open Source definition as well. Mono is under a mix of GPLv2, LGPLv2.0 (not 2.1!) and MIT/X11, so the code of Mono itself and its derived works is Free Software (by this measure) and works linked to the libraries are not encumbered.

Copyright management is one of those topics close to project management style, but I believe that a project with a clearly stated management style — almost regardless of what that style is — is better-off than one with a confused, ambiguous or stupid copyright management style (an example of the latter being: publish all the source with no attribution and no copyright headers). In any case, the Mono project with its mandatory copyright assignment (to Novell) is clear.

Which is when we come to the last item on the list, patents. Software patents per se do not exist in the EU, but they do in the US. Other parts of the world I am insufficiently aware of. There is the notion of the “submarine patent” (a term whose use has mutated over time, see this article for instance about long-pending patents). In current use, it seems to be a patent that is not-well-known, but applies to some piece of technology that is incorporated into a standard (either official through a standards organization or as a de facto standard). That’s odd from a patent perspective, because the whole point of patent (dict: shown, open to public inspection, well-known) is to make sure that knowledge is pushed into the public domain at some point (that’s the social contract around patents). In any case, Aaron phrases it quite well:

there is a rather higher than zero chance of Microsoft taking advantage of its patents and coming down on C# implementations when and if it feels like it. they have an agreement with Novell, and Novell thinks it covers everyone but Microsoft seems to disagree. and that’s their public position.
however, we don’t know for sure. so it’s “only” a risk, not an absolute.

You will find similar statements about the risk entailed in using the possibly-patent-encumbered Mono .net framework in the comments to Andreas’ blog entry (the first comment, by STiAX, in particular).

So the whole issue isn’t about licensing, management or technical features, but purely about the risk involved with using a platform that is encumbered by patents. This is an issue on which the Free Software developer community has been either split or ambivalent for years. GIFs? MP3s? .NET apps? All encumbered at some point or in some way.

A similar kind of encumbrance would be if MIT (or Xorg) could retroactively re-license the X11 libraries to something proprietary (note: they cannot), thereby removing the platform upon which all Free Software X11 applications are built; it would be a risk, and given the importance of Free Software, a risk where the expected value of a manifestation is huge.

This isn’t to say there’s not other submarines in the water. We don’t know. Maybe we should. The known submarine should be treated with caution. And the side of caution is to treat C# as a non-Free platform to be avoided.