Hi All,
I probably should have explained this to begin with and Richard has now
provided some key background, which I’ll add to here:
OSI has adopted (and did endorse via a joint public announcement that was
probably back in 2011) the SPDX identifiers. This is implemented on the OSI
list via the URL and indication in parenthesis next to the full name. This was
all very easy in the beginning, as the OSI list did not change for some time,
so once we were all “caught up” from both sides - that is, SPDX ensure all
OSI-approved licenses were on the SPDX License List; and OSI adopted the short
identifiers from SPDX.
More recently, as OSI started to approve licenses again, we realized we needed
some better cross-communication such that: SPDX would know when OSI added a new
license; SPDX could then create a short identifier; OSI could use the short
identifier in the same way as described above: and SPDX could ensure that new
OSI-approved was added to the SPDX License List. We discussed this process
about a year or so ago and it was also decided that where OSI got a new license
up on their website prior to SPDX adding it to the SPDX License List / assign a
short identifier, then OSI could add that reference (parenthetical) to their
webpage and change the OSI URL as needed to all be consistent.
So, that is where we are now. SPDX License List needs a full name and a short
identifier to be consistent with the protocols that we have used so far; the
short identifier being more critical. We have also tried to conform with the
wishes of the license author (or license author representative, as in this
case) as well.
The addition of this license does not raise any compelling reason to change
existing short identifiers of licenses that have long been on the SPDX License
List here. This license is like others already on the list that use some aspect
of one of the BSD licenses and builds upon that. We have a pattern of short
identifiers for such a situation, so we ought to carry on that pattern as that
is what people will expect and being consistent is key! Along the same lines,
considering that “+” and “with” (as well as “or” and “and”) are license
expression operators, we aim to avoid using these in a license short identifier
as that would obviously cause confusion (and in full names to some extent).
Hence: the suggestion was/is:
Short identifier: BSD-2-Clause-Patent
(patent can be capitalized or not, but we have capitalized
other such words in BSD* short identifiers, so I’d vote for being consistent
there too. I don’t really see any reason for something different here and it
seems like we have some amount of consensus here, so can we call this done and
dusted?)
Full name: BSD 2-Clause Patent
(this would be consistent with other full names on the SPDX
License List. Note, the full name is not as critical as this is generally not
used in the same was as short identifiers, however consistency here is also
nice for viewing on the list, etc. I see that OSI has listed the full name as
“BSD+Patent” - I’d urge McCoy and OSI to reconsider this as, even though it’s
not a short identifier, it could cause confusion due to the “+” sign being
used.
Note: OSI now lists the full name for BSD-3-Clause as: "3-Clause BSD License",
whereas SPDX has the full name as: "BSD 3-clause "New" or "Revised” License”
SPDX choose that name as following the lead of OSI and how they listed the full
name on their list of licenses circa 2011 when OSI adopted the SPDX
identifiers:
https://web.archive.org/web/20110605024926/http://www.opensource.org/licenses/alphabetical
<https://web.archive.org/web/20110605024926/http://www.opensource.org/licenses/alphabetical>
I don’t know why OSI has since changed the full names, but again, I don’t think
the full name is as critical (especially in order of the words) so long as it
is sensibly recognizable. If OSI was to follow it’s own current naming
convention for BSD licenses, it might use "2-Clause BSD plus Patent License” or
something along those lines.
So, can we:
1) align on the short identifier; and
2) come up with a full name that is either the same or reasonably similar on
both lists, and consistent with the pattern as evidenced on both lists (and
make McCoy happy)?
Remember the goal here is easy, consistent, and reliable identification of
licenses.
Thanks,
Jilayne
SPDX Legal Team co-lead
opensou...@jilayne.com
> On Jun 2, 2017, at 3:51 PM, Richard Fontana <font...@opensource.org> wrote:
>
> On Fri, Jun 02, 2017 at 05:16:01PM -0400, Wheeler, David A wrote:
>> J Lovejoy:
>>> Specifically, when adding other BSD-x-Clause licenses, we have tried to
>>> follow the same pattern for the identifiers as it aids in identifying what
>>> exactly the license is, which I think everyone finds helpful! Hence the
>>> use of BSD-x-Clause-<extra> was intentional and thus, why I suggested such
>>> a pattern here.
>
> I think it is possible that this effort to systematize the identifiers
> for textually-related licenses, if taken too far, can actually cause
> greater confusion or have other questionable unintended
> consequences. One case where I worry this is happening is the
> so-called Clear BSD license, which SPDX calls "BSD-3-Clause-Clear".
>
>> I agree, I think something like "BSD-2-Clause-Patent" would be the better
>> choice:
>> * It's more consistent with the other licenses
>> * All the existing tools can handle that, even if they can only handle
>> identifiers (not expressions)
>> * Using "-with-" is hard to distinguish from the operator "... WITH ..."
>> when spoken
>> * Using "...plus..." is hard to distinguish from terminating "+" when spoken
>>
>> I hope that SPDX & OSI will agree on a short name, too...!
>
> Well, OSI doesn't have a notion of an official, OSI-endorsed short
> name. OSI has been prominently noting the SPDX short identifiers on
> the opensource.org web pages for the licenses and that commitment
> should continue. I don't think the OSI should do more than that,
> though.
>
> Richard
>
_______________________________________________
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal
