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
May 18, 2021
Since I was a kid, I’ve always been a fan of technology making life better. When I was 8, I remember programming the VCR to record the morning cartoons so I wouldn’t miss the good ones after the bus picked me up from school. When I was 10, I made mixtapes of my fa...
May 18, 2021
原文出è•: Please Excuse the Mesh: CFD and Pointwise ä½è…: Paul McLellan Cadence於今年四æˆæ”¶è³¼äº†æµé«”動力學公司Pointwiseã‚å¨æˆ‘的前ä¸ç¯‡æ–‡ç« æŽ¢è¨Ž PointwiseãPCIeã...
May 13, 2021
Our new IC design tool, PrimeSim Continuum, enables the next generation of hyper-convergent IC designs. Learn more from eeNews, Electronic Design & EE Times. The post Synopsys Makes Headlines with PrimeSim Continuum, an Innovative Circuit Simulation Solution appeared fi...
May 13, 2021
By Calibre Design Staff Prior to the availability of extreme ultraviolet (EUV) lithography, multi-patterning provided… The post A SAMPle of what you need to know about SAMP technology appeared first on Design with Calibre....

featured video

What’s Hot: DesignWare Logic Library IP for TSMC N5

Sponsored by Synopsys

Designing for N5? Josefina Hobbs details the latest info and customer results on Logic Library IP for TSMC N5. Whether performance, power, area or routability are your key concerns, Synopsys Library IP helps you meet your toughest design challenges.

Click here for more information about DesignWare Foundation IP: Embedded Memories, Logic Libraries, GPIO & PVT Sensors

featured paper

Designing TI mmWave radar made easier using our third-party ecosystem

Sponsored by Texas Instruments

If you are new to radar or interested in replacing your existing sensing technology with radar, there can be a significant learning curve to both designing your product and ramping to production. In order to lower this barrier, Texas Instruments created a third-party ecosystem of radar experts who can provide solutions no matter how much help you need.

Click to read more

featured chalk talk

Yield Explorer and SiliconDash

Sponsored by Synopsys

One a design goes to tape-out, the real challenges begin. Teams find themselves drowning in data from design-process-test during production ramp-up, and have to cope with data from numerous sources in different formats in the manufacturing test supply chain. In this episode of Chalk Talk, Amelia Dalton chats with Mark Laird of Synopsys in part three of our series on the Silicon LifeCycle Management (SLM) platform, discussing how Yield Explorer and SiliconDash give valuable insight to engineering and manufacturing teams.

More information about the Synopsys Silicon Lifecycle Management Platform