SPDX is a format for exchanging information about licenses and copyrights of a “component” (loosely defined). The main goal is to avoid doing work multiple times: once a component has been vetted, it shouldn’t be redone all the time. It is targeted to but not limited to open source. 75 out of 100 people asked thought that this kind of industry standard was at least somewhat important.
Everybody in the audience knows SPDX, only 2-3 use it in their organization (and not very convincingly).
SPDX by itself doesn’t solve the issue of trust: it is only a standard format to specify who has reviewed a component and what the conclusions were, but it doesn’t e.g. including crypto signing and by itself it doesn’t relieve you from doing due diligence in checking copyright.
SPDX has a repository of standard licenses, including their text with stable URLs. There’s a set of rules (“matching guidelines”) to say to what extent the text has to be identical for the license to be consider the same (e.g. different spellings of license/licence).
SPDX file contains info about itself (SPDX version, creation info), package info (including hash of all files excluding the spdx file itself), per file a license and a concluded license (e.g. if a file has no explicit license but the directory does, use that one). It also contains a list of license texts that are not standard. And it contains a log of reviewers of the info.
Open source project can include a one-line comment in all their source files that specifies the license as an SPDX-compliant string, to ease the generation/verification of SPDX files. It would also be possible for open source projects to include an SPDX file for their releases.
For SPDX 2.0, the idea is to add hierarchy for components that include other components. For instance, an embedded product could have an SPDX file that refers dozens of other SDPX files (but it’s also possible to generate just a single flat one). Signing may also be part of it. 2.0 is foreseen for somewhere in 2014. SPDX versions should be backward compatible, i.e. a 2.0 tool should be able to read 1.2 files – there is no excuse to wait.
Adoption: e.g. Samsung has fully adopted it: every product must have an SPDX file, every product has a QR code that refers to a website containing all that info. Debian uses the same tags as SPDX (except GPL-2 instead of GPL-2.0).
UNO has a FOSSology instance that can be called from yocto to generate an SPDX file.
Are their tools to help to create SPDX files e.g. from a git repository? Not yet, but they would be really convenient. Maybe a good GSoC project?
License compatibility is not in scope for SPDX, because it is interpretation. SPDX focuses on facts.