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:
