RE: License: spdx-license=IDENTIFIER

Jilayne Lovejoy: >yes, I actually agree. I have long thought that the short identifiers would >be better served as: >GPL-2.0+ >and >GPL-2.0-only >And logged this as something to bring up, but we have been busy with trying to >finish other tasks and it hasn't risen to the surface. Of course, th

RE: meta-tag page

I really like this idea of one special line I can quickly search for. It makes the SPDX list a lot easier to use. I have a comment on the justification: "The license list for SPDX is immutable and will never change." Well, that's not true, hopefully it'll keep getting larger. How about: "The m

RE: meta-tag page

Dmg: > Following this rational, would it be possible to recommend something in the > line of: > BEGIN_LICENSE > This file is licensed under the > For more information see URL-TO-SPDX-WEB-SITE-WITH-iNFO > END_LICENSE > that makes three things explicit: > > * It says where the license info in -file

RE: meta-tag page

If there can be agreement on a very short license "meta-tag" - and I have a strong preference for a version that lets me do it in 1-line- then I'll start using it. I suspect others would do so too. After all, it's easy to add this kind of line to a source code file: SPDX-License-Identifier:

RE: meta-tag page - part II

Gisi, Mark [mailto:mark.g...@windriver.com]: > My main concern is: if we don't choose a sufficiently expressive syntax, and > end up losing information, then we will have done more damage to SPDX than > good. It needs to represent NOTICES and not just a single license. Fair enough. I very much

RE: meta-tag page

I said: David> From a programmer's perspective I think the "cryptic" approach is FAR superior. There are lots of tools that can quickly examine files and return text with the pattern "SPDX-License-Identifier: ", and other tools that can trivially process the stuff after it. The above alternat

RE: meta-tag page - part II

Wolfgang Denk [mailto:w...@denx.de]: > But this example doesn't work either. If you mix a license that allows > "modify and keep the modified code closed" with GPL, the only legally > possible result is GPLed code. > I see little value in constructing such more or less artificial examples. This

RE: meta-tag page - part II

Wolfgang Denk [mailto:w...@denx.de] > But there there is no actual choice. Yes, you take the parts of the project > that do not include the GPL code - and you can use this code under the MIT > license for other purposes. But as soon as we talk about the thing as a > whole (say, the linked bin

RE: SPDX meta-tag for implicit license terms

Gisi, Mark: > All in all, from a compliance perspective - THERE IS NO BETTER PRACTICE THEN > INCLUDING A CLEAR LICENSE NOTICE IN EVERY FILE. Sure. However, in a world where a LARGE number of people intentionally include NO LICENSE and wrongly assert that "no license"=="I can do anything I want"

RE: [Bug 1292] New: What is the correct license expression for a project with an additional patent license?

Perhaps the "WITH" operator's definition needs to be extended. Instead of this definition: > The WITH operator semantically implies that a given license applies > except under certain special circumstances Perhaps "WITH" should mean "Modify the license listed on the left, by appending the

RE: Is "+" a valid character of a LicenseRef idstring?

Schuberth, Sebastian wrote: > Using a + is a whart. Licenses that allow the use of other versions do so > explicitly in their texts, the GPL being the most prominent but the EPL comes > to mind too. So there is no such thing as GPL-2.0 or another version: these > are the plain default GPL ter

RE: Is "+" a valid character of a LicenseRef idstring?

Philippe Ombredanne: > This + is a suffix and not a freestanding character, right? > Then again we would be better off to get rid of the plus entirely! You may be confusing a SPDX "license identifier" and a SPDX "license expression". It's a subtle point. The purpose of a "license identifier" is

RE: Is "+" a valid character of a LicenseRef idstring?

I said: > In particular, "GPL-2.0" is a license identifier, and "GPL-2.0+" is *NOT*. Just a few nitpicks on my previous email: * I realize that "GPL-2.0+" is in the list of "deprecated" license identifiers, so in some sense there is a "GPL-2.0+" license identifier. But I think it's clear what

RE: Is "+" a valid character of a LicenseRef idstring?

Philippe Ombredanne: > I am not confusing these at all. The gist of what I am saying is that the > plus is a legacy that should not be there. It does not make sense to add to > the large majority of GPL in the wild a + just to deal with a few exceptions > that do not allow other versions. Except

RE: Is "+" a valid character of a LicenseRef idstring?

Philippe Ombredanne: > The focus is not only on the GPL: well over 25% of the SPDX licenses DO HAVE > a "this or later version" clause > In the grand scheme of things, "only" and "or later" are minute > technicalities that the large majority of software users do not care for. The > licenses

Are SPDX license identifiers case-sensitive?

Are SPDX license identifiers case-sensitive? License *expressions* are not case-sensitive (e.g., the AND, OR, and WITH), per here: http://wiki.spdx.org/view/LicenseExpressionFAQ#Is_the_License_Expression_Syntax_Case_Sensitive.3F But that doesn't tell me about license *identifiers*. I've been pr

RE: Are SPDX license identifiers case-sensitive?

My personal preference would be that the license identifiers be *matched* by forcing everything to lower case, AND that SPDX encourage *displays* of a license identifier to use the exact mixed-case as shown in the SPDX lists. The mixed-case forms use normal English conventions (all-caps for acr

RE: Are SPDX license identifiers case-sensitive? (Ben Balter)

J. Lovejoy: > I feel like we had this conversation before on this topic and David’s > suggestion was raised, which I also agree with…. digging into meeting minutes > I found: > - > http://wiki.spdx.org/view/Technical_Team/Minutes/2014-09-16#Case_sensitivity_for_license_information > - the tech

Proposal: "SPDX-LICENSE" file convention

I propose a convention that builds on the SPDX-2.0 specification, the "SPDX-LICENSE" file. Users of this convention would include a file named "SPDX-LICENSE" (all upper case) at the top-level of a software project (typically an open source software project). This file would ONLY contain a SPDX

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 th

Proposed *SHORT* SPDX tutorial

I have created a proposed SHORT tutorial about SPDX: https://github.com/david-a-wheeler/spdx-tutorial/blob/master/README.md It's released under CC-BY-3.0 (same as the SPDX specification). To be effective I think the tutorial needs to be in HTML and very obvious to new visitors to the SPDX websi

RE: Proposed *SHORT* SPDX tutorial

Gary O'Neall: > Nice tutorial! Thanks! Sam Ellis: > Using .spdx for both rdf and tag formats makes it slightly harder for tools > to tell which format a given file is in. I note that the examples in > spdx-tools use extension .rdf for RDF files. I wonder if anyone else uses > this .rdf extensi

RE: Proposal: "SPDX-LICENSE" file convention

Gary O'Neall: > 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 app

RE: Proposed *SHORT* SPDX tutorial

Just to be clear, I’m a big fan of having a standard way to notate SPDX licenses within source files. I just find it odd that and Eric S. Raymond are currently using: SPDX-License-Identifier: when what comes after that is clearly a SP

RE: Proposed *SHORT* SPDX tutorial

Kate Stewart: >"tag:value" is the way in the spec for referring to the other supported > format. > I'm spotting tag/value > and tag-value in the tutorial Good eye. You’re absolutely right. > When I'm back from > vacation, if someone hasn't beaten me to it, I'll > submit a pull request to

RE: Proposed *SHORT* SPDX tutorial

> Yup, reasoning is clear. Its now a question of impact to projects already > adopted if change vs. adding alternate permitted identifier (SPDX-license-Expression) vs. leaving it as is. Technically older projects need not *change*. SPDX could recommend “SPDX-License-Expression” going forward,

RE: Prototype spdxify codewalker

> In my opinion it can only be used by the copyright holders of the single > files where the standard license header shall be replaced and not by any > other person. I would say you are not *removing* the notices, you are simply moving them to a different location. In particular, I'm presuming

RE: Prototype spdxify codewalker

ESR: > I will now express an opinion: It is *highly unlikely* that a court will ever > find any change of open-source license actionable, with one possible > exception: changes between reciprocal (GPL-style) and non-reciprocal > licenses. But from a court's point of view the difference between

RE: Prototype spdxify codewalker

ESR: > And the design of SPDX is intended to incorporate that text by reference. Yes, we completely agree there. To be honest, what is *most* valuable to me in SPDX are the SPDX license identifiers and SPDX license expressions. But having a simple, short, and clear way to express licenses is *

Bug and issues in SPDX grammar (Appendix IV)?

In the process of creating my tutorial I've found some potential issues in the SPDX spec. Below I argue that the license-expression grammar in Appendix IV seems to have at least one bug, it fails to discuss whitespace, and is overly complicated and confusing when you try to read it carefully.

RE: Bug and issues in SPDX grammar (Appendix IV)?

Also: is there any reason to *FORBID* the "+" suffix after a license-ref or license-exception-id? In particular, someone might use a license-ref while waiting for a license to be added to the SPDX license list or exception list. That would change my proposal grammar to: simple-expression = ( li

RE: Machine representation of deprecated licenses

I suggest that everyone use the term “deprecated license identifier”; don’t use “deprecated license” or “deprecated.” The obvious interpretation for the term “deprecated license” is that the license itself is forbidden going forward, and that’s not the intent here. --- David A. Wheeler From:

SPDX: Many tags should NOT be mandatory for the "developer assertion" use case

I'm primarily interested in the use case where software developers *assert* their license(s) in terms of a license expression, and the SPDX file (if any) is *embedded* in the package as a *hand-created* file (created by the developers). In this use case, I think that many of the "mandatory" tag

RE: SPDX: Many tags should NOT be mandatory for the "developer assertion" use case

> Bill Schineller [mailto:bschinel...@blackducksoftware.com] >Gary and I were talking about this at lunch - yes, your use case, which is > an important one for lowering the barrier for upstream projects to declare > licenses in a standardized way - represents an 'SPDX Lite' requirement/use

RE: SPDX: Many tags should NOT be mandatory for the "developer assertion" use case

Yev Bronshteyn: > Your use case seems to be already covered by the current SPDX 2.1 spec. With > the new filesAnalyzed attribute on packages, we can now describe packages, > with all their optional metadata richness without going into their contents. > Here is an example of that use case: A pack

RE: SPDX: Many tags should NOT be mandatory for the "developer assertion" use case

Yev Bronshteyn: > This is exactly the point of the filesAnalyzed attribute. Ah! *Now* I understand your point. Good to know. Is there a URL for the current SDPX draft? So would the text below be a valid LICENCE.spdx file, for someone trying to declare that "spdx-tutorial" was declared to be

RE: SPDX: Many tags should NOT be mandatory for the "developer assertion" use case

Yev Bronshteyn: > Here’s the link: > http://docs.google.com/document/d/112x3s3g1Qg2tj8bjvIPsqIBlWUp3Sob37cvAx2eiS6U/edit Thanks!! Sadly, the text for "FilesAnalyzed" suggests to me that this field is exactly wrong for the use case I'm most interested in. Let me call my use case "developer sel

RE: SPDX: Many tags should NOT be mandatory for the "developer assertion" use case

David A. Wheeler: >>I certainly will distribute the files, and I may very well *want* to state >>that certain files have/don't have certain licenses or exception. Yev Bronshteyn: > In that case, you don’t need filesAnalyzed = false. You can set it to “true” > or leave it out, specify the files t

Proposal: Add "(IF THEN [ELSE ])" to License expressions

In the Linux Foundation CII "best practices" badge effort I'm noticing an interesting problem. Some projects have *different* license situations for their source code and documentation, but there's no simple way to express that using SPDX License expressions. Examples of projects where the lic

RE: Proposal: Add "(IF THEN [ELSE ])" to License expressions

Philippe Ombredanne [mailto:pombreda...@nexb.com]> >Could this be simplified? > I can see two use cases: > 1. at the file or directory level, this is unlikely needed: just provide the > expression that applies there only e.g. to a doc or source directory in an > SPDX doc or a simple expression.

RE: Proposal: Add "(IF THEN [ELSE ])" to License expressions

Philippe Ombredanne: > I suggest instead to change this application design and data model to track > several license expressions, one for each of your "keywords". > For instance, by storing a list of expressions and what they apply to or by > breaking down top level packages in sub-packages each

RE: SPDX 2.1 Specification - please provide any final input before July 29, 2016

I have a quick comment on the draft spec. The current license expression doesn’t support multiple license exceptions, even though that is absolutely possible. I suggest tweaking the grammar to allow repeated WITH. This is easily done; in Appendix IV, in: compound-expression = 1*1(simple-expr

RE: HPND & NTP

Jilayne’s recommendation makes sense to me…! --- David A. Wheeler From: spdx-tech-boun...@lists.spdx.org [mailto:spdx-tech-boun...@lists.spdx.org] On Behalf Of J Lovejoy Sent: Friday, October 07, 2016 4:21 AM To: SPDX-legal Cc: spdx-tech@lists.spdx.org Subject: HPND & NTP Hi All, During the S

RE: Getting started...

Paul Sherwood: >>- maybe worth trying to get a CII badge for SPDX :) Kate Stewart: > For spdx-tools - yes, worth discussing. I’m technical lead of the CII badge project. Yes, I’d *really* like to see that for spdx-tools, FOSSology, and other SPDX-related OSS projects. If there’s any way that w

Re: [spdx-tech] GSoC Proposal

I'd like to see an online validation tool to validate *just* license expressions. E.g., are all the licenses known? Is the expression valid (OR, AND, etc.)? Bonus points: Make it trivial to automate - Send in with a trivial URL, replies with an easily-parsed answer. I don't often need to pro

Re: [spdx-tech] Can I add a comment/suffix to the SPDX-License-Identifier line?

I have previously commented that it would be valuable to have a “!” suffix meaning “exactly this version”. Technically “GPL-2.0” in SPDX means “only this version”, but in practice many practitioners & tools are sloppy about this. Part of the problem is that tools can easily determine that “GPL

Re: [spdx-tech] Can I add a comment/suffix to the SPDX-License-Identifier line?

> We've started having some discussions with FSF about what they'd prefer, and > their preference seems to be GPL-2.0-only,  so we probably want to go that > way rather than  introducing the "!" idea. Okay. Although that's less flexible, that's much easier to transition (you don't have to chan

Re: [spdx-tech] Can I add a comment/suffix to the SPDX-License-Identifier line?

Yev Bronshteyn: > How do you imagine this change working for everyone who used the > SPDX-License-Identifier format in code? Is “SPDX-License-Identifier: GPL-2.0” > now to be interpreted as “I’m licensing this under GPL 2.0 and not telling > you whether later is ok or not”? Because clearly this

Re: [spdx-tech] various threads on "only" suffix (for GPL)

J Lovejoy: > Thanks Bradley. Your point re: other licenses building in a de facto “or > later” > clause versus the GPL family of licenses leaving the choice to the copyright > holders is exactly the thing I wanted to confirm and is also (I think, but > need > to do more thinking on this) why the

Re: [spdx-tech] minutes, summary, next steps

W. Trevor King: > Is this proposal different from [1]? The only think I can see is that the old > “GPL-2.0 by itself is unclear” issue is now being explicitly embraced (while > [1] > listed it as a potential issue). > > Also, do we have a preferred phrasing for a grant like: > > This program

Re: [spdx-tech] minutes, summary, next steps

Gary @ sourceauditor.com: > Since "-" is an allowed character for a license ID, it would be more > challenging to write a parser for the "-only" operator since we would have to > determine if the "-" is part of the ID or is part of the operator. BTW "+" > is not > allowed in the license ID and "G

[spdx-tech] Two kinds of license version number ambiguity

The call yesterday revealed to me that there are *two* kinds of license version ambiguity in SPDX license expressions. I don't know if this is actually a problem, or if it is, that solving it is worth the trouble. For many people the "second kind" is probably immaterial. However, I want to re

Re: [spdx-tech] Proposed topic for this week's tech call: Extend license expressions to include OR-MAYBE

g...@sourceauditor.com: > - Do we agree the "OR-MAYBE" should be added? I agree, and I prefer OR-MAYBE (I didn't come up with it). It's more general AND its meaning is more obvious. My congrats to whoever created it, I think it was W. Trevor King. > - Should we disallow "OR-MAYBE" in declared li

Re: [spdx-tech] SPDX short-form IDs site

W. Trevor King: > I think that would be clearer if, instead of scoping this as “SPDX IDs”, you > scoped it as “SPDX License Expression Comments” or some such. Agreed. Perhaps call these "SPDX license comments" - since that's what they are? > Along those lines, I wish the comment tag had been >