feature article
Subscribe Now

Not Much New Under the Sun

SPDX Helps Contributed Code Licensing Management

These are not the times for DIY or NIH if you can help it. More and more is expected of fewer and fewer people, so the less you have to do yourself, the better. Yes, some of us live with that lurking inner feeling that, even though there are lots of wheels out there that have stood the test of time, we could do a far better job inventing a better one ourselves. The existing wheels are just so, well, ordinary.

Alas, however; the schedule doesn’t allow for that. We must go rummage through the selection at the Megagiant Wheel Warehouse, 3 acres of wheels piled in no particular order with no one there who knows anything about wheels… or we could spend more (<gulp>) and go to the Wheel Boutique… or we could simply poke around in the junkyard and see what’s available.

The bottom line is, the software you write for this new car may reflect your skilled hand-crafting in, perhaps, the portion where you are optimizing fuel efficiency, but for all the basic standard stuff (like the wheels, not to mention other software), you’re getting that elsewhere. And that other specialized part that deals with the newfangled radar thing that tells the driver when he or she is being and idiot and is about to slam into the car ahead? Yeah, you don’t have time to study that; you’re going to buy that outright.

So your software will be cobbled-together bits and pieces, a few of which you wrote, the rest of which you assembled. It may or may not be pretty, but at least you got it done and you’re getting paid. If you can’t take pride in having done the whole thing by yourself, at least you can be proud of doing your obscure bit better than anyone else.

But there’s a consideration: if you purchased the wheels or got them with permission from the junkyard, then you’re fine. But if you went and stole them off someone else’s car, then… not so much. And how do you prove that? You get a receipt.

Except: there are no receipts for software. You can download all kinds of freeware and no one will know. You can also steal code and maybe no one will know. Except when a telltale bug or error message or unaltered splash screen shows up and trips the burglar alarm. Then you’ve got trouble.

And people are wise to this now, so if your software is going somewhere, those inheriting it may want proof that it was obtained all nice and legal-like. Which means that any software you acquired elsewhere should come with a receipt in the form of a license saying that it’s okay for you to use the code the way you’re using it.

But who keeps track of where the heck all their code comes from? And who keeps a file of all the licenses? Seriously?

Yes, seriously. This is a topic Protecode has been propounding for a few years now: the concept of assembling an inventory of the code bits making up a program, along with their respective licenses. They started out with a database containing the signatures of a huge number of open-source code snippets, and they would scour your code to identify any such bits, thereby assembling this inventory.

But that works only if the code is in the database and you’ve taken a chunk sizeable enough to generate the right signature and you haven’t altered it in a way that changes the signature. It would be more straightforward if there were actually a formal mechanism for associating license information with code (free or otherwise): tools could then be developed that would allow the creation of licenses for code and the assembling and tracking of license for code contributions to a program.

That’s the purpose of the SPDX standard, sponsored by the Linux Foundation and just released last month. SPDX specifies a format for a machine- and human-readable file that contains the code pedigree or provenance of a code “package.” A package is a collection of files, each of which may hail from a different source. The SPDX file contains information on:

  • how the SPDX file itself was created (versions, who created it, how and when created, etc.);
  • information covering the entire package in common;
  • a list of various licenses likely to be found in the package (since different files may have different sources and license requirements) and a shorthand naming convention for each;
  • specific copyrights and licenses and other “facts” associated with each file in the package;
  • information on who reviewed the package.

They are careful to note that they don’t cover any patents, nor do they attempt to provide any legal interpretation of the licenses or copyrights.

With respect to license names and shorthand, the standard includes an appendix of no less than 155 different licenses and variants, from Academic Free License v1.1 (AFL-1.1) to Zope Public License 2.1 (ZPL-2.1). It could be expected that this list would grow, although you could reasonably ask whether yet more variations on licensing terms are needed. If anything, shrinking and combining might make sense (that, of course, being completely outside the scope of SPDX, which will accommodate growth or shrinkage).

The SPDX spec itself is licensed via the “Creative Commons Attribution License 3.0 Unported.” Which is four full pages long.

In addition to listing licenses, there is also an appendix spelling out the structure of the data interchange mechanism using the Resource Description Framework (RDF) from W3C. It shows the data model and defines the classes and properties so that various tools can work together to exchange license information.

Protecode, who had some participation in the SPDX project, has jumped into this immediately, having announced that their tools support SPDX. In addition, they have a specific workflow tool called Code Administrator that allows coders, or, more likely, managers, to assemble a package and have that package approved and logged in the company’s enterprise system for tracking all this stuff.

So, in essence, what this does is to allow each bit of software brought into a project to come with a receipt that can be decoded both by computers and by people. Those receipts can be assembled and filed and organized and referenced as needed based on an overall manifest that lists all the program contents.

So, even if you don’t get to invent it all yourself, you can at the very least prove that you came by it honorably. Whether that’s a point of pride or shame is up to you.

 

More info:

SPDX

Protecode

W3C’s RDF

Leave a Reply

featured blogs
Mar 4, 2024
The current level of computing power is unprecedented. It has led to the development of advanced computational techniques that enable us to simulate larger systems and predict complex phenomena with greater accuracy. However, the simulation of turbomachinery systems still pos...
Mar 1, 2024
Explore standards development and functional safety requirements with Jyotika Athavale, IEEE senior member and Senior Director of Silicon Lifecycle Management.The post Q&A With Jyotika Athavale, IEEE Champion, on Advancing Standards Development Worldwide appeared first ...
Feb 28, 2024
Would it be better to ride the railways on people-powered rail bikes, or travel to the edge of space in a luxury lounge hoisted by a gigantic balloon?...

featured video

Tackling Challenges in 3DHI Microelectronics for Aerospace, Government, and Defense

Sponsored by Synopsys

Aerospace, Government, and Defense industry experts discuss the complexities of 3DHI for technological, manufacturing, & economic intricacies, as well as security, reliability, and safety challenges & solutions. Explore DARPA’s NGMM plan for the 3DHI R&D ecosystem.

Learn more about Synopsys Aerospace and Government Solutions

featured paper

Reduce 3D IC design complexity with early package assembly verification

Sponsored by Siemens Digital Industries Software

Uncover the unique challenges, along with the latest Calibre verification solutions, for 3D IC design in this new technical paper. As 2.5D and 3D ICs redefine the possibilities of semiconductor design, discover how Siemens is leading the way in verifying complex multi-dimensional systems, while shifting verification left to do so earlier in the design process.

Click here to read more

featured chalk talk

Achieving High Power Density with IGBT and SiC Power Modules
Sponsored by Mouser Electronics and Infineon
Recent trends in the inverter market have made high power density, scalability, and ease of assembly more important than ever before. In this episode of Chalk Talk, Amelia Dalton and Abraham Markose from Infineon examine how Easy & Econo power modules from Infineon can help solve common inverter design requirements. They explore the benefits and construction of these modules and how you can take advantage of them in your next design.
May 19, 2023
32,098 views