DataTables and Healthcare.gov Case Study

By nexB Team December 03, 2013

The story started with this post at the Weekly Standard

Note that the link from the article will now take you to a corrected file with a full copyright and license notice.

But there is a copy of the original file at Archive.org (with an added archive.org header).

The article shows code snippets from two different files from the DataTables project.

The first snippet shows the header for the file DataTables.js, which shows the copyright and license notice for the project. This file is the "primary" source file from the source folder /DataTables-1.9.4/media/src/ which defines DataTables as a plug-in to JQuery. The second snippet is from the DataTables file: DataTables-1.9.1/media/src/core/core.columns.js. This code snippet is not in the file DataTables.js despite the path/filename in the browser address as shown in the article.

The original file core.columns.js does not contain any copyright or license notice and neither do any of the other 15 JavaScript files released by DataTables in that code folder nor do any of the other 14 files in /DataTables-1.9.1/media/src/. It is unclear why the Healthcare.gov file is name DataTables.js because it does not contain code from the original DataTables.js - rather it is a collection of code snippets from various other DataTables files. The second set of snippets are from the file: /DataTables-1.9.1/media/src/core/core.sort.js.

Analysis

The developer(s) responsible for this part of the website pulled a set of code snippets from various files from the DataTables project and decided to name the file DataTables.js. These individual DataTables files do not contain copyright or license notices nor do they contain the summary/version comments found in the Healthcare.gov file shown in the article, but since those comments are in the same format as in the original DataTables.js it seems that the developer(s) copied that “snippet” from DataTables.js and decided to not include the license and copyright information.

Some key lessons from this incident are:

  • Your source code in Web-oriented languages like JavaScript is quite public on your website and relatively easy for an enthusiast to find and investigate.
  • Developers are not likely to do a very good job fulfilling OSS (open source software) obligations without clear guidance. If you use a file from an OSS project that does not itself contain copyright and license information, what is your obligation? And how do you fulfill it?
    • Good practice is to document the copyright and license in your file even if that is more than the original developers did because you have changed the context for use of the file.
  • The developers in this case seem to have come up with a very poor “solution”:
    • Borrow code from many files of a well-known project, combine those snippets into a new file and give it the same name as another file of that project even though there is no code from the latter file.
    • Document the project name and version in the file header without the copyright and license notice.
  • Your website should have an ABOUT or other standard location in the sitemap where you can acknowledge/attribute use of open source components at a summary level which enables you to manage outbound OSS attribution obligations in one place. This does not remove the requirement to track OSS usage, but it would give you more leeway in dealing with attribution at the file level.

Blog Posts