Friday Jun 05, 2009

OASIS Protects Open Source Developers From Software Patents

Crane Block

Some of you may remember a fuss that was made a few years ago by some open source people over the copyright and patent policy used by OASIS, the computer protocols standards body1. OASIS seems to have taken it to heart, because it has today announced what looks to me like the perfect basis for technology standards in an open source world.

Their new rules2 include a new "mode" which standards projects can opt into using. In this new mode, all contributors promise that they will not assert any patents they may own related to the standard the project is defining. Contributors make this covenant:

Each Obligated Party in a Non-Assertion Mode TC irrevocably covenants that, subject to Section 10.3.2 and Section 11 of the OASIS IPR Policy, it will not assert any of its Essential Claims covered by its Contribution Obligations or Participation Obligations against any OASIS Party or third party for making, having made, using, marketing, importing, offering to sell, selling, and otherwise distributing Covered Products that implement an OASIS Final Deliverable developed by that TC.

That's deliciously simple, and implements close to what I have previously recommended as the basis for handling patents in open source projects. I've written before how patent non-assert covenants are low cost for the patent holder and low risk for the developer. There is of course a "patent peace" associated with it:

The covenant described in Section 10.3.1 may be suspended or revoked by the Obligated Party with respect to any OASIS Party or third party if that OASIS Party or third party asserts an Essential Claim in a suit first brought against, or attempts in writing to assert an Essential Claim against, a Beneficiary with respect to a Covered Product that implements the same OASIS Final Deliverable.

I think this is a wonderful development for protecting open source developers from patents, and I would like to see it replicated in all standards bodies. The only issue will be whether OASIS TCs choose to adopt this mode; we need to demand it and boycott the TCs that don't.

  1. I thought the fuss made was pretty unfair at the time, since it complained about legacy OASIS approaches to patent licensing just at the time when OASIS had fixed them - the essence of the complaint was that OASIS hadn't just blown away the old approach but had left it there so that older projects weren't harmed.
  2. There's a redline PDF document showing the changes - the new stuff is mainly in section 10, although other areas had to be changed to match as well, I gather.

Tuesday Mar 24, 2009

Document Freedom Day 2009

Today is Document Freedom Day, the second year it's been celebrated. We have a great opportunity in front of us this year. With Microsoft promising to support ODF any day now in their latest office suite (and with the ODF plug-in already freely available for their older versions), it will become politically acceptable for organisations everywhere to standardise on ODF for their documents.

This is an important step, because ODF is widely supported and implemented, openly developed and provides a baseline that will be readable for years to come. That protects the ability of future generations to read our documents in just the same way that we are able to read the documents that explain what went on in previous generations.

So what can you do to celebrate? Here are some ideas:

  • Steer your organisation to adopt the Open Document Protocol, with the intent of sharing only widely available and open formats with other organisations.
  • Give a friend a copy of
  • Give a friend who's locked in to Microsoft Office a copy of the ODF Plug-in
Happy DFD!

Wednesday Nov 05, 2008

ODF Toolkit Union

Another milestone on the Open Document journey was just announced. Sun and IBM are joining together to sponsor the new ODF Toolkit Union, a collaborative community to develop the tools software developers need to support ODF in their applications. The goal is to make it very easy for any application to embrace ODF and to do so with a collaboratively-developed codebase so that it's really easy to make interoperable documents.

There's a substantial initial code donation there from Sun, including an ODF DOM and a .Net ODF library, all licensed under the Apache License v2. There is also an ODF validator, to help developers check the documents they create are correctly constructed.

Hopefully this will catalyse participation by a very wide range of developers, and promote the spread of document creators and consumers that work smoothly together. If I can clarify things for any organisation wanting to join the Union, get in touch by e-mail (details at the foot of the page). And if you're at ApacheCon, come and find me today and ask.

Tuesday Feb 19, 2008

Document Freedom Day

Comma - Open

The news just went out that March 26 2008 will be the world's first Document Freedom Day, celebrating and championing the cause of true freedom for our data. You may recall that I wrote about this back in 2006 and also gave a speech at the European Commission. I coined the term "Freedom To Leave", referring to the liberty to take your data and go elsewhere uninhibited by DRM, closed interfaces or file formats that require a particular program for faithful reproduction and use.

I believe this to be the new front line in defending the freedoms of computer users. Richard Stallman's four freedoms are now driving the mainstream of software (especially here at Sun), and while software freedom is not yet a given, the next challenge for us is our freedom to own and move our own data anywhere, any time.

Defining Data Freedom

I believe there are multiple dimensions to data freedom.

  • There is the personal dimension - being able to take the data I "own" and use it with any software or service that's appropriate.
  • There is the historical dimension, ensuring future researchers have access to the electronic information that is driving directions in society today.
  • There is the commercial dimension, ensuring that data interfaces remain open, equitable and interoperable so that we have a fair yet competitive marketplace.
All of these converge on Document Freedom Day. I'll be taking time on March 26 this year to celebrate and campaign for each of us to have the Freedom to Leave, with our data - I hope you will too.

Monday Jan 21, 2008

Strategically Ignoring Customers

Interesting to see the Microsoft folks making a big deal out of the fact that companies are implementing OOXML features in their software products. I'd hesitate to join them being thrilled at IBM's new-found support for their strategy. Truth is, when there's a monopolist in the market it's impossible to ignore the consequences of even their worst ideas, let alone their good ones. Responding to the needs of locked-in customers who will find themselves using OOXML is a different deal to strategic support.

A much more crucial question, though, is why the folks at Microsoft are so surprised. If you know your customers have a requirement, surely you respond to it? The real question this situation brings to my mind is not "why are IBM implementing OOXML features". It's "why won't Microsoft implement support for ODF at least to the same level as RTF built-in to Office?" Given they have a number of very significant and visible customers demanding that support, it seems to me they are the ones with the explaining to do, not IBM, Google, or anyone else.

Sunday Nov 11, 2007

Verse Remembered on Reading a Certain Posting on Slashdot

Epigram on Singers

Swans sing before they die - 'twere no bad thing
Should certain persons die before they sing.

Samuel Taylor Coleridge, from Verse and Worse

Monday Jul 09, 2007

The Go-Between Format

So Many Connectors

While I was considering the power plugs that appeared in last Friday's posting, it struck me that there was an untold story worth considering there. The plugs are from a replacement power supply I have now used several times for various gadgets. At one end is a block with a dial for me to select a voltage, into which I can insert a mains flex. At the other, the lead terminates in a two-pin female connector. I can then select the tip that works with my gadget and insert it in the end of the lead, selecting the polarity in the process. Power Adaptor

It's not perfect, but this device solves the vendor-imposed mismatch by offering an intermediate connector that allows close to an any-any match. Looking at this I realised we may all have lost sight of the problem we set out to solve in 2002 with what's now called OpenDocument Format (ODF).

What we wanted was an equivalent (better!) solution for portability and longevity of editable documents. The way this was being achieved in 2002 was actually not by the plugs themselves (all the various then-undocumented binary formats called ".DOC") but rather by an intermediate format, Rich Text Format (RTF). Weakly specified and widely implemented, this was the way most of us created word-processing documents that we could be reasonably sure would be opened on any platform in any word processor.

While an RTF specification is now available (ironically not in RTF format), the problems it presented - and still presents - make it unusable as an open standard with open source implementations. Why? Well, reasons include:

  1. The license is incredibly restrictive;
  2. The specification has no participative process to control its evolution so changes at random;
  3. It's too weakly specified for rigour in implementation across many platforms;
  4. There is no open source reference implementation;
  5. Because it has been tracking MS Word for years, there is no one version everyone is implementing.

So I wonder if people have been incorrectly comparing OOXML and ODF? Surely the correct comparison is of ODF with RTF? And surely, regardless of the state of OOXML, the problem remains and ODF is the best solution for it, providing a baseline interchange format we can all use?

Just in case you need inspiration from the plug tips too, see what they say to you in this brief animation my son made.

Choice and Customers

For those of you who were on vacation last week, welcome back! I ran a series of stories last week looking at places around the house where there are multiple "standard" formats for things and what the impact of them is. To recap, I looked at:

  • Choice and Light Bulbs, in which I noted that choice that serves the customer involves having as few different connectors as possible and lots of choice of light bulbs in that format.
  • Choice and Flash Memory, in which I observed that I wish I didn't have to keep buying memory cards for my different gadgets just because the format in use varied, and how some formats seem designed to actually reduce customer choice.
  • Choice and Power Supplies, in which I looked at the power supplies all my gadgets come with and observed there were so many different, vendor-serving choices in play there that I am swamped with power adaptors, but how a solution from an unexpected direction - USB - may be the answer.

Lessons Learned

Spending this time looking round the house for examples of multiple standards has been useful for me. It got me to tidy a load of stuff that had been sprawling across the study, yes. But it also led me to some conclusions about the value of having a choice of standards.
  1. There are plenty of examples of a choice of "standards" in our lives (usually validated in some way by a vendor body), but I have yet to find one that actually leads to a benefit to the customer. In the cases I have found, it arises from:
    • Vendors trying to create customer lock-in, like Sony and the Memory Stick;
    • Subsequent versions of a prior format being developed, like the Memory Stick Pro;
    • Vendors trying to reduce their costs, like those choosing to only offer 110v wall wart power supplies;
    • Vendors trying to create an after-market, like those selecting custom power plugs in their gadgets so you have to buy their in-vehicle adaptor;
    • Vendors operating in a market that is fundamentally divided, like those choosing between SBC and SES sockets for their bulbs.
  2. When standards do occur that help the customer, it may be that the fastest path is to avoid involving the vendors directly. Using USB as a power connector standard was not part of the intent of the consortium that defined USB (who were competing with Firewire, leading to an undesirable, vendor-focused choice of standards).
  3. No vendor will willingly surrender the ability to create customer lock-in or a taxed after-market. Even in the case of USB as a 5v power standard, it is still taking legislation in Asia to stop vendors being anti-social.

In other words, I have yet to see a case where a choice of standards in a single area delivers benefit to the customer. I can see all the benefits it's bringing to the vendors in the cases above, but it's also causing them unnecessary costs. But customers? No. I remain unconvinced that a choice of standards for a given application does anything for them.

Thursday Jul 05, 2007

Choice and Power Supplies

So Many Connectors

Being a gadget guy, I find I end up with a load of power adapters. There are two basic types:

  • 'Wall warts' with a build-in mains plug (or sometimes with an integrated mains flex)
  • Bricks with a connector to plug in a mains flex

I generally prefer the latter, since as Sin-Yaw observed there are multiple international standards for mains connectors and I prefer not to have to use an conversion dongle for long term use. Additionally, wall warts tend to have a fixed voltage corresponding to the country whose plug they carry (since there are multiple standards even after a century of use) whereas bricks tend to accept any mains voltage. The down-side of bricks is that the connector for the mains flex can vary, but of late the majority have had 2-pin figure-of-8 connectors.

There's enough variability at the mains end, but it's nothing to the variability at the gadget end. While many devices use a 5v supply, it seems no two devices use the same connector and polarity to deliver that 5v supply. As a consequence, when I travel I used to have to carry a whole bag of black spaghetti to be sure everything was powered. There's plenty of choice, and there are standards involved, but it all serves the manufacturers rather than the customers.

I say “used to” because increasingly I am choosing things that charge from a USB lead . I don't think the group that defined USB intended to define a standard for power plugs, but increasingly I am finding that gadgets come with a mini-USB connector so that they can be charged from any USB socket. So my bluetooth headset and mobile phone both use this method, and I no longer need to carry two of the power adapters that used to be in the spaghetti bag.

I now have a growing collection of useful things that work with this USB power standard, all from different places and all interchangeable. So I have a car-socket-to-USB plug, wall-warts for US & UK that deliver USB, and each new gadget that comes with a USB/mini-USB lead makes it easier to leave a cable ready everywhere. And since most power comes through my computer, there are fewer wall-warts left plugged into power sockets acting as electricity vampires.

I hear some Asian countries agree with me and are starting to make laws standardising on this approach, making a USB connector the only approved way to supply power. That restriction on unwanted diversity has to be good for customer choice as well as for energy conservation.

Part 1: Choice and Light Bulbs
Part 2: Choice and Flash Memory

Wednesday Jul 04, 2007

Choice and Flash Memory

I just bought a new camera, a Sanyo digital video that films in HD (720p) and stores onto flash memory cards. My plan is to give video podcasting a try, but as you can tell from the track record on LiveMink that may be hopeful. Still, it's a cool toy and I am having great fun playing with it.

I actually have a load of flash memory cards due to my long-term addiction to digital photography. The problem is, they are all different kinds. There are CompactFlash cards (in three thicknesses), SD cards, micro SD cards, Memory Stick, Memory Stick Duo and a whole load more. I have a nice 1Gb CompactFlash card but it won't fit the new camera, which uses SD cards. So I have had to get a new SD Card.Flash Memory

Why are there so many formats? Well, they seem to be defined by competing manufacturers and different regional vendor consortia. Memory Stick is from Sony, for example, and hardly used at all by other manufacturers. That means I can be sure that if I have a Sony product, replacing it with a product from some other manufacturer will also involve buying new memory cards and perhaps new adaptors to allow them to be plugged into my computer. As a result, once Sony has managed to get a customer the cost to that customer of exercising choice is higher. More than that, there are quite a few accessories that don't support Memory Stick, so my choice as a customer is further constrained.

What I really want as an end-user is many fewer formats. Choice is still good - there needs to be a range of capacities, of storage technologies, of access speeds and so on. But why should there be so many different connector/card formats?

Part 1: Choice and Light Bulbs
Part 3: Choice and Power Supplies

Choice and Light Bulbs


Reading Sin-Yaw's blog about power plugs and the need for a conversion 'dongle' last night, I started wondering what other examples of "a choice of standards" there are. Looking around the house I realised there were quite a few. Since it's a holiday for lots of my readers, I'll take the next few days to tell some stories about what I found.

So let's talk light bulbs. I pulled the box of spares out of the cupboardBox of Bulbs and took a look. There were red, green, blue spotlights; 60W and 100W bulbs; 25W and 40W candle bulbs; some 6W low-energy bulbs; a great halogen-in-a-bulb that gives a brilliant room-filling light; and plenty more. Having a choice of light bulbs is good. I can decide to put the 25W candle bulbs in the light fittings in the hall, for example, and save energy and money out there. Then I realised that I can't use the 25W candle bulbs in the candelabra in the lounge in place of the 40W bulbs I usually use.

The reason? The lounge fitting takes small bayonet connector (SBC) bulbs, but the hallway fitting takes small edison screw (SES) connector bulbs. Candle bulbsSimilarly, the reason the low energy bulbs (delivered free of charge at one point by the electricity company) are still in the box is that they have a full-size bayonet connector (BC) but the lights that need them in the kitchen all have a full-size edison screw (ES) connector.

There are similar stories for the rest; the great halogen has an ES connector but the socket where I'd like to use it in the study is BC, for example. The outside light has an ES fitting but all the weather-proof low-energy bulbs I can find that are the right shape for the casing have a BC so I am forced to continue using something incandescent. Having a choice of connectors like this simply leaves me with redundant bulbs in the cupboard. It also means when I buy a new lamp I probably can't use the spare bulbs I already have in stock. A choice of standards for bulb connectors reduces my choice as a customer since I find I am unable to buy bulbs in bulk and unable to use old bulbs in new lamps.

That doesn't mean choice is bad. I want a choice of colours, of energy technologies, of wattages, of shapes, of reflector styles and so on. But I want them all with a common connector so that when I'm shopping I know any bulb will work. Choice that serves the customer is choice of bulb, not of connector.

Part 2: Choice and Flash Memory
Part 3: Choice and Power Supplies

Wednesday May 30, 2007

US OOXML Discussion Now Public

I just heard that INCITS V1, the group making the recommendation to ANSI on whether the US should support Microsoft's proprietary OOXML format in being fast-tracked to ISO, is considering creating a public archive of its conversations on the subject. In the interim while they consider a more formal arrangement, Jon Bosak has placed the April and May correspondence on iBiblio. Take a look and, if you're a US citizen, use it to guide the comments you make to INCITS V1.

Monday May 21, 2007

Ten Reasons The World Needs Patent Covenants

Yosemite Valley River

Among the things Sun does to protect Free software developers from patent threats is to issue patent non-assert covenants. We did it for ODF, we did it for UBL, we did it for SAML, we did it for WebSSO, and we just did it again for OpenID. The idea has spread a little but needs to spread much more widely. Here's why.

  1. It's a blanket promise connected with the technology in question that's not restricted to particular facets or features - it doesn't just have a list of a few carefully-selected patents and leave you to wonder what's not granted. A blanket statement like this just says "no need to look, you're safe, Sun is on your side".
  2. It's irrevocable. It's a promise you can rely on for the long term, regardless of changes in Sun and the industry.
  3. It's global. No games involving smiles in one country or state and attacks in places that don't hit the news so much or have laws that encourage patent aggression.
  4. It's not time-limited for the projects where Sun is able to join the process - there's no "everything before this point" clause. For example, it extends into new features added to future versions of ODF all the time Sun continues contributing to its development, and doesn't end if Sun stops participating.
  5. It's reciprocal (we won't sue you if you don't sue the community). That means that we're still able to take action to protect ourselves and the community we participate in, despite providing rock-solid safety for developers and end-users.
  6. It builds a web of protection because it is reciprocal. As each new participant offers a similar covenant, the consequences of a patent action on any member of the community become greater and greater, enforcing the peace more strongly.
  7. There's no bureaucracy. Some moves in the past have sounded generous but have required some sort of action to register a license or act in some other way that limits redistribution of software that's trying to benefit from the protection.
  8. It's simple and clear. There is no game being played and you tell because you can understand the whole thing. It's about as simple as an effecive and binding legal document can be made.
  9. There's no "essential claims" language. Most statements like this one include language that says that you only get a "waiver" if you've no choice but to infringe the patent - according to the patent holder, that is, there's no certainty available! This statement sets you free regardless, no judgement call required.
  10. It's cheap! You don't have to search your portfolio for relevant patents if you don't want to, you can issue a non-assert covenant just for the cost of typing the document.

Of course, this doesn't help protect against patent trolls directly (although over the long term it will since most patents in an area come from parallel filing), nor does it address the problem of deficient covenants, but I believe a key improvement to the world of standards would be to have all bodies generating software patents require participants in their processes lodge patent non-assert covenants instead of the common current practice of simply requiring a best-effort disclosure.

It's high time standards bodies worldwide caught up with the needs of open source. We need more companies to issue - and expect - patent non-assert covenants, especially since those with the largest patent portfolios have yet to start issuing them, despite their claims of support for open source. Some time soon we'll need to collectively shun "standards" (and indeed vendors) who won't protect developers in this way.

Friday May 18, 2007

Message to Denmark: Dual Format Standards Are Bad

Twisted Spire in Copenhagen

I gave an interview at JavaOne which seems to be causing a stir because of the way it's being spun in translation in Denmark. The spin seems to be suggesting that I think it's OK to have a dual standard in a country for document formats, both ODF (the open format used by multiple applications including Microsoft Office1) and OOXML (Microsoft's Office 12 file format).

To be clear, I do not believe that. It's clearly Microsoft's strategy to socialise that idea but it's not an ideal outcome. Having a single, baseline standard for document files is clearly preferable, and because of its complexity and the way it unfairly advantages Microsoft's existing products, OOXML is clearly a very poor choice for a national standard. Thus I would always advocate having a single standard and making that standard ODF. It's good for Norway and others, so why not for Denmark too?

Will that happen in Denmark? Well, the amount of pressure Microsoft is bringing to bear on the Danish government by funding lobbying, media activity, astroturfing and more, I am worried that the legislators will cave and have a dual standard. That may sound pragmatic but in practice that's a disaster for Denmark. Because of the existing market power of the monopolist2, Denmark's history, culture and due process will end up in a format that can only be faithfully rendered with Microsoft products3.

My comments were meant to indicate that fear, and any version of them stating I support a dual standard in Denmark or any other place is incorrect. The best future for computer-maintained documents is ODF4 and I recommend Denmark follow the trend and standardise on it.

  1. Via Sun's free ODF plug-in, although it ought to be a built-in feature of Office if Microsoft are serious about interoperability.
  2. The Rambøll report already indicates the scale of the lock-in the country faces - it's assumptions of continued use of MS products are what pushed the cost up for alternatives. It seems to me that suggesting writing this monopoly into the law makes the situation worse, not better.
  3. We can already see how impossibly hard OOXML is to implement, from the poor quality of the (partial) translators that people have built and the repeated delays of Microsoft's own Mac implementation. I said more in the audio interview on this subject.
  4. Probably with an allowance for added-feature namespaces layered over it to allow products like MS Office to have proprietary features. Having ODF as a baseline does not preclude inclusion of either backward-compatibility capabilities or added-feature support, it just sets an interoperability baseline that does not assume the perpetuation of Microsoft's monopoly.

Thoughts and pointers on digital freedoms and technology markets. With a few photos too.


« August 2016