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!

ShareThis

I’m back from FTF now and I’ve got a little more to share about the demo I spent most of my time standing in front of. I was showing off the new Freescale QorIQ P4080 running MontaVista Linux in an SMP configuration:

The system is booting, debugging, and running applications including a full userspace configuration. Our DevRocket IDE was in the demo as an example of debugging memory usage, memory leaks, and multi-threaded debug. We’ll have broader tool support up and running as engineering continues.

This is all exciting for a chip that has yet to be manufactured.

Brad

ShareThis

I’m attending the Freescale Technology Forum in Orlando, Florida this week representing MontaVista. This is Freescale’s 4th FTF event in the US and like every year it has been a valuable technical training event and a chance to connect with the experts on various technologies.

Multicore and the QorIQ P4080

The big Freescale announcement this week, in my opinion, was the new multicore QorIQ P4080 that was unveiled. It is an e500 core based design with 8 cores on chip. What is compelling about the annoucement at FTF is that the chip itself is not present. Each and every instance you see of a demo built upon the P4080 is running in a simulator. Freescale has provided key partners (MV included) with the simulator and everyone has started to pre-integrate their products with the P4080 platform.

Virtutech Simics

The simulator used by Freescale is Virtutech’s Simics. This is not a typical cycle-accurate simulator that is used to support semiconductor design and prototype. The simulation is based on functional (ie. behavioural) aspects of the design so the simulation runs quickly. Rather than taking days to boot Linux like the behavioral simulators might for complicated chip designs simulated at the RTL level this one is actually quite quick. I’ve worked with Simics fairly extensively (though I’m still learning) when building our MontaVista Test Drive evaluation system. We’ve run Linux and applications unmodified on Simics… it just works. For those who need cycle accurate timing for performance benchmarking please give Virtutech a call… they may have something to say on that.

Everyone in on the P4080

So what’s running on this not-yet-a-chip chip? Just about everything and most of it seems to be Linux. We’ve got MontaVista Linux running on the platform now:

If you run over to the Virtutech booth you can see just about every other OS that might be running doing so at the same time:

Simics is really aimed not at just running a single hardware instance but in simulating the entire system (with custom I/O) and system-of-systems that interoperate.

The Technology Lab

Freescale has one or two times a day an open “Technology Lab” where everyone gets to mill around and see what’s new. What FTF does right is a) they make sure some “fun” technology shows up and b) they serve beer and food. Hard to complain about that. What’s fun this year:

A robot that autonomously plays air hockey. The robot uses a video camera mounted above the air hockey table to sense the puck. Notice the reflective tape outlining the puck. The robot is fast and quite good. It is not invincible, however… folks who are fast enough seem to be able to beat it at the corners. You can see it playing a little on a webcam covering the floor. The system was designed by Nuvation for Freescale’s use a demo, I think.

This is a Linux based HD digital media server shown with some great HD road rally scenes. Thanks to Greg Shippen (System Architect, Freescale) for showing it to me. It was streaming simply beautiful HD video without and challenges.

ShareThis

I was just doing one of those vanity searches on technorati.com where you search for your name or company just to see what others think. I feel bad admitting it… but fess up. You know you do it, too.

Anyways I noticed many posts where people were speaking about their phones (often from Motorola) and about wanting to reconfigure the MontaVista Linux software that they claim is on the device. I say “they claim” only because I’m not in a position to confirm or deny anything about anyone using our product. Don’t ask… I won’t tell.

I’ve also seen emails come in from time to time requesting (usually politely) that MontaVista provide the source code to a phone that is claimed to run MontaVista Linux. These requests are impossible for us to satisfy because we at MontaVista are usually never in possession of the code that is actually on the phone. I’ll explain.

In the enterprise world if someone says their server runs Red Hat Linux 5.0 then if you go and fetch RHEL5 from Red Hat you’ve likely got exactly what makes that server run. Red Hat prevents their customers from modifying RHEL by tying the support contract to their binaries. If you modify the binaries then Red Hat won’t support it. Read the support scope of coverage document.

That just won’t fly in the world of embedded software that powers the devices you love. All of our customers (save a few) modify the software we provide to them. Some modify it extensively.

We also support a wide range of hardware configurations and do most of it through static kernel configurations for some technical reasons. RHEL runs as unmodified binaries on every piece of hardware it supports. MontaVista Linux is designed for a different usage model and therefore is different. Companies typically don’t want to design in extra flash to support hardware they aren’t using.

So while MontaVista is a supporter and adherent to the GPL license and other open source licenses we are not the right people to ask. We don’t have the crucial code that you need to help you hack your phone, television,  or any of the 10’s of millions of devices that run MontaVista Linux. Our customers don’t provide these crucial code modifications to us. They are under no obligation to do so, of course.

The best thing to do is to contact the manufacturer of the device. Most of them intend to comply with the licenses they are using and will do so. We often advise them on the right path to satisfy both the letter and the spirit of these licenses which make the world of open source work. Companies like Sony and many others do so wonderfully.

ShareThis

Next week I’ll be attending the Freescale Technology Forum in Orlando, FL. I’ll be presenting on power management for Linux based products on Wednesday at 5pm in the Tuscany A room.
For more info on the other presentations being conducted by my colleagues please see the list here.

ShareThis

Nat Torkington started off on today about why “Web 2.0 Is From Mars, Enterprise Is Up Uranus” recasting oft quoted “laws” of the Internet into their alter ego “enterprise” versions. This one laughed me up… I’ve heard it before myself:

• Torvald’s Law: Given enough eyeballs, all bugs are shallow.
• Torvald’s Enterprise Law: Given enough eyeballs, all bugs are exploited.

The quote is actually from Eric S. Raymond who, I presume, stated what he thought Linus would say if Linus were predisposed to statements of that sort.

Yup… I’ve heard prospective adopters of open source software cite as their chief concern the fact that it was open. If only somehow they could buy open source software that no one else has seen… that would make it better. Where do we download that?

That reminds me of something…

A few years ago a prominent military program even pressed for MontaVista to make an exhaustive review of the community codebase our product is built upon in order to identify subversive code. If you’ve not thought of this before there is, of course, the possibility that rogue agents of foreign powers could insert subversve code into popular open source projects with the intent of later exploiting that code.

Think it can’t happen?

The US did it to the Soviets back in 1982. The CIA inserted subversive code into natural gas pipeline control software that was being procured by the Soviets. When the subversive artifice was triggered “The result was the most monumental non-nuclear explosion and fire ever seen from space” according to the author of “At the Abyss: An Insider’s History of the Cold War.” We in fact corrupted a whole slew of technologies that were on an espionage shopping list the KGDB maintained.

So do many eyeballs make all bugs shallow? The answer has to be “no” if you read that statement to mean that all of the defects have been removed by the community’s inspection. If you read it to mean that even difficult defects can quickly be surmounted then I’d think you’ve read it correctly and I agree.

So does proprietary software have a better possibility of avoiding the insertion of subversive artifices? I don’t think so. Back in 1980 Philip A. Meyer’s graduate thesis for the Naval Postgraduate School gave a review of the problem. “Subversion: The Neglected Aspect of Computer Security” is a great read on this subject. It is old enough the PDF is a scan so my quotes are actually clippings:

Yeah… I’ve seen that, too.

The Meyers paper goes on to discuss what is now a commonly held assertion security kernels are the right tool to use to protect against subversive code.

Security kernels, are, still vulnerable:

I am, frankly, not enough of an expert to tell you what the route to security nirvana is… or even what nirvana is for your particular project. […and Meyers says some great things about vendors and their claims.] There is no one right answer that suits everyone. The world of open source (including the Linux kernel) gets a lot of attention from various security minded groups yet it still has its own collection of screw-ups.

I guess I just really want to say that software is software. When it comes to security the license it is distributed under isn’t a primary factor to consider. Other factors are more important.

Brad

ShareThis

Robert Lee Hotz in a recent Wall Street Journal article “Revenge of the Freeloaders” summarized a set of fascinating experiments that characterized “antisocial punishment” in cultures around the world. Antisocial punishment is the tendency for individuals to sanction others that behave in a way that benefits society. Prosocial behavior, I had thought, was something that would have been at least tolerated if not universally respected as a noble pursuit. Proves what I know, I guess.

The experiment use groups of four who could contribute to an investment pool anonymously. At the end of the round a dividend would be paid to all. As you can quickly see this is an invitation for freeloaders to withhold their contribution but still reap a benefit. Previous research has evidently proven what we all know to be true… that if there is too much freeloading going contributors will withhold their contributions.

The research indicated that offering the participants the ability to punish those who were freeloaders kept the contributions flowing. The need to punish freeloaders was so essential to the participants that they would punish even if it cost them something to do so.

This triggered some thinking about the relative merits of the BSD and GPL licenses. I’m a fan of both… but given this new observation about the need of those who behave prosocially to chastise freeloaders I have new questions. We know that there really is no practical way for an author who licenses software under the GPL to effectively punish freeloaders. There is no reason to even do so, in fact. Software is meant to be used and it is likely that any author who uses the GPL will in fact desire wide usage of the software in question. Might it be possible, however, that the GPL’s oft derided “viral” aspect assuages contributors internal fears that freeloaders will run rampant without the opportunity to discipline them?

Maybe this explains a recent observation over at the Google Open Source Blog: “The trend around licensing is obvious: GPLv2/GPLv3 represent 42.6% of the projects, and Apache is 25.8%. MIT, BSD, and LGPL are at about 8% each, Artistic at 3.5%, and MPL 1.1 at a mere 2.7%.”

More next time on a compelling and surprising role that cultural attitudes towards prosocial behavior may play in the patterns of open source software development.

Brad

ShareThis