David and Kate, I agree with the need to document a simple tutorial for including SPDX files for original code. I also agree it would be good to maintain the same tag names and definitions as used in the SPDX document standard. We might as well leverage the work done as long as it is appropriate for the use case. It would also make it easier and more accurate for downstream consumers and suppliers of open source to produce SPDX documents.
I would also propose we re-open the discussion on a "light" version that could be used for original code developers with less required fields. We ended up supported a very large number of use cases in the 2.0 spec, which unfortunately had the side effect of having a lot of additional fields that may not be applicable for some of the specific use cases such as documenting license information for originating open source projects. BTW - I have also seen this as a theme for feedback on the 2.0 spec from others using other specific use cases, so we may need to have some other specific tutorials. I have actually implemented full SPDX files for open source projects. Since it requires checksums, it does require tools to produce. I have written two tools - an Eclipse plugin to maintain an SPDX document "live" as the project is created and maintained and a Maven plugin to produce and maintain an SPDX document at build time. What I have learned through the experience is that it is much easier to produce and maintain the actual file at build time. You really don't want to check in an SPDX document that is changed with every file change - it guarantees merge conflicts. The Maven plugin leverages a Maven pom file to store the SPDX fields. Perhaps we could use an "SPDX Light" format to store the input fields using the same tag/value formats as SPDX for non Maven build environments. Gary > -----Original Message----- > From: [email protected] [mailto:spdx-tech- > [email protected]] On Behalf Of Wheeler, David A > Sent: Saturday, November 21, 2015 11:09 AM > To: [email protected] > Subject: RE: Proposal: "SPDX-LICENSE" file convention > > Kate Stewart: > > Just wondering if putting out a tag:value SPDX file at the top level > suffice? > > Both tag:value and RDF/XML are supported formats, and care has been > >taken so that translation between the two (and spreadsheets) is possible. > > It *could* work, I guess. I've been assuming that the full SPDX file format > (in either XML or tag-value format) is for license analysis people & > specialized tools to exchange license information, and is NOT expected to be > used by developers to express their license. I've been advocating the use of > SPDX license expressions, but NOT the full format, for that reason. I'll note > that others (e.g., Eric Raymond) have also been advocating SDPX license > expressions, but NOT the SPDX file format - so others seem to be making the > same assumption. > > One current problem is that SPDX website doesn't help developers who want to > quickly use SPDX files to declare their licenses for simple cases. There’s no > short tutorial, nor any obvious short file examples, to help developers > understand how to describe their license for simple common cases. Most > software developers do not have time to read through an 88-page reference > document just to declare "this entire package is released using this specific > well-known license".; its length alone signals "this is a detailed spec > intended for specialists." If the SPDX group wants ordinary developers to use > SPDX file format to declare their license, then the SPDX site needs a tutorial > that explains in ~60 seconds how to declare that my package is MIT, or Apache- > 2.0, or GPL-2.0+. > > I intend to draft a short SPDX tutorial, and post it here, to show what I > mean. I hope people will find it useful enough to improve and put on the SPDX > website. > > Another problem seems to be that the existing specific and guidance *appears* > to assume the file is *unconnected* to the project, instead of being included > with it. For example, it urges the inclusion of information that doesn't > really make sense if the SPDX data is included as part of a project and thus > managed by its version control system. For example, when I look here > <http://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0/Low_cost_SPDX_file> it > says that, "Project maintainer creates SPDX file that describes his package > (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does > not included information about the files in package and does not generate > packageVerificationCode....". Checksums?!? Are you kidding? Checksums are a > waste of time SPDX information is maintained in a package; if a SPDX license > file can be corrupted when it's inside a version control system, then so can > the project's source code. Existing information also urges that the SPDX file > include information about each file *within* it, instead of being distributed > to the files. That's also absurd; developers add new files all the time, and > if you think it's important to have per-file license information, then that > information needs to be in the file itself. When people copy files into other > projects, they will copy that source file, not the SPDX file, so per-file > information (if you care) needs to be in the actual source file. I note that > Eric Raymond is *NOT* using the SPDX data format, just the license expression > syntax, and adding statements like this to each source file > <http://esr.ibiblio.org/?p=6867>: > SPDX-License-Identifier: BSD-2-Clause > This convention isn't documented on the SPDX site, as far as I can tell, and > it's probably technically not quite right (I think he means a SPDX-License- > Expression not a SPDX-License-Identifier). > I don’t see why I need 'licenseConcluded' - if I have the right to declare > software to have a license, there's no reason that I need to also declare a > conclusion. Frankly even 'name' and 'description' are excessive; name is > reasonable just to prevent separation, but all you really need is > 'licenseDeclared'. > > So I think I could live with tag-value format instead of my proposed "SPDX- > LICENSE" form, as long as there's a quick tutorial on the SPDX site on how to > *do* that. However, there still needs to be a standardized convention for > embedding SPDX license names within source file comments. I would suggest > using a variant of ESR's convention, and recommend that those who want to > embed SPDX license expressions do this: > SPDX-License-Expression: .... > > --- David A. Wheeler > > _______________________________________________ > Spdx-tech mailing list > [email protected] > https://lists.spdx.org/mailman/listinfo/spdx-tech _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
