Combining Open And Proprietary: Bruce Perens Tells You HowCombining Open And Proprietary: Bruce Perens Tells You How
If there's an authority on the concept of open source, it's probably Bruce Perens: after all, he helped found the open source movement in the first place. Over at Datamation, he's got an <a href="http://itmanagement.earthweb.com/osrc/article.php/3801396/Bruce-Perens-Combining-GPL-and-Proprietary-Software.htm" target="_blank">article</a> on a subject few people understand well: the tricky practice of combining open source and proprietary software.</p>
February 10, 2009
If there's an authority on the concept of open source, it's probably Bruce Perens: after all, he helped found the open source movement in the first place. Over at Datamation, he's got an article on a subject few people understand well: the tricky practice of combining open source and proprietary software.
The main example that Bruce discusses in his article is embedded systems -- phones, TV boxes, appliance-style hardware. Such solutions almost inevitably involve combining something free (e.g., BusyBox) with something non-free (e.g., DRM). Engineers are often tempted to turn to open source solutions for such things as a timesaver, only to be shot down by their legal departments. The whole thing doesn't have to be a compromise between delivering a solution on time and getting into hot water.
What's crucial, as Bruce points out, is keeping the open and proprietary components physically discrete. I've seen examples of this in action; right here on this computer I've got CrossLoop, a proprietary app that uses the open-source VNC protocol. The way CrossLoop uses VNC falls under the "arm's-length" provision, since it's being invoked by another program and not actually incorporated into it.
This stuff can seem distressingly complicated to the outsider, especially someone who's not done software engineering in the strictest sense of the term. One of the comments on the article by Bruce himself touches on this issue. "When I learned electronics, we soldered together discrete components to make a product. Today, we combine copyrighted units of other people's intellectual property to make a product. And we don't really have the tools to carry out that task properly."
There are, of course, auditing tools that allow you to get a better grip on what sort of software licenses you might have floating around in your code stew. It sounds like Bruce is talking about something much larger -- say, the need for entire development environments that are also licensing-aware, and that allow you to automatically assemble larger projects from multiple libraries without creating licensing collisions. And even then, I doubt that'll be a substitute for the ancient art of knowing what you're doing.
About the Author(s)
You May Also Like