A few years ago we needed to introduce employement contracts for all staff at Catalyst. When we got the example contract back from our HR consultant, she had quite naturally biased it strongly in the employers favour, and as a consequence it had a very anal and lawyerly clause in it regarding the ownership of intellectual property. This clearly wasn't going to work well in our environment so I decided to take the opportunity to try and write a clause which was fair and reasonable, which considered the likely desires of both parties, and which expressed an understanding of the sort of environment which often happens with free open-source software. It seems that many people who are interested in working on open source software are also people who will work on (i.e. fiddle with :-) things in their spare time, but they will not necessarily consider the possible consequences of using conmpany resources to do so. I have heard of situations where employment contracts (or perhaps even government enacted legislation) will give ownership of an individual's work to their employer in such situations, so I also wanted the contract to make it clear where and how this might happen. I would like to hear people's comments on the contract clauses which we use here. Is this fair to both parties? Have I missed something? Is the meaning clear? Also, I need to make it clear that it is OK for people to use this text, so I hereby place the text of the following Intellectual Property clause in the public domain. Intellectual Property

1. All intellectual property, including source code, objects and documentation, relating to work carried out while in the employment of $ COMPANY , remains the property of $ COMPANY , subject to the exceptions outlined below.
2. All intellectual property, including source code, objects and documentation, owned prior to joining $ COMPANY remains your property. If you choose to use such intellectual property, including source and objects during your time at $ COMPANY , $ COMPANY will have the rights to their continued use in perpetuity, including access to the source code of all versions of such software in use at $ COMPANY .
3. If $ COMPANY asks you to do something, then we expect that while you work on that something, you will be being paid by us and we (or our clients) will own the IP. In some cases we may elect to open-source that, and may decide to jointly own the IP or make some other arrangement, but it would be at $ COMPANY s option.
4. If you work on something by your own choice, and on your own time, then you are welcome to own the IP, but if you use the premises or computers of $ COMPANY to do that work then you must license it under a free, open-source license agreed with $ COMPANY .
5. $ COMPANY may choose to fund some part of your time to work on OSS projects in a non-directed way. $ COMPANY will expect to own the IP for such work, and to participate in the choice of license for such code.
6. All of the above is subject to confidentiality of client information, and constraints which clients may specifically request in relation to specific project work from time to time.

Over To You I wrote that because I couldn't find examples around the place of similar things. I guess I still see people looking for that sort of thing so I'm publising it here with the idea of providing a seed which can perhaps grow into something else. A few specific questions I would like you to think about:

• Are there any loopholes in this?
• Does this seem like a fair agreement?
• Is there anything missing?
• Is there any part you would like to see changed?

Then, perhaps, if we can see some general agreement on what would, or would not, be a useful standard we can encourage people to use it in their future contracts. I am hoping that through your collective wisdom I will be changing this clause in Catalyst's standard employment contract.

You might have noticed that current Wammu is not available for Windows. The reason is simple - I was not able to produce working binary in reasonable time. Python-gammu itself seems to work, but when I run Wammu, it crashes quite soon. I tried to debug it for few evenings, but I was not successful. Therefore I again ask for somebody who would be willing to maintain Windows build. Somebody with Windows experiences will be probably able to resolve problems much faster and will help creating application that will behave good on Windows. I am not able to achieve this as I do not know Windows much and do not use it at all.

I just started poking with my Nokia 6600 and python for S60. From the highlights of the evening (I just started, so I needed to set things up).

• 'obexpushd -B' is good for receiving all the images and videos stored on the phone and taking space
• 'obexftp -b "phonename" -p somefile' - is the way to send files to the phone (I installed pyS60 on the phone, whoohoo)
• nothing works unless you use hcitool dev and hciconfig reset before using any of the above
• it is really useful if you have tried a couple of days ago to make it easier for your father to receive via Bluetooth on the laptop files sent from the phone and realised the former (since gnome in Etch doesn't have any graphical means to start an obexpushd server)

Now I would really like to know how to start a serial terminal server that listens on Bluetooth to be able to start the bluetooth console in a manner similar to the Windows or Mac method.

Update: After digging and trying different things I got to a message which put me on the right track. After a while I got the magic formula:

bounty:/home/eddy/usr/lib/linux_and_other_oses/series 60/devel/python# rfcomm listen 0 3
Waiting for connection on channel 3
Connection from 00:60:57:BB:B6:C5 to /dev/rfcomm0
Press CTRL-C for hangup


The 1 means to create a /dev/rfcomm1 device; the 3 is the channel on which the Bluetooth console tries to connect (try once and you will see it).

After that, the hint in the Mac tutorial, so I typed:

bounty:/home/eddy$ screen /dev/rfcomm0
help
Traceback (most recent call last):
File "", line 1, in ?
NameError: name 'help' is not defined
>>>

Victory! Now I can actually start to program.

Update2:
Oh, yes, I remembered I should write something like "How to connect PyS60 Bluetooth console and Linux" so is easier to spot. I tried to add myself a link to the proper page, but I couldn't make an account because of the broken capthca.

I've gotten started on setup for my Google Summer of Code project (original abstract for anyone unfamiliar), originally titled "Automated Upgrade Testing Using QEMU." In thinking about the direction I'd like to take the project, I've created an Alioth project with the title "Virtual Live OS Upgrade Testing Suite" (short name vlosuts). As discussed briefly in the GSoC application comments, the system should have a plugable backend so that one could use QEMU, Xen, etc. as preferred, and so I dropped QEMU from the title in favor of the word Virtual.

The project itself is still in a planning phase, but Ubuntu has a similar package using chroot which may serve a good basis for what I'm doing. I will be making periodic updates of my progress via this blog, but status and mailing lists should also be available at the Alioth project: http://vlosuts.alioth.debian.org/.

For everyone who's celebrating the ATI announcement about fglrx, please read this. I can only imagine that it's wishful thinking that people reading Blizzard's blog entry and interpreting "committed to fixing the ATI problems with open source" as "we're going to open up fglrx". ATI hasn't really done anything yet, and they certainly aren't playing in the same class that Intel is playing. We as a community need to push Intel hardware because they're showing an incredible level of support that no other graphics vendor is willing to do right now. The Intel guys are even working on getting Real Documentation out there so that the community has an easier time helping hack on the driver. All we have from ATI right now are very old specs and a vague promise. Don't fall for ATI's marketing unless you like getting burned.

From reading my web stats yesterday it seems that one Planet has polled by blog feed 1693 times over the first 14.25 days of this month. This is about 5 polls per hour. Another Planet has polled my blog 994 times for an average of about 3 hits per hour. How frequently does it make sense to poll blogs? Speaking for myself I think that waiting an extra 10 minutes to see my latest blog post isn’t going to hurt anyone, and encouraging Planet readers to reload the page so frequently probably isn’t doing them a favour either. For my own personal Planet installation (which mainly aggregates other Linux Planets for my own personal use) I have it poll the feeds every four hours. For a Planet installation designed for general readership it would make sense to have it poll more frequently. Maybe once every hour or once every half-hour. When I initially set up my own planet installation I aggregated the entire feed list of Planet Debian and Planet Linux Australia and it generally took between 10 and 30 minutes to poll all the feeds with 20 minutes being common (Planet does not support parallel downloads). So for a moderate sized Planet with frequent polling you might have one poll end after the next cron job for a poll has begun. It’s a pity that Planet doesn’t support pings. Will the next version do so? I would rather have my blog ping the Planets that I know of that aggregate my content and save thousands of needless polls while also giving a faster update. Finally if you need a fast response for a dialogue then probably blogs and Planets are not the communication mechanism to use, a mailing list would probably be more appropriate.

This is somewhat old news but these two articles are worth linking here and linking together for they convey nicely, in the words of AC/DC, how “money talks” and also how numbers can talk about how money talks. One article is Senators who weakened drug bill got millions from industry from USA Today and the other is on a topic that has been receiving a lot of play in the NYTimes Psychiatrists, Children and Drug Industry s Role. I am not so much a researcher of numbers in so far as I don’t produce them, and think it is a good idea to cultivate a healthy skepticism of them, but I do appreciate what they can tell us. I think the article in the NYTimes is particularly insightful because it is based on “public reports of all drug company marketing payments to doctors” in the state of Minnesota, the *only* state that requires this access. The authors of the article are careful to hedge and qualify their findings, but many of them do suggest that the more money a doctor gets, the higher the likelihood they will prescribe more meds and of a certain class. Hopefully more states will pass such legislation and more research will be done. This is my favorite quote from the article

“There s an irony that psychiatrists ask patients to have insights into themselves, but we don t connect the wires in our own lives about how money is affecting our profession and putting our patients at risk, he said.”

People were calling it futile when I asked back in last July for people to kick AMD to open up ATI's graphics drivers. Myself, I sent one email to ATI and, to my surprise, actually got a reply from a person at ATI who knew what a license is and what Open Source/Free Software is and who actually took the time to reply to my email. That was already a positive signal. And now they're really doing it: releasing drivers for ATI graphics chips under an Free license. At least they announced it, and I guess by now companies have realized that announcements like that not only are applauded to, but also get followed up on. So thanks AMD, and thanks Intel for putting up the pressure by supporting their own graphics chips. And now everybody turn their heads towards Santa Clara, CA, USA and give them a wake up call. And of course lets hope that AMD will go ahead with this project soon, and pick a sensible license. (Damn. The laptop I've got here still hasn't magically changed its graphics chip. No, I didn't buy it myself.)

While working on Gammu, I still wonder why people who want to connect their phone to computer buy phones from vendors who use own proprietary protocol or do not share any documentation. Then they come to Gammu mailing list and/or bug tracker and want Gammu to support their phone. Sometimes the fix is easy, but usually it is quite lot of work to debug unknown protocol. I know this situation quite good from past. I had Alcatel phone, which was using proprietary protocol for access to in phone contacts and events. Fortunately Alcatel released synchronisation software for these phones (it of course runs only on Windows) which had enabled debugging and it was quite easy to understand protocol thanks to logs it could produce. But as newer phones with some extensions appeared, maintaining this became harder and harder. When I looked for new phone, I decided to buy Sony-Ericcsson K750i phone. Writing support for most of functionality (well in fact all I need) was just matter of few days. The reason why it was so fast was that this phones is using open standards (e.g. OBEX, IrMC) and vendor specific AT commands are documented in freely available documents. It's your choice how good will your phone interoperate with computer. If you buy well documented piece of hardware, chance to have it fully supported is much higher.

Next time I need to buy a graphics board, It might be an AMD one. That, or an Intel one—Intel already provide open drivers (whereas for AMD it's still vapourware for the time being), but Intel's 3D abilities aren't as shiny. Guess it'll depend on what the hardware will be fore.

Ever since I've returned from DC6 I've been planning to return to Mexico one day. Given the current state of my vacation fund this won't be any time soon. However, as a kind of consolation I'll have a little bit of Mexico coming to me this week! Pante n Rococ (alternate non-official site without so much flash) from Mexico City will be giving a concert in my crummy little hometown! Yay! If you are into good Ska music and living near Hildesheim don't miss out on this one! Oh, almost forgot. The whole thing happens on
Wed 16 May 2007
Admission: 19:00, Begins 20:00

Vier Linden
Alfelder Str. 55b
31139 Hildesheim

Tickets: 12,00 Euro Advance Booking or 15,00 Euro Box Office

Not to be missed: well-known enfant terrible James Grimmelmann is guest-blogging on PrawfsBlawg. His opening commentary on the relationship between law practice and computer science:

Practicing lawyers, like practicing programmers, are professional pragmatists. Both must make their cases (and case mods) out of the materials they have available; both starve or eat steak depending on whether their creations work. The day-to-day practice of law is unlikely ever to require much high theory. We can mourn that fact because it means that they look at us with suspicion, or celebrate it because it frees us to chase Truth and Beauty and it will remain a fact either way.

Aside from the fact that I don’t eat steak, I think this is correct. Via a commenter on James’ entry, I learned that the 7th Circuit Court of Appeals is implementing a wiki (the entry page could surely use some more content). Surprisingly, it was not Posner but Easterbrook who spearheaded the effort. This is a very interesting development, but I expect it will be quite a while before any other circuit takes up the idea. Finally, I have been meaning to write about this New York Times story describing Jonathan Coulton’s success as a musician breaking with the traditional distribution /promotional channels (via 43 folders, a productivity blog that is still on my “probation” list). Unfortunately, slashdot beat me to it. I first re-discovered Jonathan Coulton during his guest episode of the Show with Ze Frank. In any event, the article is well worth reading:

More than 3,000 people, on average, were visiting his site every day, and his most popular songs were being downloaded as many as 500,000 times; he was making what he described as a reasonable middle-class living between $3,000 and $5,000 a month by selling CDs and digital downloads of his work on iTunes and on his own site Coulton realized he could simply poll his existing online audience members, find out where they lived and stage a tactical strike on any town with more than 100 fans, the point at which he d be likely to make $1,000 for a concert. It is a flash-mob approach to touring: he parachutes into out-of-the-way towns like Ardmore, Pa., where he recently played to a sold-out club of 140 . In total, 41 percent of Coulton s income is from digital-music sales, three-quarters of which are sold directly off his own Web site. Another 29 percent of his income is from CD sales; 18 percent is from ticket sales for his live shows. The final 11 percent comes from T-shirts, often bought online

Share This

More than a year ago, I published an election methods library called RubyVote. Interest in the library surpassed any of my expectations: I know of at least one startup using the library heavily in their core business and a number of fun sites, like Red Blue Smackdown, that are using it as well. The point of course, was to make complex but superior election methods accessible in all sorts of places where people were making decisions suboptimally. It its own small way, it seems to have succeeded enormously. Over the last year, I've been asked by a variety of people if they could use RubyVote for their own organizational decision making -- tasks like electing leadership of a student group or members of a non-profit board of directors. Since RubyVote was just a library without a UI of its own, I had to tell them "no." I caved in eventually and got to work on a quick and dirty web-based front end to the library. That project grew into Selectricity which is a primarily web-based interface to a variety of different election methods and voting technologies. You can currently try out quickvotes which can be created in half a minute and voted on in a quarter but which bring all of the power of preferential voting technologies to bear on very simple decisions. Prompted by Aaron Swartz, I also built a mobile phone version that's lets you send a short email or SMS to create or vote in a election. For those that follow research in voting technologies, there's not a lot of new stuff here. What's new is that this project, unlike the vast majority of voting technologies, is interested in the state of the art for everyone but governments. Clearly government decisions are important but they're one set of decisions, usually only once a year. Selectricity is voting machinery for everything and everyone else. It was announced in a variety of news outlets today that Selectricity was selected for grant from mtvU and Cisco as part of their Digital Incubator project. As part of that, I'm going to be working with some other voting technology experts to bring tools for auditable elections, cryptographically secured anonymity, and voter verifiability to the platform (I have only rudimentary functionality today). There are a couple people who will be joining me on the project this summer and we will building out what I hope will be an extremely attractive platform for better every-day decision-making. More than the grant though, I'm excited about the visibility that use by MTV will bring to the project. Most of all though, I'm just excited about more free software and more (and more accessible) democratic decision making. My adviser Chris Csikszentmih lyi put it well:

One of the big arguments against preferential voting, or new voting technologies, is the fear that they would disenfranchise the average person who doesn't yet understand how they work. Certainly, making all voting technologies open source is critical, but the issue of familiarity is worth considering. We re hoping that MTV and eventually American Idol will move their voting over to Selectricity, allowing it to work as both a technical tool but also pedagogically, training future voters. Why not integrate democratic processes into all your software and communications tools? Why not use the best democratic processes available, so long as they're available to everyone?

Currently I am considering the priority scheme to use for some highly available services running on Linux with Heartbeat. The Heartbeat system has a number of factors that can be used to determine the weight for running a particular service on a given node. One is the connectivity to other systems determined by ping (every system that is pingable can add a value to the score), one is the number of failures (every failure deducts a value from the total score), one is the weight for staying on the same node (IE if the situation changes and the current node is not the ideal node you might not want to immediately move the service to a different node as that gives some seconds of no service), and one is the preference for each node that may run the service. For a given node to run a particular service then the score has to be greater than all other nodes and also greater than zero. If all nodes have a score that is zero or less then the service will not run. Now in the case of a service that repeatedly fails (EG a filesystem mount that relies on a hardware RAID which is not connected) then what should we do? One option is to have the score for running on a particular node be for example 100 times the value that is subtracted on failure. In this case after 100 failures on that node (and an appropriate number of failures on other nodes which are permitted to run the service) it will be disabled. Then the service has to be explicitly re-enabled (or a node rebooted) before it will run again. The other option would be to have the value that is subtracted on failure be less than a billionth of the score for running on a particular node, so that the service will keep trying to start for the next few hundred years. The up-side of this is that there is less fiddling required, the down-side is that some CPU and disk resources will be kept active in repeatedly starting the service. Now I have to decide which option to take in this regard, any comments would be appreciated.

While the announcement from ATI about their intention to provide better support for Linux is certainly welcome it’s not clear what exactly they intend to do. They don’t appear to have actually said that they will release their drivers. This could actually be a really good thing - for example, I’d expect that documentation and support for people producing free drivers would be at least as useful as their current proprietary code - but it’s worth bearing in mind.

Today is the end of a pretty long week-end of dealing with samba. About 10 days ago, we (the samba packaging team in Debian) were privately notified of security issues found by the Samba Team developers in this quite popular package. This very close to one of their bi-annual releases, namely 3.0.25. No less than three security issues were unveiled. Two of them (CVE-2007-2446 and CVE-2007-2447) affect all currently supported Debian releases, namely sarge, etch and sid. One (CVE-2007-2444) affects both etch and unstable. This was the beginning of long days of rehearsal, helped out by Noah Meyerhans from the security team. Finally, updated versions for sarge and etch were uploaded to oldstable-security and stable-security for the autobuilders to catch up (they still are catching up because I uploaded the updates without the .orig.tar.gz file, which unveiled a bug in the security autobuilders apparently). These updates for sarge and etch should be available as soon as the security team completes the final checks and approval, I guess. And, today, the Samba Team gave us early access to the newly released 3.0.25 version of samba so that we could build and upload that package 2 hours before it was officially announced..:-) Thanks a lot again to the Samba Team for their care and more particularly to Gerald "Jerry" Carter (someone I have deep respect for, along with Jeremy Allison and Andrew Tridgell). Thanks to Steve Langasek for his hard work preparing the 3.0.25 release (tracking down an upstream bug in the Pythin bindings build). And, finally, thanks to the Debian security team and more particularly to Noah Meyerhans for his work on backporting some of the patches. This was a tiring but really motivating week-end. I hope that all Debianers who use Samba will enjoy the result.

AMD has announced that is going to deliver open graphics driver for ATI graphics card. Good news.

One of the most requested features for Webconverger is a “customization kit”. Before I pointed enquirers to Debian Live and a guide, which didn’t seem to satisfy the “easy to use” crowd. Now I’ve created a Web form where you can easily tell me what customized homepage you would like and I will go away and build it for you. For 20GBP. I just need 25 orders a month and I can pay my rent. ;) Since Webconverger is a collection of free software Debian packages, feel free to become a competitor. :)

Yes, Microsoft have started swinging their patent bat a little harder. However, before everyone gets all screamy about the "235 patents" thing, read a little closer:

the Linux kernel [...] violates 42 Microsoft patents. The Linux graphical user interfaces - essentially, the way design elements like menus and toolbars are set up - run afoul of another 65, he claims. The Open Office suite of programs, which is analogous to Microsoft Office, infringes 45 more. E-mail programs infringe 15, while other assorted FOSS programs allegedly transgress 68.

While I can forgive a journalist the sin of not knowing the difference between Linux-the-kernel and Linux-the-entire-FOSS-ecosystem, can people who should have a clue about this please stop perpetuating the inaccuracy? Yes, 42 patents is still pretty bad, but it's not 235, and getting facts straight is what we do on this side of the debate -- the frothing and bullshit is what the other guys do. Once you start looking at the various categories of patent, it really does make it obvious that there's some straw-grasping going on here. If GUI elements really infringe on 65 Microsoft patents, it seems reasonable to assume that KDE and Gnome have a subset each, so presumably nobody gets the full brunt of that lot. Also, those 68 "assorted FOSS programs" patents probably includes such widely-used classics as this pearler of a program (chosen at random from Freshmeat for it's likely small userbase; no other ridicule is intended or implied). What galls me, though, isn't the bandying around of random inaccurate numbers, it's classy things like this:

[some Microsoft sock-puppet] refuses to identify specific patents or explain how they're being infringed, lest FOSS advocates start filing challenges to them.

Yeah, we'd hate it if the patent system were at all used in the manner in which it were intended. I don't suppose anyone else is getting SCO-style "we've got 100,000 lines of infringing code, but we're not going to tell you which ones" flashback at this point? Personally, I think that if Microsoft ever does starts with a patent smackdown, it won't be 235 patents, it'll be two or three, the strongest ones they can find, and 90 minutes after the plaintiff(s) is/are served the infringing code will be history, and we'll go back to living our lives as normal. That's even assuming that the patents are legit, which is by no means a given (even with the US' insanely broad patent provisions). As the linked article explains, the US Supreme Court has started getting a bit noisy on the subject of over-broad and pointless software patents, so perhaps Microsoft is just getting it's licks in before the Supremes take it's noisy rattle away from it. There's some side-commentary on this issue at Groklaw, and the Patent Law blog has a quick mention of it too (with all sorts of nice frothy comments, to boot).

I just released new version of Gammu, you can download it from download server. Changes to latest testing version are relatively small:

• Do not use asynchronous I/O on Windows.
• Make USSD work with AT phones.
• Fix setting date on Siemens MC75 (Rudolf Cejka).
• Config file on Windows is now searched in Application Data folder.
• Avoid corrupting vCard when some fields are empty.
• Properly handle OBEX error codes (bug #298).

Stay tuned, release evening will continue ;-).