Jason Wacha is our corporate counsel and in house GPL licensing expert. If you’ve never heard him speak you ought to go register and listen to one of his recorded webinars. He will frequently exclaim that “software is software” in an attempt to get the audience to realize that the licensing and intellectual property issues faced by teams using open source licensed software are the same as those facing proprietary.

Our friends at Red Hat have shown themselves, again, to be fans of not just open source licensed code to fuel their products but of community developers as well. Red Hat had been sued for patent infringement by Firestar Software for patents related to their JBoss products. Rather than just do the customary pay-off or cross license deal Red Hat did something different. They settled in a way that covered downstream users of JBoss (their customers) and the upstream developers of JBoss. The settlement also covered people making derivative works of JBoss even if they aren’t Red Hat.

I’m just an engineer… but this seems to be a very unusual settlement. Firestar and Red Hat settled out of court as often happens. Rather than just making their peace Red Hat extracted what seems to be quite broad protection for many other developers and companies other than Red Hat. It can only be hoped that this sets a chilling precedent for those who would wish to pursue alleged patent infringement against open source companies an open source projects.

With respect to Red Hat: Bravo!

I just flew into our Santa Clara, CA office today. I’m a band geek… I played trombone, marched in high school, and marched for two years with the Georgia Tech Yellow Jacket Marching Band. Lots of fun!

I learned a lot in band and was reminded of it when I arrived at our corporate offices in Santa Clara, CA. Since school is out now there are teams of devoted musicians who are participate in drum and bugle corp competitions all around the US. One of the best known and elite corps, the Santa Clara Vanguard, practices in a parking lot about a 3 minute walk from the office. If you’ve ever heard a corp play in competition you’ll always know the distinctive sound when you here it. Listening to a corp is an experience your entire body participates in… not just your ears. It is that powerful.

One of the most important lessons I learned from marching was that even the most simple of tasks is profoundly complicated if you are trying to get a lot of people to do it together. We’d line up 20 high school band students, count down from three, and expect each of them to take one measured step with their left foot. This simple exercise could take an hour to get right. Double the number of people and it would likely take 4 times as long to get it right.

Mark Shuttleworth (Ubuntu’s BDFL) recently called for cooperation and release synchronicity in a recent blog post. His main argument was that if various major distributions agreed on a major release schedule that their efforts within the upstream communities could be coordinated. The distributions could also agree on a kernel, gcc, glibc, and major library versions to unify around and thus make life easier for ISV’s. Interesting idea… very user focused as one would expect from Mark.

There are competitive angles on this, of course. Ubuntu is probably 3rd or 4th place in server adoption behind Red Hat and Suse. That’s a cold place to be. Large ISV’s don’t really care beyond #1 and #2 unless they’ve got a key customer that wants you. Red Hat, of course, doesn’t see this as a problem that needs solving.

Synchronicity is also a challenge not only between Linux distributions but within a given Linux distribution. It is incredibly challenging to align the hundreds of community backed components that constitute a typical Linux distribution and get them to all be ready to provide to customers at the same time. This truth has often been misinterpreted as a criticism that these community projects are not suitable for production usage. That is not true… what is true is that there aren’t all suitable for production usage at the same time. Getting all of these components to take one measured step, with the same foot, in the same direction, at the same time is a profoundly non-trivial challenge.

Getting this to work between companies might be too much to expect without a massive groundswell of user and customer demand that would be needed to focus everyone’s attention. It is not clear to me that this demand is there.

Brad

A short thought about the nature of communities and freedom has been bouncing around my head. Back in 2003 my wife and I took a few days to visit Boston. I’d made many trips there for work but typically only saw Logan airport and the ‘burbs. Boston has a lot more to offer than office parks.

We did the typical history walk through the city. Outside the Massachusetts State House is a statue of Mary Dyer who is remembered a Puritan turned Quaker who was hung for violating colonial law banning Quakers.

The sad irony in all of this is that the Puritan colony of Massachusetts was ostensibly started to preserve religious freedom. This sanctuary, however, seemingly applied only to Puritans and not to those of other faiths.

This was just a lesson to me that freedom for one class does not at all imply a respect of freedom for all or for all purposes. Tag that under “valuable_life_lesson”.

Remember this when evaluating open source communities. There is often a shared ethic of Free Software but sometimes that is all that is in common from one community to the next. One community might be open to new developers or alternate ideas and implementations. Others are relatively closed. Unlike denial of religious freedom, however, it is not possible to simply declare that all suppression of a community member’s freedom is repressive.

First of all… the right to modify a community codebase is not an expected freedom under any Free or Open Source software license that I’m aware of. Membership and the right contribution is a privilege extended by the respective communities under bylaws that rarely are documented but are there and should be respected.

Some communities do document their membership practices. Gentoo has an explicit membership process. Debian has a social contract the sets shared community expectations. Other communities have social processes that are part of the ambient structure of their world. You are advised to learn the implied procedures and policies if you intend to make progress and achieve you goals.

Secondly some degree of community control is likely to be seen as essential to the proper functioning of a FLOSS community. This is not some sort of hippie concert. Folks are making real software here. Linus Torvalds is jokingly referred to as the benevolent dictator… but his authority is real. Decisions need to be made and stuck to.

Sometimes, however, the decisions of the community leaders can and do cause division and frustration. Recently I was speaking with a commercial developer who had been working with a prominent open source distribution community for embedded devices. He expressed a high degree of frustration with this project and stated that there were “zealots” (his words) and this was keeping everything in a state of flux. His commercial project was, to a degree, hampered by this constant change and breakage. As his software stack expands from simply kernel and uClibc to graphics and windowing systems this breakage becomes more challenging.

I highly doubt this developer will be hung for his heretical statements. Nor are the members of this community anything like the Puritanical prosecutors of yore. I am also explicitly avoiding digging into the whole commercial vs. community supported argument. That’s for another day.

What I’m really trying to say is that when you evaluate a software base look at more than just code and the license. Try to understand the community that backs the project so that you can understand the operational dynamics of the community. How does it really work? Is the reality of this community going to serve your needs?

So I’m working with a group at our company that is fond of shared Microsoft Exchange Calendars. I’m a pragmatic fellow and while I have run Linux as my day-to-day platform for 10 years now I just realize that the world sometimes sees stuff differently from me. Whatever… I really don’t mind. It’s just a program. Run it.

Let’s just boot Windows in a VMWare virtual machine and run Outlook’s Calendar. Easy as pie. Wrong.

I use OpenSSH to tunnel into our work network. I map a slew of local ports to remote machines over the SSH connection. So what ports need to be mapped to the Exchange server. Answer: All of them.

Exchange is built upon MS-RPC which is a tweaked version of OSF DCE/RPC and all of these protocols seem to just love to dynamically allocate ports to serve individual clients. I saw it in Wireshark myself. Outlook connects to the exchange server over port 153 and the reply points Outlook to another port to continue the conversation.

At this point I am filled with colorful epithets that I’ve disciplined myself not to utter verbally.

I know very little about all of these protocols. Wikipedia this stuff:

• “MSRPC (Microsoft Remote Procedure Call) is a modified version of DCE/RPC.”
• “DCE/RPC stands for “Distributed Computing Environment / Remote Procedure Calls”.
• “Distributed Computing Environment (DCE) is a software system developed in the early 1990s by a consortium…”

Eh… hold it. A consortium? Oh, that explains some of this. Tell me more…

“As part of the formation of OSF, various members contributed many of their ongoing research projects. At the time, network computing was quite popular, and many of the companies involved were working on similar RPC-based systems. By re-building these various utilities on a single “official” RPC mechanism, OSF could offer a major advantage over SVR4, allowing any DCE-supporting system (namely OSF/1) to interoperate in a larger network.”

So MSRPC is based on DCE/RPC which is based on a bunch of corporate R&D cast-offs? (maybe cast-offs is a little harsh)

I’m just dubious about a closed door corporate consortium getting stuff right. There is a huge difference between a community centric development model with corporate participation (like the Eclipse community) and a corporate consortium populated with commercial actors even if the intended output of the consortium is to be licensed under a FLOSS license.

I have no clue if a real community would have reigned in the madness of dynamic ports. Maybe they were de rigueur at that time. I have a hunch it would have been different, though.