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
Nov 24, 2020
In our last Knowledge Booster Blog , we introduced you to some tips and tricks for the optimal use of the Virtuoso ADE Product Suite . W e are now happy to present you with some further news from our... [[ Click on the title to access the full blog on the Cadence Community s...
Nov 23, 2020
It'€™s been a long time since I performed Karnaugh map minimizations by hand. As a result, on my first pass, I missed a couple of obvious optimizations....
Nov 23, 2020
Readers of the Samtec blog know we are always talking about next-gen speed. Current channels rates are running at 56 Gbps PAM4. However, system designers are starting to look at 112 Gbps PAM4 data rates. Intuition would say that bleeding edge data rates like 112 Gbps PAM4 onl...
Nov 20, 2020
[From the last episode: We looked at neuromorphic machine learning, which is intended to act more like the brain does.] Our last topic to cover on learning (ML) is about training. We talked about supervised learning, which means we'€™re training a model based on a bunch of ...

featured video

Accelerate Automotive Certification with Synopsys Functional Safety Test Solution

Sponsored by Synopsys

With the Synopsys Functional Safety Test Solution architecture, designers of automotive SoCs can integrate an automated, end-to-end BIST solution to accelerate ISO compliance and time-to-market.

Click here for more information about Embedded Test & Repair

featured paper

Learn how designing small is easier than you think

Sponsored by Texas Instruments

Designing with small-package ICs is easier than you think. Find out how our collection of industry's smallest signal-chain products can help you optimize board space without sacrificing features, cost, simplicity, or reliability in your system.

Click here to download the whitepaper

featured chalk talk

Automotive Infotainment

Sponsored by Mouser Electronics and KEMET

In today’s fast-moving automotive electronics design environment, passive components are often one of the last things engineers consider. But, choosing the right passives is now more important than ever, and there is an exciting and sometimes bewildering range of options to choose from. In this episode of Chalk Talk, Amelia Dalton chats with Peter Blais from KEMET about choosing the right passives and the right power distribution for your next automotive design.

Click here for more information about KEMET Electronics Low Voltage DC Auto Infotainment Solutions