Leading items

Heartbleed aftermath

By many accounts, the "Heartbleed" vulnerability in OpenSSL was one of the worst security-related bugs seen in years. The actual cost of this vulnerability will take some time to work out, though; rumors of long-time exploitation by the intelligence community notwithstanding, there is not much hard evidence of real-world compromises enabled by this bug. In truth, the nature of the bug makes such evidence hard to come by, and, in any case, the cost of updating much of the Internet, changing passwords, and replacing keys will be certainly be high. While the full picture emerges in the long term, we can profitably look at a few interesting themes that have already become apparent.

Resources

One commonly heard assertion is that the OpenSSL project simply does not have the resources needed to maintain a code base of that size (about 300,000 lines of code), complexity, and importance. Companies take OpenSSL for granted, it is said; they make vast amounts of money using it, but do not contribute back to its development. Steve Marquess, the OpenSSL "money guy," put it this way:

There may be value in asking, though, whether support levels are the real problem and, if so, what form the solution would take. There are calls for users and companies to donate to the project, but nobody seems to be pointing out one simple fact: it is a rare development project indeed that operates out of cash donations. It just does not seem to be a sustainable way to keep developers employed working on a project. Companies don't donate cash to OpenSSL because, almost without exception, they do not donate to free software projects at all.

That does not mean that resources are not available for OpenSSL development, though. It is interesting to continue reading in Steve's posting on the subject. The OpenSSL Software Foundation offers consulting services starting at $250/hour. Those rates are apparently not high enough to put off clients:

Given that, one might reasonably conclude that the limiting resource is not money, it's qualified developers. That is a different sort of problem.

Coming up with more qualified developers is not something that will happen overnight. Cryptographic programming is not easy, and the TLS protocols are seemingly not designed to make it any easier. If companies are waiting with contracts in hand for qualified developers to just show up, they may find themselves waiting in vain while the quality of the software continues to suffer. Perhaps there is a better way.

Projects that have large numbers of commercially supported developers are typically not employing those developers through a donation-supported foundation. Instead, those developers are employed directly by the companies that have an interest in the development of the software. In the most successful settings, these companies have in-house programs to bring developers up to speed on the projects they care about the most. That is the sort of support that projects like OpenSSL need; the companies that depend on it need to be directly employing (and training) developers to get this work done. Once that happens, OpenSSL should improve quickly.

The perils of closed enhancements

One of the companies that arguably should be employing OpenSSL developers is Akamai, which uses OpenSSL heavily on its massive content distribution network. On April 11, Akamai proudly told the world that it could not have lost SSL keys via the Heartbleed vulnerability, despite having run vulnerable versions of the software. Why?

The reasoning was that this secure heap, being kept far away from normal working memory, could not be exposed via Heartbleed. Akamai kept this code to itself; it was not contributed back upstream to the OpenSSL project. Or, at least, it was not contributed until Akamai posted it on April 11.

It took less than two days for an independent reviewer to look over the code and conclude that, in fact, it was buggy and offered no protection at all. By late on April 13, Akamai had conceded the point and begun the process of changing out all customer SSL keys. The company deserves credit for facing up to its problems once they were pointed out, but it can't have been Akamai's proudest moment.

Akamai, it seems, had been using its custom allocator for many years. Had that code been contributed upstream, there is a good chance that the bug would have been found a long time ago. Akamai would have benefited with secure code that was actually secure and the damage to the net as a whole caused by the Heartbleed vulnerability would have been considerably reduced. There really is value in this whole open-source development idea, but it seems that this lesson has to be learned the hard way over and over again.

End notes

There does seem to be one influx of new developer effort, though: the OpenBSD project has apparently decided to rip the code apart and clean it up to its standards. The result seems likely to be a cleaner and more secure OpenSSL in OpenBSD, but there is no evidence of any sort of coordination or communication with the OpenSSL project or of any intent to push these changes back upstream. In other words, it seems likely that OpenBSD has just forked OpenSSL. This move may allow some immediate problems to be addressed but, in the long term, this project (which, like most projects, has resource constraints of its own) has just taken on the maintenance of a complex, security-critical body of code. The cost of that decision will have to be paid continuously into the indefinite future.

Finally, we have had a few queries about LWN's server. As LWN readers know, we are strong proponents of running the latest and greatest software with all the newest fixes and features. That is why the main LWN server is running on CentOS 5. First impressions notwithstanding, this version of CentOS does not actually predate the World Wide Web, but it is old enough to have never had a vulnerable version of OpenSSL, so LWN's servers were not vulnerable to Heartbleed for even small period of time. The company that does LWN's credit card processing (Braintree) was vulnerable, but responded quickly once the vulnerability was disclosed. PayPal, our other payment provider, claims to have never been vulnerable but says nothing about why that is true.

In summary: there should be no need to change LWN passwords or to worry about payments made for LWN subscriptions.

The Heartbleed vulnerability is a reminder that there are classes of bugs that can affect a substantial portion of the Internet. Heartbleed may or may not have been extensively exploited against people on the net, but, in a sense, it almost does not matter. The chances that other vulnerabilities exist and are known to hostile entities would appear to be quite high. Free software may well offer the best defenses we have against security problems, but it is clear that those defenses are nowhere near as strong as they need to be. For years we have been telling the world that it can rely on our software; now that the world is, to a great extent, convinced of that fact, we need to accept the responsibility to make sure that this claim is actually true.

Comments (52 posted)

Internet and communities

John Perry Barlow has done a lot of diverse things in his life. In the free-software world, he is probably best known for co-founding the Electronic Frontier Foundation (EFF), but others will know him best as a lyricist for the Grateful Dead. Along the way, he was a cattle rancher in Wyoming for twenty years. All of those experiences shaped him, clearly; he came to PyCon 2014 in Montréal, Canada to impart some of what he has learned over the years in a somewhat rambling, but amusing—and ultimately fascinating—keynote.

Internet uncle

He confessed at the outset that he is now an "elder of the internet"; an "internet uncle". That is strange to him, since he spent most of his life trying to continue to be an adolescent; "being an elder is something of a drag". But there are advantages to being an elder and an adolescent, he said, "you still have the desire to do crazy shit, but you know what crazy shit is likely to fail badly".

He popularized the term "cyberspace"—coined by William Gibson—to refer to the internet. When he found cyberspace in 1985, there was already a recognizable culture there that a had a certain flavor. He immediately thought it might be a new substrate for communities to form in. It reminded him, in some ways, of the small town in Wyoming where he grew up. There was a sense of shared adversity and a "real density" to the relationships shared that was similar in the town and in cyberspace.

Much of that small-town culture was being supplanted by "television-land and suburbia". There was a rise of corporate working environments where there was a great deal of pressure for individuals to pretend to be like all of the other employees so that the company could treat them as individual cogs in the machine. The impetus for privacy was so that the company couldn't figure out that, like everyone else, you were "weird as hell".

Everybody is weird, he said. If you examine them on the inside, everyone is unusual. He is the one who talks to you throughout an airplane flight, he said, which "some of you hate". But he does it to prove to people that they are more interesting than they think they are, he said with a laugh.

Spreading the internet

He became convinced that the right way to fight this attack on small-town (and other) cultures was to spread the internet everywhere, so that everyone had access to it. Now we see that it is not just everyone, but everything that will have access to the internet. He thought that outcome would be a "slam dunk", but, then, he also believed that the "Age of Aquarius" was a slam dunk too. "So I was already prepared for disappointment", he said, with another of the laughs that permeated the keynote.

The internet was about "connection, not separation", it was about conversation, rather than the channel, which stands in stark contrast to broadcast media. The media companies are about "content", which is a "code word" used by those companies to claim ownership of all human expression. The internet has the potential to give a voice to everyone, which in many cases "will be a terrible idea". Just because everyone has a voice, does not mean that everyone else has to listen to it.

He thought that the internet and its culture would just "kind of slide in, invisibly" into the void left once the nation-states realized they had nothing left to do after the cold war was over. "I underestimated them". He also underestimated the three monotheistic world religions which were threatened by the internet. When the "word" does not need to be filtered through a book or document that is "absolutely, positively right", it "plays hell" with church authority.

He knew that the record business was one of the ugliest industries out there, but he was still surprised that it would rather kill itself and everybody in it, rather "than do something that was wise and decent". He has spent many years trying to explain to that industry that it is not in its interest to "make expression scarce". There is a huge difference between an information economy and one of hard goods.

Adam Smith was right about scarcity and goods, but it is completely different with expression and information, he said. In the latter case, familiarity is important, while scarcity really is not. If he has the largest diamond in the world in his pocket, it is still valuable even though no one knows it is there. But he can have the best song ever in his head, and it has no value unless it is shared with others. It then gathers value slowly, dependent on how many people can sing along.

Lessons from the Grateful Dead

The band that he wrote for discovered this value proposition accidentally. It invented viral marketing without really meaning to. It was a very improvisational organization, "LSD will do that", he said with a grin, "it doesn't give you a lot of choice". The band noticed that people were taping their concerts, and the record company said they needed to stop that because the fans were "stealing something from them". But the band had a hard time understanding what was being stolen—it had no intention of ever playing the same show twice. It didn't seem likely that people would not buy the records because there were these tapes of the show. It also didn't seem right to be mean to Deadheads, who are, he said, "a hapless bunch".

So the band allowed people to tape their concerts. Those tapes became an "unbelievably effective" way to spread the word about the band's music. By the time the band died, though maybe it hasn't yet as it still "clings to weird life", it could fill any stadium in the US (and perhaps the world) without ever having a hit record, based on the fact that all of their tapes had been big hits. "And the fact that we could haul our audience around with us", Barlow said.

The community of Deadheads and the aspect of sharing within that community reminds him, in some ways, of the Pythonista community. There have been cultures associated with languages before ("French is a good example", he said to audience laughter), but there is always the question of who has the authority role. At one point he mentioned to EFF co-founder Mitch Kapor that the internet was finally an example of a "working anarchy". Kapor, though, noted that underneath any working anarchy is an "old boy network". That is probably true with the Python community too, though he hopes and believes that we are starting to see the emergence of a "young girl network" instead. Kapor also said that there is often a "benevolent dictator" role in a working anarchy as well, and Python certainly has that.

In the early days of the internet, there were sometimes cultures associated with programming languages, but they were typically small and "often cult-like". TeX and Lisp were two that he mentioned (the Lisp people would sometimes "go a little nuts on you"). There was also the Unix/C culture, where everyone "looked like Dennis Ritchie". Python is different; it is "young and stylish", more engaged with the world as whole than "the Unix weenies ever dreamed of being". Barlow has attended Unix gatherings, where attendees thought they were being social if "they were looking at your shoes" instead of their own, he said with a chuckle. PyCon has a "completely different flavor".

Governments and rights

He was wrong about what the industrialized nations' governments would do after the cold war. Instead of folding up their tents, those governments are imposing all of the surveillance and control mechanisms that didn't work in the physical world onto cyberspace. He takes some solace in the fact that those governments evidently can't stop his almost daily talks with Edward Snowden. Or maybe they just want to listen in because it is more amusing than what they are thinking about.

As the infrastructure gets taken over by companies like Comcast, which has no "Bill of Rights", or meta-organizations and forums like the International Telecommunication Union (ITU) (though Barlow mistakenly called it "ITT"—he also called it "a dreadful artifact of horror"), there is no redress of grievances available through the courts, there is only "cultural redress" available to combat abuses. That is done by spreading the culture of openness, sharing, curiosity, and human service into the foundations of what will become the next generation of cyberspace.

Barlow said that he dreams of a day ("it's not a crazy dream") when anyone on the planet can find out everything we know about a certain subject, regardless of where they live. It is a dream of a "right to know" that is (or should be) a natural human right, and should extend to every being on the planet. There is a right to know what governments are doing, as well as how and why they are doing it. For that to come true, it relies "on people like you" who are building the plumbing, he said.

Around the time of the founding of EFF, he was expressing dismay that the US Bill of Rights is really a set of local ordinances. They can only be enforced in a place where the enforcer also has the ability to take them away. Rights are not something that you can depend on any government to extend to its subjects, those rights have to be embodied in the technical architecture of the internet. Those attending PyCon and "people like you" are the ones who can define that technical architecture to make sure that his dream comes true. That way, we "will end up being extremely good ancestors after all".

Q&A

That ended the keynote, but Barlow then took questions from the audience. They ranged widely, and he often answered at length. Some of the more interesting exchanges covered things like privacy as well as his suggestions for what Pythonistas and the wider community can do in the coming years.

Barlow grew up in a small town where no one had any privacy. There was a "mutually assured destructive capacity", though, because everyone knew where the bodies were buried, so it was "best to not start digging". Our reasons for wanting privacy are bad, he said. We fear the judgment of agencies who should not be making judgments over our personal lives.

On the other side of the coin, the secret services want secrecy partly to disguise their "complete incompetence". It is important to let the light shine in on their activities. He helped found an organization (the Freedom of the Press Foundation) that is working to protect people who find themselves in the same position as Snowden. That organization will try to make sure that what whistleblowers have to say can get said, and to protect the people that say them. It is also working on easy-to-use crypto tools for journalists.

Currently, the work on open-source tools for helping journalists resides "in the vicinity of Tor and its many manifestations". There are already lots of Tor packets on the internet, he said, which routinely make some traffic less visible. The EFF's HTTPS Everywhere initiative also helps keep traffic encrypted, or "did until recently", he said referring to the Heartbleed vulnerability.

For the Python community, Barlow suggested that it keep "doing what you appear to be doing". He suggested that it "resist ideology", but "encourage belief". There is a fine line between the two, but ideology is in the head and belief is in the heart. Try not to impose opinions on people, and try to get consensus to work for most decisions. There will be politics, of course; that's "life among the humans", but from what he has seen, the Python community is "not political by the standards I have become accustomed to".

Barlow was asked how he reconciled the idea of the "right to know" with the collection of enormous amounts of surveillance data by governments; does it just come down to a "good vs. evil" question? He said that he has consulted with the NSA and CIA for more than twenty years. There are constituencies within those organizations that want to figure out what the "truth" is so that the decision-makers have the right information to base their decisions upon. He said that he would really like to put Mike Hayden (former Director of both the NSA and CIA) together with Snowden. He likes them both and thinks that he might be able broker a truce (or at least a conversation) between them, he said with a laugh.

In the end, the more data that "evil" has, the better off we are. It is looking for needles in haystacks, and when you do that, you don't want to increase the size of the haystack exponentially. Instead, you want a better magnet. The security agencies don't know the difference between data and information, which means we are "spared their despotism by their incompetence", he said.

While he is not a fan of government, in general, he is in favor of "some government". He would like to see a government that ensures kids don't starve at school and one where people don't have to produce some kind of medical card before they can get care. He is for localizing government to the extent possible, perhaps to the level of the city-state. That is the level of government that "seems to work", and the one that works well with cyberspace, he said. It would be great to see a renaissance of the city-state, the likes of which we haven't seen since the Renaissance.

A video of the keynote is available at pyvideo.org. Videos of many of the other PyCon sessions, perhaps all of them, are at the site as well.

Comments (3 posted)

Trademarks for open collaboration

A panel session with four lawyers may not sound like it would make the best choice for sitting in on at the 2014 Linux Foundation Collaboration Summit, but it turned out to be one of the more interesting sessions I attended. Luis Villa, Yana Welinder, Pam Chestek, and Karen Copenhaver talked about trademarks, and specifically how they can be applied to open-source projects. All were coming at it from a practical perspective, with Villa and Welinder having just helped lead the Wikipedia community in defining a trademark policy, Chestek has designed a kind of boilerplate trademark policy that projects can use as a jumping off point for one of their own, while Copenhaver deals with trademarks frequently as part of her work as the Linux Foundation's counsel.

Villa is the chair of the licensing committee for the Open Source Initiative (OSI) as well as a general counsel for the Wikimedia Foundation. Welinder is also a legal counsel for Wikimedia. Chestek is a former Red Hat counsel, now in her own practice. As noted, Copenhaver is the general counsel for the Linux Foundation.

Background

The background was set by Villa, who said he would be explaining why trademark issues are interesting for lawyers, but painful for everyone else. The purpose of trademarks is fairly straightforward, but it runs directly counter to the ideas behind open source in some ways. Trademarks are all about controlling the quality of something by only allowing a name to be attached to it under certain conditions. But in the open-source world, users and others must be able to modify the software, so the trademark holder is going to have to give up some level of control.

A trademark is meant to tell consumers that there is one entity behind the product, for example only a single manufacturer that makes the good. But in open source, lots of people participate. For example, no one really controls "Linux", and there are various flavors of Linux available (e.g. Red Hat Linux or SUSE Linux).

It is this right to modify versus the requirement to control that causes problems for free-software projects with regard to trademarks, Villa said. For example, the Firefox trademark was being used to sell modified versions of the browser with adware and sometimes malware. Mozilla's efforts to stop those kinds of abuses caused problems for Linux distributions that wanted to modify Firefox in various ways (e.g. replace the file chooser with a native version). One more thing to keep in mind, Villa said, is that there is a difference between using a trademark to reference a product and using it to sell a product.

Because members of open-source communities often identify themselves using the trademarks (e.g. "I am Linux/GNOME/Wikipedia"), any kind of discussion of trademark "control" can get heated. It can feel like the lawyers are trying to wrest the community member's identity away from them. There are examples of that in nearly every open-source community that has grappled with trademarks, he said.

Wikipedia

With that, Villa turned things over to Welinder, who suggested that one way to solve this tension between the community and the legal side was through collaboration on the policy itself. If the community comes together to create a trademark policy for itself, it will not be an imposed policy but one that came about through agreement. Also, by getting as many eyes as possible on the drafts, bugs can be identified early on in the process, she said.

So, Wikipedia invited its entire community to help determine the policy for using the trademarks held by the Wikimedia Foundation. It took seven months and around 150 community members participated in the process. The first thing learned was that the community had no idea what was in the old (then, current) policy. It was a "wall of text" that was difficult to understand.

So the first step was to break up that wall and make the policy easier to understand. It took legal design, of course, but also usability design to do that. A summary of the policy in a one-page document was an important piece. It told users what they could do with the trademarks ("yes"), what they could do under certain circumstances by following some simple steps ("yes, but first"), and things that are not allowed ("sorry, no").

Beyond just the summary, other usability upgrades included some newly designed icons to help navigate the policy. In addition, interns went through the text to find overly long or complex sentences to target for simplification. Because it was a community document, it couldn't have things hidden in small print, which is something that lawyers often like to do, she said.

Areas that were unlikely to cause consumer confusion (cupcakes with the Wikipedia logo at a hackfest, for example) were explicitly allowed. For other uses, they designed a new trademark license that is short and simple. People just fill it out and send it in; they don't need to wait for permission or approval before using the marks. It makes trademark licensing much more streamlined, she said.

Model trademark guidelines

Chestek was next up. She has dealt with lots of projects that didn't have a trademark policy and realized that there isn't a common understanding about trademarks among FOSS projects. She was concerned that the legal industry would start defining those policies for projects, with potentially "disastrous outcomes" because FOSS is so unusual to courts and lawyers.

So, she has come up with the Model Trademark Guidelines as a tool for projects to use to come up with their own policy. Projects using it will, hopefully, "give the courts a push" in the direction that the FOSS community would like them to go.

To come up with the guidelines, Chestek looked at 30 to 40 projects' trademark policies. The referential (or nominative) use of trademarks was not generally an issue for projects. Many of the policies were concerned with other uses that would require a license or permission, in particular distributing modified versions of the software. So that is what she concentrated on in the model guidelines.

The guidelines are freely modifiable, she said, and are ready to be used by projects if they wish. CentOS is using them currently and is the only project to do so as of yet.

She pointed to the "Uses we consider non-infringing" section as an area that is unique to FOSS projects. The section outlines various uses that FOSS projects typically find to be reasonable, without requiring a license or permission. They represent kind of a "safe harbor" for users. It is not a settled area of the law, so the idea is to recognize these uses up front, so that a court would not determine that a potentially infringing use of the mark had been ignored. Trademark owners are required to take action when their marks are misused, so that section tries to set a boundary both for the users and so that the courts recognize certain uses are not being ignored, but are, instead, explicitly allowed.

A common activity with FOSS is one that gives lawyers fits: allowing distribution of the covered software under the mark after modifications have been made. In the proprietary world, lawyers hate trying to create licenses to allow that kind of behavior and the result is a thick stack of legalese. Should a trademark issue end up in court, it should be clear that the agreement requires a certain level of quality control over the modifications, but that doesn't fit too well with some open-source projects.

There are some existing FOSS project policies that address this. For example, the LibreOffice policy allows changing the "skin" of the office suite while still calling it LibreOffice. There may be other kinds of similar requirements that show the project is exercising a level of quality control over its downstreams. There is still some concern that the courts won't agree with that approach, but it is the line she tries to walk in the model. "Hey, I don't know who you are, but you're making my product" is a statement that is "stomach-churning" for lawyers, she said.

In the end, the guidelines reflect her opinion on various matters as she is the author of it and most of the commentary and legal background pages that go along with it. For example, she believes that unmodified distribution of the software by others does not require a license to use the trademarks, but others may disagree. The site is a wiki, and she is quite interested in contributions, particularly from lawyers in non-US jurisdictions.

Summing up

Copenhaver then summed things up by saying that trademarks are going to become more important in the open-source world over time. There are more corporate-run projects whose owners want them to become open-source projects; trademarks are going to cause the most heartburn. Having thoughtful policies about trademarks will show the companies that we are speaking their language, that our policies show a more reasonable approach to trademarks in our space.

Trademarks are one of a project's most valuable assets, she said. They govern how the project is perceived in the world. But trademarks also give a project a way to enforce certain standards. For example, there were multiple companies offering Firefox "licenses" for $200, she said, and the only way that Mozilla could deal with that was via its trademark.

It will be important to courts to see that projects honor the requirements of trademark law because registering a trademark means that one must take on certain responsibilities. One of those is to enforce the trademark against those who are infringing on it; if you don't do that, you can't enforce it against anyone. By defining what we consider to be infringing uses, as Chestek has done, it gives the courts a model to follow.

The law always lags technology by 20-25 years, she said. It took 27 years to test the shrink-wrap license issue, but the industry functioned just fine in that time. Judges tend to honor the way things have been done, so if open-source projects have a general framework for how they handle trademarks, they will be in a better position than if projects are "all over the map" with respect to trademarks.

Q & A

All four then sat down, "panel style", to answer audience questions. As part of that, the idea of a FAQ to accompany a project's trademark policy came up. Most were in favor of creating a document like that to help inform the good players (as the bad players are unlikely to read, or heed, any document), but there were some caveats. Villa noted that FAQs (and accompanying documents, in general) tend to make lawyers uncomfortable since they aren't a part of the legal document. But Copenhaver said that a FAQ can provide good evidence of what the project considers "bad actors", which is most of what the trademark policies are meant to combat.

Enforcement was another topic. Copenhaver often deals with companies turning over trademarks to newly formed open-source projects, and they often expect that the level of enforcement of those trademarks will be high. But enforcement costs a lot of money and could easily eat the entire budget the company is allocating to the project. So, unless the company is willing to write an unlimited check, she recommends that a low, but consistent, level of enforcement be chosen. Inconsistency in enforcement is problematic, as is saying one thing about the mark, but doing something else. For example, many projects will look up all of the domain names related to the trademarks and want to start going after each infringer, but that can be incredibly expensive and swallow up the entire enforcement budget.

Villa said that he is not convinced that the case law for trademarks is as settled as is often portrayed, though other lawyers have literally suggested he be debarred for making such a heretical statement. Chestek agreed with Villa—"I have your back". She said that the trademark rulings that exist come out of the "single manufacturer model" that doesn't take the new collaborative approach into account. So far, the courts just haven't caught up with that change.

The least amount of policing that a trademark holder can get away with was the final question to the panel. Welinder said that identifying truly harmful uses and policing those should be enough. The project's policy should reflect the level of enforcement that it is willing to do, Copenhaver said; as long as it does what the policy says right from the beginning, not three years down the road, all should be well.

That led to some discussion of what happens when enforcement hasn't been done for some period of time. Chestek said that the holder needs to reestablish its rights, or switch away to a new brand. Given that rebranding is expensive, Villa said, it probably makes sense to "get back on the horse" and move forward with reestablishment. Chestek noted that when a trademark is lost, the most common cause is that the owner has caused the problem by genericizing the term, so projects should strive to avoid that.

Trademarks are tricky and sessions about the intersection of trademarks and free software are usually fairly interesting—this one was no exception. It is clear that there is quite a bit of thinking going on in the FOSS trademark space right now, so it was nice to see a status report on that work.

[ Thanks to the Linux Foundation for supporting my travel to the Collaboration Summit. ]

Comments (2 posted)

A note from your editor

If there is one thing that I have learned in my existence so far, it's that life brings no end of surprises, some of which are pleasant, others of which are distinctly less so. At the bottom end of that scale is where I would place a cancer diagnosis. But, I am sad to inform LWN readers, that is exactly what life brought me at the end of February.

The good news is that my condition, while serious, still has a good probability of being curable. Things were caught at a stage where, with a bit of luck, the disease can be evicted from my body and, eventually, this whole episode will fade into a bad memory.

The bad news is that getting there is not going to be a great deal of fun. Cancer treatment turns the body into a battleground, and, regardless of who wins, battlegrounds always suffer. My treatment has been underway for a couple of weeks now, and will continue, in various phases, through the end of the year. I am doing OK so far, but I expect that there will be periods where I will not be in a condition to figure out and explain the details of a complex kernel patch or community political situation.

It is very much my intent to continue to inflict my insights, opinions, and bad humor on LWN readers over the course of this treatment regime. But there will certainly be times when I'll have to cut back or drop out entirely. The rest of the LWN crew will continue to work to make LWN the best Linux and free software resource on the net, and they will certainly do a fine job of it. But please cut them a break if an occasional edition comes out a bit thinner than usual; they will have a lot on their plates.

Needless to say, my presence at conferences will be somewhat reduced for a while as well.

Happily, it is possible to gain access to top-quality medical care in the United States if one pays attention and is well insured. My previous experiences with the medical system have had the effect of causing both of those conditions to be met in this case. In the absence of ugly surprises (always a possibility in the system here, alas), the stress of dealing with this situation should not be accompanied by undue financial stress.

If there is a lesson in this situation (beyond paying attention to your insurance if you live in a part of the world where that is necessary), it is that we all need to pay attention to the health of our bodies and to keep up on our biological maintenance. As a community we are getting older, and any "biological debt" that we allow to accumulate will indeed catch up with us eventually. Step away from the keyboard and get outdoors, eat your vegetables, keep up with your health screenings, etc.

Should anybody wish to help, a good starting place would be to not ask for details on my condition or treatment plans; I do not intend to discuss such things in public spaces. For those of you who have ever thought about writing up some interesting work for LWN, this year might be a good time to put together an article — but please look at our author guide and talk to us before getting into the actual writing. We would also still like to hire another editor someday, especially if we can find somebody who can write about kernel topics. But, for the most part, the best help I can get is quiet support and understanding.

Many thanks are due to the (few) people in the community who already knew about this and have offered their support. More thanks to every LWN subscriber; it's you who, among many other things, allow us to pay the company's insurance bill every month. I am pleased and proud to be a member of this community — and I plan to continue that way for a long time yet.

Comments (126 posted)