Glenn's Web Factory

Thursday, November 24, 2005

More Lessons from the Sony Fiasco - Source Code Origin Transparency

Many of us have watched in subdued horror as the Sony BMG DRM drama plays out. Since the October 31 discovery that Sony had released music audio CDs with a rootkit installed (spyware which annoys paying customers in attempts to keep them honest while having no effect on experienced music pirates or anyone who has tape) we've seen Sony compound their mistakes in providing damaging removal software (don't install this!) and attempts to ignore, deny or downplay the seriousness of their offenses. (For the sarcastic among you, get your I "heart" rootkit tShirts here!)

The public outcry (and class action complaints!) seems to be getting through to some degree, but now another discovery that the software contained on the discs appear to contain open source software that is used in violation of its license. Sony purchased this software from a third-party called First4Internet) who has declined comment about the matter) but that code clearly contains code fragments from the LAME open source project. This raises lots of questions of accountability and it will be interesting to see who is held responsible for this violation.

But regardless, it emphasizes the need for companies who purchase software to heavily scrutinize the code origins to ensure compliance by all applicable licenses and regulations. Corporate software purchasers should demand absolute transparency to all code used for an application and obtain a signed statement attesting to it.

With the tremendous amount of available source code on the Internet, developers are increasingly depending on code, libraries or components developed by others. In turn, these libraries or components may depend on other components and so on. With the endless array of licensing options available, each with their own rules for use or extension, a fair amount of scrutiny is required to determine just how "owned" a software product is, and under just what conditions it may be legal to be used, modified, distributed or sold.

For example, Yokohama (my company's flagship product) incorporates a small handful of "third-party" components to enhance it's functionality:
  • TinyMCE - An excellent rich text editing component produced by Moxiecode Systems AB. Nature of use: "linked library". License: LGPL.
  • FileUpload and DBCP from the Apache Jakarta Commons project for handling file submissions via the web and database pooling. Nature of use: "linked library". License: Apache
  • Matt Kruse's Calendar Popup for easy entry of dates. Nature of use: "linked library". License: Custom (Allows free use, must retain original header)
  • Walter Zorn's DHTML Tooltips for enhanced tooltips. Nature of use: "linked library". License: LGPL.
The nature of "linked library" usage means the code has not been copied and pasted into your own application, but is left in whole on it's own and linked to via a script call (for javascript libraries) or via a CLASSPATH (for java libraries). For each of these libraries, this allows for full distribution with commercial products and does not impose their licenses upon your proprietary applications which link to them.

That is the full disclosure of our software's included third-party code. I recommend every ISV to create a similar list for their clients (it wouldn't necessarily have to be published on the web). Furthermore, I strongly recommend companies who purchase software to demand such a list and require a signed statement as to the accuracy of the list.

I believe such precautions would go a long way towards limiting the liability for companies who might otherwise find themselves in Sony's shoes.

Comments?

0 Comments:

Post a Comment

<< Home