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 25, 2022
Explore the world of point-of-care (POC) anatomical 3D printing and learn how our AI-enabled Simpleware software eliminates manual segmentation & landmarking. The post How Synopsys Point-of-Care 3D Printing Helps Clinicians and Patients appeared first on From Silicon To...
May 25, 2022
There are so many cool STEM (science, technology, engineering, and math) toys available these days, and I want them all!...
May 24, 2022
By Melika Roshandell Today's modern electronic designs require ever more functionality and performance to meet consumer demand. These requirements make scaling traditional, flat, 2D-ICs very... ...
May 24, 2022
By Neel Natekar Radio frequency (RF) circuitry is an essential component of many of the critical applications we now rely… ...

featured video

Synopsys PPA(V) Voltage Optimization

Sponsored by Synopsys

Performance-per-watt has emerged as one of the highest priorities in design quality, leading to a shift in technology focus and design power optimization methodologies. Variable operating voltage possess high potential in optimizing performance-per-watt results but requires a signoff accurate and efficient methodology to explore. Synopsys Fusion Design Platform™, uniquely built on a singular RTL-to-GDSII data model, delivers a full-flow voltage optimization and closure methodology to achieve the best performance-per-watt results for the most demanding semiconductor segments.

Learn More

featured paper

Intel Agilex FPGAs Deliver Game-Changing Flexibility & Agility for the Data-Centric World

Sponsored by Intel

The new Intel® Agilex™ FPGA is more than the latest programmable logic offering—it brings together revolutionary innovation in multiple areas of Intel technology leadership to create new opportunities to derive value and meaning from this transformation from edge to data center. Want to know more? Start with this white paper.

Click to read more

featured chalk talk

Power over Ethernet - Yesterday, Today, and Tomorrow

Sponsored by Mouser Electronics and Microchip

Power over Ethernet has come a long way since its initial creation way back in 1997. In this episode of Chalk Talk, Amelia Dalton chats with Alan Jay Zwiren from Microchip about the past, present, and future of power over ethernet including details of how a PoE system works, why midspans are crucial for power over ethernet connectivity and why Microchip can be your one stop shop for your next PoE design needs.

Click here for more information about Microchip Technology multi-Power over Ethernet (mPoE)