LWN.net Weekly Edition for May 5, 2005

KOffice heads toward 1.4

The first beta of the KOffice 1.4 release was announced on April 29, so we thought we'd take a look at this release and see how KOffice was shaping up. How does KOffice 1.4 stack up against the competition, namely OpenOffice.org and standalone applications like Gnumeric, Abiword and the Gimp?

Since the release is still in beta, we were checking for features compared to the other suites, but ignored any stability issues. To try out KOffice we downloaded the "Klax" live CD. There are also binary packages and source code. We also compiled KOffice beta1 on Ubuntu "Hoary" with no problems.

Since support for the Open Document Format is one of the big features in KOffice 1.4, we decided to test that out first. Unfortunately, we didn't have much luck. We started by opening a document in OOWriter (from one of the OpenOffice.org 2 preview releases from Ubuntu's package repository) and then saving it in the Open Document Format. KWord refused to open the document, complaining about the paper size. When we tried opening a document from KWord, saved in the Open Document Format, it also failed. KWord had no trouble opening other file types, including Microsoft Word, which is more likely to be found in the wild at the moment anyway.

Next we tried out KSpread and KPresenter using some PowerPoint documents we found online using Google and the Gnumeric testing spreadsheets. Unfortunately, KSpread and KPresenter are a bit less capable than OpenOffice.org or Gnumeric when it comes to handling these documents. The test spreadsheets showed that KSpread doesn't implement many of the functions that are available in Gnumeric and OpenOffice.org Calc. KPresenter had trouble with the Microsoft PowerPoint document, only displaying the text for the slide show and badly mangling the text formatting.

KWord, KSpread and KPresenter are fine for creating original documents, but users may wish to look to OpenOffice.org or Gnumeric and AbiWord for exchanging documents with users of Microsoft Office or OpenOffice.org.

We did like Kivio, the KOffice diagram and flowchart program. It comes with a hefty selection of stencils, and the interface is clean and easy to use. The beta is a bit unstable, but we expect that problem will be taken care of before the final release.

Two applications that make their debut with the 1.4 release are Krita and Kexi. Krita is an image editing application, and Kexi is a database management application. Krita looks promising, though it doesn't seem quite as full-featured as The Gimp just yet. It offers a much different interface than the Gimp and is a bit crowded at first, making it a bit difficult to work on larger images. Krita does allow the user to open new windows with the same image, but this is also a bit less than optimal.

Kexi could be the Access-like application that many Linux users are looking for. It's a bit rough around the edges at the moment, but it could be the answer for many Linux users who want to create simple databases that do not require MySQL or PostgreSQL backend.

KOffice also includes KChart, Karbon14, KFormula and Kugar. Kugar is an application for generating "business quality reports." KChart is, as the name suggests, an application for generating charts. It can be used as a standalone application or within KSpread. It offers a fairly extensive variety of chart types, including bar charts, polar charts, and "ring" charts. Karbon14 is a Illustrator-like application. We didn't get time to test it extensively.

Users who are interested in test-driving KOffice should check out the "Klax" live CD -- it's a relatively small download and offers the full range of KOffice apps and the KDE 3.4 desktop. The final KOffice 1.4 release is slated for June.

In all, it looks like the KOffice 1.4 release will be a significant move forward for KOffice. In some ways, several of the KOffice components are still a way behind the other free office applications in terms of document format support and features, but the suite does provide a usable alternative for Linux users who don't require extensive Microsoft Office compatibility.

Comments (7 posted)

Where community and commerce meet

Free software development projects and for-profit companies can often interact in ways which are rewarding for both. The interaction between the two is not always entirely smooth, however, and occasional frictions can emerge. Resolving these issues as they come up can yield insights about how the free software community operates, and how it interacts with the commercial world.

As an example, consider this note posted by Bruce Momjian to a couple of PostgreSQL mailing lists. Interesting things are happening with free database management systems, and various companies are beginning to take note. Bruce welcomes commercial attention, but worries about some problems which could result if things are not handled carefully.

The main issue would appear to be companies working on features for PostgreSQL without first discussing their proposed changes with the community. These companies risk finding that they have duplicated another company's work; merging overlapping patches then puts a stress on both companies - and on the community. Companies which keep their patches until a late stage may also find that the community is unwilling to merge the finished product for any of a number of reasons.

This kind of problem can usually be dealt with relatively easily if it is caught in an early stage. By the time a large amount of effort has been expended, changing the direction of a project can be a harder task. For this reason, many development communities would like to see proposed additions as early in the process as possible. This desire often clashes with a company's goals: the company knows what sort of patch it wants to produce, and corporate management is often afraid to release code which has not been polished, run through a quality assurance process, and cleared by the lawyers. Releasing early-stage code with missing features and known problems so that the community can redirect the development process is just not the pointy-haired way of doing things.

When a company owns a given free software project (think MySQL, OpenOffice.org, or JBoss), there is usually a certain level of predictability in its development process. The controlling company has its agenda, and will accept or reject patches based on whether the patches further that agenda. Many or most of the major developments are centrally planned from the outset. If another company wishes to encourage development in a certain direction, managers from both sides can get together and work a deal. Managers tend to like to work that way.

A more community-driven project can be harder for companies to engage with. Promises to merge a given feature are hard to obtain and even harder to enforce. The whole process can seem whimsical and hostile to corporate five-year plans. But this is also the process which, at its best, produces high-quality code which is maintainable over the long term. Companies can learn to work with - and appreciate - the community development process, but there is a learning process involved. It all tends to work out with successful projects, but each project seems to have to find its own way to work with the commercial world.

The other problem mentioned by Mr. Momjian is that companies are hiring PostgreSQL developers to work on closed-source extensions. This is OK in general: PostgreSQL carries a BSD license, and it is hard to argue with jobs for PostgreSQL hackers. But the project needs developers to survive; companies which hire those developers and prevent them from working on the core system risk killing their golden goose. Bruce asks that such companies at least allow their developers to spend some of their time working on the free PostgreSQL core.

The interface between corporations and free software development projects has its share of traps and potential problems, just like any other relationship. Given time and sufficient will, these problems can be worked out. It is worth the trouble: each side has a lot which it can offer to the other.

Comments (4 posted)

Software, reverse engineering and the law

Reading about proprietary software law is sometimes a shock, when you are used to the freedoms of the free software community, because your natural response to hearing how the law works outside the community is to say: "But that's awful. That can't be the law." And frankly there is nothing that advertises the benefits of free licenses as clearly as a brief rundown on what you can't do outside that realm of freedom. But with the recent flap about BitKeeper, it might be good to review what the current state of the law is on reverse engineering.

Unfortunately, if we define reverse engineering as "trying to figure out how something works," then the state of the law is that there are places on Planet Earth where there are laws restricting what you are allowed to do. The center of that restrictive universe right now is the US. Cem Kaner, Professor of Software Engineering and Director, Center for Software Testing Education & Research at the Florida Institute of Technology, believes that restrictions on reverse engineering are holding American programmers back from being able to compete:

Let's take a look at what you can and can't do around the world, when you wish to reverse engineer proprietary software. We can view it as we would learning about a repressive government's laws about dress code or some other issue you don't normally worry about, but need to study and obey for travel there, so you don't end up in the clink, so to speak, for wearing shorts or sandals or whatever else they have in their beanie as being worth making a law about.

I polled attorneys and engineers in the US, the UK, and Australia, and I've collected some resources as well, and I've found that there is a good deal of flux and some confusion in this area of law. I am not a lawyer, as you know, so if you need to know how the law applies in a particular situation in your area, please get advice from an attorney.

Why Do People Reverse Engineer Anyway?

People have many reasons why they might wish to reverse engineer software, but two important ones are 1) to make software that can interoperate with the software being studied and 2) to make a product that will compete with it. Why might the the knowledge not be visible? Dan Shearer, Samba Team and open source virtualization specialist, provides some possible reasons:

• The original programmer is dead, or the company has died, or otherwise events have buried the explanation for how a technology works from the engineer and perhaps everyone else;

• Commercial protection. A company feels its commercial goals would be compromised if the knowledge was published, so it keeps the knowledge secret (and often tries to obscure the knowledge so it is difficult for anyone to find it.)

• Encumbrance on the knowledge. The knowledge might be published, but under such terms as anyone who agrees to the conditions under which the publication is made is limited in what he can do with it. Example: Microsoft's approach to detailed API sharing (Kerberos etc etc.) So the reverse engineer may choose not to see the knowledge. A basic encumbrance is sometimes cost for access to the documentation.

Having said that, the problem with seeking to know whether you can do reverse engineering or not is that it isn't consistent around the world, so your answer depends on where you do it and why.

A Brief US History of the Law on Reverse Engineering

Reverse engineering of manufactured products was originally designed, in US law, as a kind of balancing limit on trade secret protection, to ensure that a company couldn't gain, through that back door, a perpetual, unlimited monopoly on unpatented inventions. With manufactured products, the system worked well. As long as you bought the product legally, you were free to take it apart and see how it ticked. Most of us did that to clocks, radios and various other appliances when we were kids. We were free to do that because trade secret law didn't grant the owner the exclusive right to possess the secret. It only protected the owner against improper acquisition and/or disclosure of the trade secret.

That means that if I broke into your factory and stole your product and then reverse engineered it to figure out how you did it, it wasn't all right, but if I bought your product, it was perfectly legal, and you couldn't prevent me from discovering your secret, if I was willing to put in the time and effort to reverse engineer to obtain it. Reverse engineering was a lawful way to obtain a trade secret. And the time and effort involved was considered enough of a barrier that it gave the owner of the trade secret a measure of protection, by giving him a running start ahead of any copycats.

In fact, reverse engineering was considered to be a good thing, and in the 1989 U.S. Supreme Court decision, Bonito Boats, Inc. v. Thunder Craft Boats, Inc., the court said that reverse engineering was "an essential part of innovation," because it could lead to advances in technology. If you remember the DVD Copy Control Association v. Andrew Bunner case in California, it was a trade secrets case that held that reverse engineering is presumptively legal.

Both white box reverse engineering (decompiling the object code to reveal its structure and figure out the interface specifications for interoperability purposes) and black box reverse engineering (where you only look at a program's input and outputs) are legal normally in the US, if the goal is interoperability. I say normally because fair use is decided case by case. Bypassing anticircumvention devices, however, is a separate no no. Section 1201 of the DMCA forbids reverse engineering if it involves circumvention of a technological protection measure, with limited exceptions, such as for encryption research and security testing. You could probably get away with reverse engineering to fix something, and, while security testing is explicitly allowed under the DMCA, this exception is unclear enough that some have become afraid to avail themselves of it. Fred Von Lohmann of the EFF has described Section 1201 like this: "thou shalt not circumvent" and "do not break into my castle and do not violate my house rules -- seen from the perspective of a copyright holder".

Why Software is Different from a Cotton Gin

There are differences between reverse engineering a mechanical device, like a cotton gin, and reverse engineering software. Shearer says this about the difference:

Because computer software can be protected not only by trade secret law but by copyright and patent law as well, the issue of when you can and when you can't reverse engineer gets complex. If I invented the cotton gin, I could patent it for a time, gaining a monopoly for a time with the tradeoff that I must reveal all my secrets, or I could protect how I did it as a trade secret, and I couldn't use patents to protect the product at all. So my cotton gin invention got one form of protection, tops.

With software, you can get at least two bites of the apple simultaneously. Software is automatically copyrighted, and it can be patented too. And you can opt for trade secret protection instead of patents. Then you can slap a restrictive license on top, if the market will let you get away with it. And that is part of what makes it so complicated to figure out when you can and when you can't reverse engineer. It's also why some view software patents as overkill. Kaner on recent US decisions that reverse engineering is not fair use:

The fact that software can be protected so many ways also means you can be sued on all of them - trade secret, copyright, patent and contract law theories - if you were unfortunate enough to have signed away your rights to reverse engineer (or to tell what you learned from doing so). Software licenses that forbid reverse engineering may or may not stand up to a challenge, but most folks think that they will. At any rate, there was a case where a federal court of appeals said that such a provision is enforceable and does not conflict with the Copyright Act, and the Supreme Court declined to review the decision, and they would have, if they had seriously disagreed. So be careful what you agree to.

Software is therefore a separate issue when it comes to reverse engineering. The time and effort involved isn't equivalent to reverse engineering a cotton gin, particularly with computers automating some of the heavy lifting.

When Can You Reverse Engineer? -- It Depends

Copyright protects the expression of an idea, but not the idea itself. That is why you can do reverse engineering to figure out how software works and then write your own program to do the same thing. The problem that arises with copyright and reverse engineering is well expressed in this explanation of how to avoid a copyright infringement claim:

Patents protect the implementation of the idea, and that makes it the bully on the block, particularly in software, where there may be limited optimal ways to accomplish something. There is no fair use or reverse engineering exemption with patents. So you can argue all you want about how you had a fair use right to reverse engineer under copyright law, but if the part of the software you reverse engineered was also patented, you are, with some limited exceptions, sunk.

And how do you know in advance if you are going to end up violating a patent? Don't ask me. Nobody seems to know how to avoid violating someone's software patent under the current US system. You seem to find out mainly when someone sues you. Many observers believe the US patent system is broken and needs to be reformed, at a minimum, so that honest people can figure out how to avoid infringement. Meanwhile, ask your lawyer.

But just know that there is no reverse engineering right per se with patented inventions to find out how they work. It was originally the case that with patents you were supposed to reveal the tricks you used. It was the tradeoff. Sadly, software patents are now granted in the US without applicants having to reveal all the inner workings, so some legal commentators have argued that reverse engineering doesn't infringe under the first sale principle of patent law, or if you do it to satisfy your scientific curiosity, that you could assert an experimental use defense. And note that while under copyright law interfaces are not protected, they can be under patent law.

Whether or not reverse engineering is legal also depends, I've learned, on where you do it and why. Note that what matters is where the reverse engineering was done, not where the software was written. If you are in the US and you are doing it for interoperability purposes, as opposed to for the purpose of creating a similar and competitive product, you are probably safe from a copyright infringement claim, but may run afoul of a patent. (But in any particular situation, hire a lawyer to advise you.)

What About Outside the US?

The US is easy to figure out, compared to, say, Japan. At least in the US, they put it in writing. In Japan, it's assumed that reverse engineering for interoperability purposes is probably legal, but the law doesn't come right out and say so. In Japan, the law has no "fair use" concept for computer software, so reverse engineering is technically copyright infringement. Yet, as noted, most legal scholars say that reverse engineering is probably legal in Japan in a practical sense, even though their copyright law doesn't explicitly say that. Note that Japan does accept software patents.

Here's a PDF that tells you what you can use reverse engineering to accomplish in Australia, and as you can see, it's essentially similar to the US:

I asked Brendan Scott, of Open Source Law, an expert on tech law there, if it would be accurate to say that you can do more in Australia than in the US, or if their new law is as restrictive; here is his answer:

The anti-circumvention language in the FTA looks likely to keep lawyers employed for some time:

In the European Union, reverse engineering is allowed under Article 6 of the European Software Directive, for interoperability purposes only, not for creating a competing program, and the law strictly limits what you can do with the knowledge you gain. You can't publish it, for example. As you know, the patent situation in the EU is a bit messy at the moment. Software patents are supposedly not allowed, after the Munich Convention, but folks have found ways, and that effort continues. Should the directive pass as presently written, it is expected to make reverse engineering of any patented materials illegal, except for limited exceptions. The directive also states that the ideas and principles underlying a program are not protected by copyright, and that logic, algorithms and programming languages may to some extent comprise ideas and principles.

There are some differences between US and UK law, and here's a paragraph from the UK Patent Office website on what constitutes a copy of a computer program in the UK:

There is no provision for decompilation (white-box reverse engineering) in UK copyright law, and no fair use defense if the reverse engineering is for commercial research or study. And, there is no right to breach confidentiality agreements. In Stac Electronics v. Microsoft Corp., Stac was found to have committed a trade secret violation by reverse engineering a beta version of MS DOS that they had gotten in confidence and then using the information they gained in making their own product. However, in the UK, the EU copyright directive trumps any contractual agreement that it contradicts, so decompilation carried out for the purpose of interoperability is allowed, under that umbrella, as long as you don't reveal any confidential data.

There is also a provision (50BA) made for "observing, studying and testing of computer programs":

So, there is no fair use (or fair dealing, UK's much stricter escape hatch) for decompliation or copying during decompilation. However, sniffing (black-box reverse engineering) for interoperability purposes is allowed.

Note that the UK began to revise its patent law in January of 2005.

Summing Up

Kaner points out that there is research going on to make reverse engineering technically impossible:

Shearer brings up an interesting point:

The general trend in the law is to harmonize laws around the world, so they are interoperable, so to speak, to reach an international working consensus on what the laws on copyright and patents ought to be. It's obvious why that would bring benefits. Legislators can see that clearly. Unfortunately, not everyone in the world as readily sees the real benefits that come from interoperability in software.

Everyone sees the benefits of having train tracks be uniform, so you can get on a train in New York and arrive in California safely, and without having to get off and then on another train for another width of tracks. It's no different with software. And as software becomes more and more obviously the underpinning of a globalized society, including its commerce, hopefully more and more legislation will reflect that awareness.

In the meantime, please be careful. That includes using this article only as a jumping off point, and asking your attorney for advice for any real-world application of the law in your area of the world.

Additional resources

Please see this page for a set of pointers to additional reading in international copyright law and reverse engineering.

Comments (25 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Umbrella 0.7; New vulnerabilities in ethereal, gzip, ImageMagick, phpMyAdmin, postgresql, tcpdump, ...
• Kernel: Resource limits for audio latency; The end of synchronize_kernel(); Defending against fork bombs; Philips webcam driver issues.
• Distributions: Testing Kubuntu 5.04; Nimbus 4.0; Progeny Debian 3.0; Sarge on ice
• Development: Amuc - the Amsterdam Music Composer, GNOME Art, Git Traffic, new versions of Dump/restore, Daffodil Replicator, Sendmail X, Wiki, ClamAV, PythonCAD, FLTK, KimDaBa, Krusader, GNU Classpath, DrPython.
• Press: Ubuntu Down Under's LaunchPad, Kernel Archive history, LAC coverage, Red Hat signs DOD contract, Integrity Checkers, Rich Web Text Editing with Kupu.
• Announcements: Carrier Grade Linux news, Linbox Rescue Server GPL'ed, Win4Lin Pro 1.1, (IN)SECURE Mag, OpenVistA R and D Meeting, YAPC::NA schedule.
• Letters: BitKeeper blunders.

Next page: Security>>