Any spreadsheet can compute the balance of a banking account and let you know just when that account became overdrawn. One of the useful things a personal finance manager can do is to generate reports which provide a more complete picture of what is happening with one's money. Such reports can prove most useful at those animated dinner-table discussions on why the accounts are overdrawn yet again. The financial situation may be disastrous, but at least you have a nice pie chart explaining the situation.
For those who do need pie charts, GnuCash is currently the only viable option. This program offers a wide set of reports in both tabular and graphical formats, with a high degree of configurability. Unlike account registers, reports are displayed in the GnuCash main window, so only one can be viewed at once. Reports are persistent across sessions, so one need not worry about having to repeat a lengthy series of customizations.
GnuCash can export reports to HTML files, nice for posting a group's finances on the web. HTML export only seems to work for the tabular reports, however; the others yield a blank page. There is a "stylesheet" feature which affects both on-screen and exported reports. Two stylesheets are provided: "ugly" and "ugly with brighter colors" (the GnuCash developers used less informative names).
KMyMoney 0.8 does not provide graphical reports, but it does have a wide variety of tables. The display is readable, and highly configurable. Reports are persistent, but the mechanism takes a little getting used to. When a report is created, it is represented by a tab in the top of the report frame. The next time KMyMoney is started, that tab will be missing, but the report (if customized) will appear in the tree-oriented list of options. KMyMoney reports can be exported in HTML and CSV formats.
Grisbi, too, only offers tabular reports. There is an unbelievable number of configuration options, obtained by navigating through two layers of tabbed windows. The output has the requisite information, but is, in your editor's opinion, relatively hard to read. While both GnuCash and KMyMoney can create reports on investments, balances, and net worth (along with transactions), Grisbi is limited to transactions only.
None of the packages reviewed offers a useful report seen in some proprietary offerings: a projection of an account's balance into the future taking scheduled transactions into account. Such reports are necessarily inaccurate, but they can give a useful indication of whether trouble is approaching in the near future or not.
GnuCash's graphical reports set it apart (for now - KMyMoney 0.9 will have charts as well), but the truth of the matter is that the tabular reports are the truly useful ones. Unless your dinner-table budget discussions require using OpenOffice to present the situation, pie charts and the like are not often helpful for real decision making. KMyMoney's tabular reports are as good as GnuCash's, and arguably easier to read. Grisbi's narrower range of reports detracts from its usefulness here.
Any worthwhile personal finance manager will have the ability to handle transactions scheduled for the future. This feature can be useful for future cash flow planning, speeding up the transaction entry process, or for simply getting a reminder to send off that car payment before the repo man shows up with a tow truck. Scheduled transactions can also be used to handle loan repayment and to help track loan balances.
GnuCash has a well-developed transaction scheduler, currently the best of the three packages reviewed here. The usual parameters can be set: amount, begin date, number of occurrences, payment frequency, accounts to use, etc. GnuCash has the widest selection of frequencies, and is the only one which can handle semi-monthly events. Since semi-monthly paychecks can be common - at least in the US - its omission in the other finance managers is an annoyance. An existing transaction can be used as a template for a scheduled transaction, which is a nice time saver.
Scheduled transactions can be entered automatically into the relevant ledgers, or they can wait for a manual action by the user. Another feature unique to GnuCash is a popup reminder of due transactions when the program starts up; those transactions can be edited and entered immediately, or that work can be postponed for later. The main window for scheduled transactions offers both a list view and a six- or twelve-month calendar showing when events will occur.
The GnuCash scheduled transaction code does appear to be a work in progress in spots. Different graphical conventions in parts make it look like something bolted on late in the development process. There is a mention of variables which can be used in transactions, but no apparent way to use the capability. Your editor was also able to crash GnuCash by playing with the scheduler windows.
KMyMoney offers many of the features needed in a transaction scheduler, but this feature needs a bit of work yet. Your editor succeeded in crashing the scheduler when attempting to create an event from an existing transaction; let it be said that crashes in a program intended to be managing one's money can be disconcerting. That said, KMyMoney's scheduler is close to what it needs to be.
The transaction editor contains the usual information. There is no provision, however, for split transactions, and no reminder options. The list of available frequencies does not include semi-monthly. It does offer both "fortnightly" and "every other week," however, leading the user to wonder just what the difference is. "Quarterly" and "every three months" are also distinct options.
The main scheduler window comes up in a list view, sorted by transaction type. There is also a single-month calendar view which is far less useful than the multi-month calendar provided by GnuCash. The single-month calendar has space to put actual information - payee and amount, for example - on the screen, but KMyMoney, instead, just puts in a large, red number showing only how many transactions fall due that day. The list and calendar views cannot be seen at the same time. One might think that double-clicking on an event in the list view would allow editing that event, but, instead, it switches to the calendar view. There appears to be no way to get KMyMoney to step through transactions which have fallen due; instead, they must be selected and entered, one at a time, from the list view.
Grisbi's scheduler is the least featureful and hardest to work with of the set. A number of features, such as creating a scheduled transaction from an existing register entry, do not appear to actually work. The editor is awkward to use, and makes poor use of the screen space. There is no useful calendar view. The list of available frequencies is quite small. If you are a Grisbi user, you'll be able to create and work with basic scheduled transactions, but it will be harder than it needs to be.
As mentioned above, none of the packages reviewed here is able to perform any sort of future cash flow projection based on scheduled transactions. Another missing feature, found in some proprietary packages, is the ability to detect manual entry of (what appears to be) a regular transaction and offer to create a schedule; this is not a feature that all users will miss, however.
Both GnuCash and KMyMoney have nice utilities for dealing with loan payments. A series of dialogs collects the relevant information and sets up an appropriate scheduled transaction. GnuCash displays a repayment table when the loan is set up, but there appears to be no way to ever get that table back later on. GnuCash also neglects to initialize the loan account to the starting balance; the user must do that separately or the loan balance will not be properly accounted. Both packages can handle interest calculations and various add-on payments. Grisbi, instead, has no functionality for dealing with loans.
No modern personal finance manager would be complete without providing the ability to watch as one's money vanishes into the stock market. Both GnuCash and KMyMoney have investment tracking capabilities, with similar features. Grisbi, instead, lacks any sort of investment handling.
GnuCash and KMyMoney both treat stocks and mutual funds in a way similar to their treatment of currencies: they are commodities which, at any given time, can be exchanged for money at a particular price. Both of them can go to online sites to update their idea of what stocks and funds are worth, making it easy to get a snapshot of the value of a portfolio at any time.
The GnuCash way of dealing with stocks is borderline painful. The user must create a "commodity" entry describing the stock, providing information like the ticker symbol and where to get online updates. Then it becomes possible to create a new account associated with that stock. Only then can purchases and sales be entered. Sales are particularly obnoxious: one might think that entering the number of shares sold in the "sell" column would do the trick, but the Wrong Thing happens. One must, instead, enter a negative number of shares. It is not clear why there are separate columns, given this behavior.
KMyMoney is a little more straightforward, providing a set of dialogs which hold the user's hand through the process of setting up a new investment. The creation of individual accounts for each stock or fund is not required (or, at least, is hidden from the user). "Buy" and "sell" operations are easy to enter correctly. KMyMoney also has handling for brokerage fees; GnuCash can do the same through split transactions, but the user must take explicit action to make that happen.
KMyMoney has an explicit "dividend reinvest" operation, while GnuCash forces the user to figure out how to get the same effect via the register. GnuCash, instead, has an operation for dealing with stock splits. KMyMoney makes do with "add shares" and "remove shares" operations, which causes shares to arrive from (or disappear into) the void.
Both programs can generate reports showing the value of an investment portfolio and return over a period of time. Neither, however, can handle capital gains calculations - something that US users, at least, would appreciate. Neither program can plot the value of a portfolio over time. It does not appear to be possible to set up scheduled investment transactions in either program.
Your editor imported one year's worth of financial transactions into all three programs, and was able to make a couple of other observations. First of all, the size of the resulting files varied considerably:
Package File size (KB) GnuCash 1700 Grisbi 410 KMyMoney 54
The interesting thing is that all three packages use (different) XML-based file formats. KMyMoney compresses the file, however; when uncompressed, the file weighs in at 725KB. Grisbi gains its space savings by using a great many single-letter attributes.
The other observation is that KMyMoney is far slower to start up than the other two packages.
As mentioned in the first part of this report, GnuCash has a whole set of business-related features not found in the other two packages. These include a database of customers, vendors, and employees, and the ability to generate and track invoices. Job tracking is built in, and there is some capability for dealing with tax tables. The business features have a bit of an unfinished feel to them, however, and your editor suspects that very few businesses are actually using them.
GnuCash also has a poorly-maintained ability to operate with PostgreSQL as a back end. Sadly, this backend is unable to deal with business objects, making it unusable by the group which would be most likely to want that capability.
So which program would a grumpy editor recommend? One can start by eliminating Grisbi. This application has reached a level of functionality which, only a few years ago, would have placed it among the best available in the free software community. At this point, however, it lacks too much in the way of features, usability, and charm to be seriously considered by most users.
Among the other two, GnuCash still comes out on top with regard to both features and usability. Your editor hesitates to recommend GnuCash without reservation, however. One of the most important things to do when evaluating a free package is to come to a conclusion regarding the health of the development community. Unless you plan to take over maintenance and addition of new features yourself, it is nice to know that there is a strong community behind the software.
The GnuCash development community appears, from the outside, to be stuck in some sort of low point. The port to GNOME 2 has been ongoing for years, but there still is little idea of when it will be complete; as a result, distributors are considering dropping GnuCash because the pain of maintaining GNOME 1, now used almost exclusively by GnuCash, is getting to be too much. Discussion on the development mailing list is muted, and releases are increasingly scarce. GnuCash is at a bit of a crisis point. If its developers do not resolve the GNOME 2 issue and get development moving again in the near future, this outstanding application could be facing the end of its active life.
KMyMoney, instead, is on a roll. The development community is active and happy, features are being added at an impressive pace, and that 1.0 release appears to be getting closer. At current rates, it will be a matter of months, at most, before KMyMoney surpasses GnuCash in every area which matters to most users - and keeps on going. For this reason, along with the fact that KMyMoney 0.80 is nearly good enough already, your editor would have to recommend KMyMoney to anybody looking for a free personal finance manager at this time.
The Author's Guild describes it differently. To them, it's massive copyright infringement, pure and simple. The lawyers are trying to figure out who is right and which side is more likely to prevail, to the extent anyone can predict a fair use case, but there are bigger issues raised by this litigation. Here's the complaint [PDF] and Google's public statement in response. If you'd like to follow the lawyers' discussions, here are some places where you can do so: Susan Crawford's blog, William Patry's The Patry Copyright Blog, and Eric Goldman's Technology and Marketing Law Blog, and here's Andrew Raff's excellent collection of attorney reactions on IPTAblog. You might enjoy reading Tim O'Reilly's thoughtful take on the lawsuit, looking at it from a publisher's point of view.
What exactly is Google doing with Google Print? First, what *isn't* it doing? It isn't making copyrighted books available cover to cover against anyone's will. There are three parts to Google Print. One, Google makes books available in their entirety only when the books are in the public domain, like Project Gutenberg has done for years. Second, when publishers or authors agree, it makes sections available, the page the keyword appears on and a few pages on either side, but that is a separate facet of the project, the Google Print Publisher Program. The one the Author's Guild is fighting over is the third part, Google's Print Library Program, and for that Google will show only a few sentences on both sides of the keyword searched for, and not necessarily complete sentences. You never see a full page, let alone an entire book. You will also find bibliographic information and where you can find related information on the web. In all cases, you will also be directed to nearby libraries and bookstores where the book is available for purchase or loan, including second-hand bookstores for out-of-print books.
Screenshots of the three different offerings can be viewed here. And Google's Common Questions about the Google Print Library Project says that Google Print is "designed to help you discover books, not read them from start to finish. It's like going to a bookstore and browsing only with a Google twist."
On the Google side, the clearest arguments are presented by EFF's Jason Schultz, who explains the four fair use tests; Jonathan Band's paper, "The Google Print Library Project: A Copyright Analysis" [PDF]; and Susan Crawford on her blog, all of whom essentially say that copying entire books in order to make a digital keyword-based catalog is transformative and is fair use. Google isn't copying more than is necessary, they argue, because you can't search for keywords unless you have the whole book available. And anyway, where's the harm to the market? They cite the Kelly v. Arriba Soft case [PDF], in which the defendant made thumbnails of other people's photos available online in response to search requests, with links to the original works, if anyone wanted to purchase them. Arriba's use was ruled fair use, despite the fact that not only was an entire copy of the original made, a smaller version of it, in its entirety, was made available to the public. Google is only showing a sentence or two, not the entire book, for works where the author hasn't given approval to show more. If Arriba is fair use, why isn't Google Print's Library Project also?
If you wrote an article for a magazine and quoted a sentence or two, likely no one would complain, because it's so obviously fair use, so why is it a problem for Google to do the same thing with books? And what is the difference between Google collecting the world's content made available on the Internet so as to make it searchable and collecting keywords from the world's books? Copyright holders can opt out. If Google Print violates copyright law, why doesn't Google, period?
A common theme on both sides of the argument goes like this: Google has had a fantastic idea, one that can benefit the human race, and almost everyone hopes there is a way for them to do this. It's just a question of how to do it right. Google is shouldering the expense and effort of making a library card catalogue, so to speak, of the world's knowledge and offering it free to the world. Can anyone *not* want that to happen?
Authors should want to be included so they can be found. The world does its research now predominantly online, and authors, particularly authors whose works aren't selling like hot cakes, have everything to gain from being included in Google Print.
Author's Guild's Side
On the Author's Guild side is the argument that authors have the right to decide when others may or may not copy their works. This case differs from Google indexing the web's content, because a license can be inferred when someone puts content on the web and doesn't take steps to ban Google and other search engines with a robots.txt file. There is no equivalent implied permission from the authors of these books.
Copyright law gives copyright holders the right to make copies, period, and no one else can do so without permission. Libraries don't own the copyrights to these works, so they can't give permission, it is argued. Google will violate copyright law, no matter how little it shows the world, because it will make copies and store them on its servers. The onus is on Google to contact all the authors and publishers and get permissions, one by one, they say. If that is so onerous and costly that Google Print Library can't happen, so be it. The law is the law. This side cites the MP3 decision [PDF].
We might wish it could happen, some on that side say, but copyright law is what it is, so it can't. Some even predict that this litigation will shut down search engines like Google's. A few hope that happens. Some of the complaints about Google Print seem more emotional than based on fact. One comment on Boing Boing by a publisher is particularly interesting:
The second being Google will be profiting (through GoogleAds) on this content again without compensating the authors or publishers. Fair use should exclude commercial use. Even Creative Commons licenses (which I grant to my flikr account) gives you that option.
If we expect the production of good scholarship to be a viable, it has to be paid for somehow.
A little more accurate information may help calm these fears. First, fair use doesn't exclude commercial use. I can write a parody, for example, of your book, even if you don't want me to, and I can sell my parody. Second, take a look at the terms of the Google-University of Michigan agreement [PDF], which is available on the university's web site, and you will see that Google has bound the University, and any of its partners, to limitations on access and use. Further, should there ever be a dispute between an author and Google about including a work, the work can be removed by Google, and the University must then follow suit. Authors can always opt out.
What about the allegation that Google will make money from this project from ads? Google says there won't be any ads on the books scanned from a library. This is important, because the Complaint specifically alleges that Google will be profiting by ads: "4. Google has announced plans to reproduce the Works for use on its website in order to attract visitors to its web site and generate advertising revenue thereby." As for the links to bookstores, Google says that the links they will provide will not be "paid for by those sites, nor does Google or any library benefit if you buy something from one of these retailers." Clause 4.3 of the agreement says that the service will be provided "at no direct cost to end users".
While the Author's Guild makes much of Google allegedly profiting off of its members' work, a strong argument can be made that it's the other way around, since Google is providing a new way for readers to discover their members' books, even those on the deep, deep backlist, as you can see in this example.
Then there are some attorneys already pointing out flaws, procedural defects they believe they see in the Author's Guild complaint. It is supposedly a class action, but some see a problem with class certification. The complaint defines the class as all persons or entities that hold the copyright to a literary work that is contained in the library of the University of Michigan. Class action lawsuits are supposed to represent the group the few who are named allegedly represent, but Lawrence Solum, who is an author, a member of the plaintiff class in the sense that he has several works in the University of Michigan's library, opposes the lawsuit and says he will be harmed if the Author's Guild prevails:
Think about brick and mortar libraries. Suppose I were a librarian. I want to catalogue every book in my library and do it by keyword, so readers can come to the library and look up information by keywords on index cards that I laboriously file alphabetically in file cabinets. Each keyword will show you where in that library you can find a book that uses that keyword, with the page given, and additionally tells you where, in nearby bookstores, you can buy the book.
Would my painstaking work be a copyright offense? It's laughable to even think of it. Now, suppose I take all my index cards, and I laboriously hand type them into a computer. I have a computer database now, listing every keyword. Now have I violated copyright? Again, it doesn't pass the laugh test, does it?
But what if I realize that instead of the hand method, all I have to do is scan in the whole book and then pick out keywords by algorithm. Now am I a copyright infringer? If so, why? On the technicality that I had to scan in the whole book, thus making a copy, in order to break it down into keywords for my card catalogue of my library's contents? Purists for the law will say "Yes. You are an infringer," because you made a copy.
And they are right. You did. But exactly who is harmed by this scenario? The end result is exactly the same, whether I do the work by hand or by computer, except that Google deliberately limits how much I can see, whereas in the library, the keyword would lead me to the entire book, which presumably I could borrow, take home and scan or Xerox myself, if I don't care about copyright. If the copy merely stays on Google's servers, used only for making a digital card catalogue, in what way is the author or the publisher harmed? Have they lost any sales? Google isn't displaying the works in their entirety on its website, as the Author's Guild seems to imagine. It isn't selling the books or offering them for download. It is offering a tool to search books. Where is the harm to the market? Libraries have special rights under Copyright Law. Why shouldn't this project?
For those of us who are not lawyers, our dominant reaction to this lawsuit is probably that if Google Print Library violates copyright law, somebody needs to change the law. This litigation raises some important questions: What is a library in the digital age? What is a book? Is Google Print going to do away with books as containers of knowledge, replaced by searchable databases? What about this litigation's effect on copyright law in the US? Is it possible, as one comment on the Conglomerate blog suggests, that if it wins, "Google may be planting the seeds of the destruction of copyright as we know it"?
Computers are, under current law, the ultimate infringers, in the sense that you can't read anything on a computer without making a copy in RAM. There is, in short, no way to avoid making a copy, if you access at all. It's the gotcha of copyright law in the digital age, and at some point, some say, we need to think about that issue and decide what to do about it. If you want the hairs on your head to stand straight up, note the lack of comprehension of the tech involved in using a computer by reading the MAI SYSTEMS CORP. v. PEAK COMPUTER, INC., 991 F.2d 511 (9th Cir. 1993) decision: "After reviewing the record, we find no specific facts . . . which indicate that the copy created in the RAM is not fixed."
Susan Crawford explains:
Ernest Miller and Joan Feigenbaum, in their very interesting paper "Taking the Copy out of Copyright" [PDF], suggest that we drop the copy from copyright law and focus on distribution instead. After all, it's distribution that harms authors and publishers, not copies on a Google server no one can see or access but Google.
We watched Napster get hogtied, killed, cremated and scattered to the winds, and most of us were sad that the law was trying to snuff out a great new idea because the courts seemed not to grasp the tech and the real potential for businesses founded on this new technology. But the world's books? Should the law block a new way to research and find books on any topic any human has ever written about, broken down and searchable by keyword, a way to to find specific books by keyword in the finest libraries in the world, without having to travel there physically?
Larry Lessig puts it like this:
The Author's Guild has only 8,000 members. I say "only" because Groklaw has more members than that. The value to the public of Google's Print Library collection so far outweighs the value of one book to one author or even 8,000 books to 8,000 authors, that it is hard to comprehend how any law could be permitted that could allow such a result as shutting down Google on the demand of those 8,000 authors.
Copyright law is designed to protect authors, yes, but it is supposed to do so in a balance with the public good. Copyright law's purpose is to further the public good by promoting more works of authorship, so as to make knowledge available. When did that part of the law's purpose get forgotten? Protecting authors' rights is a means to the end of making knowledge more freely available, which is exactly what Google is trying to do. If the Author's Guild succeeds in blocking this project, it will have managed to turn copyright into a means for restricting the spread of ideas and reducing the public good.
LWN currently just over 3100 active subscribers; approximately 1000 more read LWN by way of group subscriptions. We are pleased that Red Hat Inc. has recently signed up as a corporate subscriber, as have a few other, smaller groups. This subscription level is nice to have, but it is very similar to what we had last year - especially on the individual side. For the time being, at least, our subscriber level is essentially flat.
Money from subscriptions goes to pay three full-time editors, one very part-time bookkeeper, health insurance, travel costs, bandwidth, computers, lawyers (not too often, fortunately), credit card processing fees, and all the other incidental costs of running a business. LWN currently pays for no office space, and plans for the procurement of a corporate yacht remain stalled (which is just as well, considering that a yacht is of limited use in Colorado). We are pleased that Rackspace.com continues to donate bandwidth for the main server, that TrustCommerce covers their part of our credit card fees, and that various sponsors have made it possible for LWN staff to attend conferences and meetings in distant parts of the world.
The end result, however, is that the current subscription level is not sufficient for sustainable operation even with the current staff. And LWN in its current form will not be truly sustainable without at least one additional staff member. So we must find a way to bring in more revenue to fund that staff member, raise our payments for outside authors to a more competitive level, attend (and report on) important free software events, deal with the long list of site improvement ideas, broaden our coverage, cope with the next inevitable horrifying health insurance cost increase, and, just maybe, give a long-delayed raise to the current staff. That might just make the grumpy editor feel a little better about the world.
We have a long list of ideas on how we might bring about that increase. Most of them are oriented toward making LWN a more valuable resource and trying to actively sell LWN subscriptions. One short-term idea (which we would like feedback on) is increasing the lockout time on subscription-only content to two weeks, or possibly more. We value our free readers, and we live for those "I finally decided to subscribe" notes, but we also have to strike a balance which respects those who are actually paying for LWN's existence. In the longer term, we may seek some sort of financing to help grow LWN into a truly sustainable business.
One thing we do not intend to change is our commitment to providing the net's most comprehensive, accurate, and well-written coverage of the Linux and free software development communities. That is what LWN set out to do back in 1997, and we've never seen any reason to try for anything else. The years in between have been a wild ride, with amazing ups and downs. But, during that time, Linux has gotten stronger, and we have built up the best group of readers we could have hoped for. We expect that the coming years will be just as interesting - and just as successful.
Page editor: Jonathan Corbet
Next page: Security>>
Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds