Re: ANTLR-PD
Thanks Till for reporting the issue and Steve for looking into it. My first reaction would be that the two texts, ANTLR with additional license and ANTLR without, are legally different licenses (with different effects which are important for the reasons Till mentioned), and should therefore be added as a new version of the ANTLR license rather than added as optional matching text to the original. What do others think? Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Tue, Jun 23, 2020 at 8:36 AM Steve Winslow wrote: > Hi Till -- taking a closer look, it seems that the language you cited was > added to the original ANTLR 2 license sometime later, which is probably why > it isn't in the license list version. > > Looking at the Wayback Machine, > http://web.archive.org/web/20130401024631/https://www.antlr2.org/license.html > shows that at least as of April 2013 the ANTLR 2 License did not include > that additional paragraph. I haven't done a deeper dive yet to figure out > when it was subsequently added. > > Given that, I'd be inclined to add it to the ANTLR-PD markup but to mark > it as optional, so that it would match whether or not that paragraph is > present. > > Thanks, > Steve > > On Tue, Jun 23, 2020 at 8:33 AM Steve Winslow via lists.spdx.org > wrote: > >> Thanks for flagging this, Till. I've added an issue in the >> license-list-XML repo to track this at >> https://github.com/spdx/license-list-XML/issues/1056. >> >> I don't know the history of this one myself, but it looks like that >> language had been omitted prior to when the license list was first brought >> into source control (see >> https://github.com/spdx/license-list-XML/commits/master/src/ANTLR-PD.xml). >> I expect it should be added into the ANTLR-PD markup for the reasons you >> mentioned. >> >> Best, >> Steve >> >> On Tue, Jun 23, 2020 at 5:33 AM Till Jaeger via lists.spdx.org > jbb...@lists.spdx.org> wrote: >> >>> Hello list, >>> >>> I just found out that there is a deviation from >>> https://spdx.org/licenses/ANTLR-PD.html#licenseText to the linked text >>> from >>> http://www.antlr2.org/license.html which contains the following >>> language: >>> >>> "In countries where the Public Domain status of the work may not be >>> valid, >>> the author grants a copyright licence to the general public to deal in >>> the >>> work without restriction and permission to sublicence derivates under the >>> terms of any (OSI approved) Open Source licence." >>> >>> From the perspective from EU law this is an extremely important part >>> since >>> it makes clear that a unrestricted license is intended if PD does not >>> work. >>> This avoids (always disputable) interpretation of the PD text. >>> >>> Is there any reason for the omission? Could the text be added? >>> >>> Best regards, >>> >>> Till >>> >>> -- >>> Dr. Till Jaeger >>> Certified Copyright and Media Law Attorney >>> >>> >>> JBB Rechtsanwälte >>> Jaschinski Biere Brexl Partnerschaft mbB >>> Christinenstraße 18/19 | 10119 Berlin >>> Tel. +49.30.443 765 0 | Fax +49.30.443 765 22 >>> Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR >>> 609 B >>> www.jbb.de >>> >>> >>> >>> >> >> -- >> Steve Winslow >> Director of Strategic Programs >> The Linux Foundation >> swins...@linuxfoundation.org >> >> > > -- > Steve Winslow > Director of Strategic Programs > The Linux Foundation > swins...@linuxfoundation.org > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2842): https://lists.spdx.org/g/Spdx-legal/message/2842 Mute This Topic: https://lists.spdx.org/mt/75056685/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Validate license cross references: New fields to be added
Hi Smith, Thanks for your well-laid-out email and your GSoC proposal. Trying to think about this from the perspective of the LicenseListPublisher repository over time, I would imagine the validity and other status of links could change over time. Links can linkrot, http-302 forwards can differ one day to the next, and the license text presented in HTML at a specific URL could be, and sometimes is, altered -- either with or without explicitly versioning the license. I think this necessitates some way of recording or representing validity information as a point-in-time, at minimum with a lastChecked value (e.g., UTC). There may be use cases for representing validity over periods of time, for example: - Time-series: (in daily checks tagged with UTC): valid-valid-valid-invalid-invalid-valid - Last-known-modified: perhaps lastChecked and lastChanged so that one could say "this was checked every week since X date and hasn't changed) - Other: other time-related information that tooling providers might want Then, I wasn't sure if isValid represented a valid regex-matchable URL (which presumably could be local, or more likely, corporate intranet), or both validly-formed according to regex and accessible from [some place on] the global internet. In theory that might depend on DNS, firewall configurations, or both, which are subject to change or manipulation to e.g. mitigate DDoS, find the physically closest webserver for a CDN, or block specific IPs sending malicious traffic. When it comes down to the "bits on the wire," the server has the option whether and how to respond to a request, and the server can (and occasionally does) make its decision based on these types of connection metadata describing the "from" side of the connection. So in theory it may make sense to include things like the source IP address of the system performing the validation attempt. That raises privacy issues, although if it came from a Linux Foundation system (or something similar), then hiding the validating system's IP address wouldn't necessarily be a requirement. So it may make sense to evaluation these kinds of contextual data points, along with clarifying in the isValid name or definition which validity-check you mean for it to represent. At minimum, it's worth thinking through these things and how we would deal with the edge cases introduced by relying on DNS and http to perform what is ultimately a connection-based point-in-time check. Best, Brad Edmondson PS: Personally I am not in favor of SPDX tracking the validity of license-text links, but then again I am coming at this as a contributor on the SPDX-legal side of things, and not on the SPDX tech team nor a frequent user of tooling. If the tech team is happy with this idea generally, and with fully owning the process and collected data on the LicenseListPublisher side, then I would have no objection from the legal side. (Also, of course, I only represent my own view and not the official or finalized position of the legal team.) -- Brad Edmondson, *Esq.* brad.edmond...@gmail.com On Wed, Jun 17, 2020 at 6:31 AM Smith Tanjong Agbor wrote: > Hi all, > > I am working on a Google Summer of Code project that emanates from this > discussion/issue > <https://github.com/spdx/LicenseListPublisher/issues/60#issuecomment-570511697>; > concerning the validation of license cross references. Here is a link to > my GSOC proposal > <https://docs.google.com/document/d/10RlmmsnJ7suDudjgugHMZkOOa-1IsY2Bv_Ew_tgzpv4/edit> > . > > The focus is on improving the LicenseListPublisher > <https://github.com/spdx/LicenseListPublisher> repository to have > generated license data <https://github.com/spdx/license-list-data> updated > with fields on the validity of the crossref, among others. > > Inorder to do this, the structure of the crossref shall change(in some > cases, eg JSON), and in others, there shall be additional tags. In general > the following are fields which shall be added to the crossrefs: > > *"isValid": true/false,* > Indicates whether or not the crossref url is a valid url (ex: not some > local file link) > > *"isWayBackLink": true/false,* > Indicates whether or not the url is a link from a previous version(wayback > machine) of the site(where the license is located) > > *"extraText": true/false,* > Indicates whether or not the license from the url has extra text in its > description when compared to the license description in the current file. > > "isMatch": true/false, > Indicates whether or not the license from the url link matches(perfectly) > the license description in the current file. > > "url": "http://landley.net/toybox/license.html;, > This is the url of the license text/description > > > *"isDead": true/false* > I
ABA Open-Source Committee: John Lyon (SSPL/Commons Clause) on Thurs. 5/9 @ 2pm ET
Hi all, There is a call with the American Bar Association's Open-Source committee next Thursday, May 9 at 2:00 PM (ET), when they host John Lyon and a discussion of the SSPL/Commons Clause. I don't know John, nor anyone on the OSI, and I'm only familiar with the SSPL/Commons Clause from a distance. But I still thought I would share, since this has the potential to be a very interesting discussion. Details below: Best, Brad --- *What:* ABA Open-Source Committee Meeting: *When:* May 9, 2019 from 2:00 PM to 3:00 PM (ET) *Where:* Dial in: 1-800-925-7671 | Passcode: 4576326 Proposed Agenda: * Presentation: John Lyon will lead a discussion/presentation on the OSS licenses and related issues such licenses are intended to address as described in the following article: https://techcrunch.com/2018/11/29/the-crusade-against-open-source-abuse/ * OSS Committee Communication * Upcoming Webinars * Other Committee Business * Opportunity to share ideas and information -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2591): https://lists.spdx.org/g/Spdx-legal/message/2591 Mute This Topic: https://lists.spdx.org/mt/31480114/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Verify new license text for libpng-2.0
Hi all, I've added a PR #755 [1] for libpng 2.0, but realized we hadn't explicitly said on the legal call whether this was just going to be the new text (v2 only), or the full text now in the license file[2] (at least, not that I can remember). I only added the new text in the current PR, which seems right to me scanning-engine-wise (and is also easier), but if anyone would like to argue for adding the full text, please do so on this thread or on the PR. Thanks, Brad [1] https://github.com/spdx/license-list-XML/pull/775 [2] http://www.libpng.org/pub/png/src/libpng-LICENSE.txt PS - Trying out the manual URLs thing I notice all the developers doing (presumably so the text itself is more readable). Is this the right way to do it? -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2551): https://lists.spdx.org/g/Spdx-legal/message/2551 Mute This Topic: https://lists.spdx.org/mt/30137417/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Introducing myself
Different Brad here (for those just joining the SPDX discussion). I'm also in favor of considering open source hardware licenses, and look forward to the discussion about guidelines. Bradley, I'm also curious as to what is missing, in your view. Thanks all, Brad Edmondson sent from my mobile device -- Brad Edmondson, Esq. 512-673-8782 | brad.edmond...@gmail.com On Wed, Oct 31, 2018, 18:22 J Lovejoy Hi Bradley, > > Are you referring to the remaining issue, as discussed here: > https://github.com/spdx/license-list-XML/issues/618 ? > > We did change the full names, as I think you raised (e.g., unproved and > international). I believe the remaining issue has to do with other language > translations? (a larger issue that impacts more than just CC licenses, to > be fair) > > Jilayne > > On Oct 27, 2018, at 11:29 PM, Bradley M. Kuhn wrote: > > J Lovejoy wrote: > > we already include all the CC licenses > > > While I'd love to see all the CC licenses included, they aren't. :) (Not > trying to open that discussion again -- just wanted to correct the typo > Jilayne made there.) > -- > Bradley M. Kuhn > > Pls. support the charity where I work, Software Freedom Conservancy: > https://sfconservancy.org/supporter/ > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2440): https://lists.spdx.org/g/Spdx-legal/message/2440 Mute This Topic: https://lists.spdx.org/mt/27459493/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: New License Request: +CAL Software License
Thanks Sally, really interesting. I've created an issue here[1] where the SPDX legal team will assess the license, but in order to best make that assessment, we have a few questions in the meantime: 1. Can you point us to some examples of projects or works that are using this license? We try to represent open-source software as it is actually used "in the wild," so usage in a project is a requirement for being added to the SPDX License List. 2. Would it be possible for CAL to add a version number to this license? There may come a time where you wish to revise it and release an updated license text, and that is a lot more straightforward if you are going from CAL-1.0 to CAL-1.1 or CAL-2.0. We look to the license author to specify their versioning and to be transparent when changes are made to the text by bumping the version number. 3. Do you have any objection to our labeling and titling the license CAL instead of +CAL? The + character has a special meaning in SPDX license expressions, and is not allowed in SPDX IDs. 4. Please let us know what OSI says after its review. Thank you for your submission, and please check or follow the Github issue for progress on this license request. Best, Brad Edmondson SPDX Legal Team Volunteer [1] https://github.com/spdx/license-list-XML/issues/670 -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, Jul 12, 2018 at 1:10 PM Sally Mindrebo < sally.mindr...@corpaccountabilitylab.org> wrote: > 1) License Name: +CAL Software License > > 2) Short Identifier: +CAL > > 3) URL: https://legaldesign.org/cal-software-license > > 4) OSI Approval: Submitted and under review > > 5) Why the +CAL License?: There are no existing licenses that (1) expand a > common law duty of care across the supply chains in which the copyrighted > work is used and (2) provide victims of abuse by corporations with > third-party beneficiary standing to enforce the copyright license. These > two features are unique to the CAL license, which otherwise operates with > the same legal logic as the GNU General Public License. Accordingly, this > is a new special purpose license intended for users who would like to > create copyrighted works that repair distorted and unjust market > structures, in line with the ethics and values of certain copyright > creators. > > > -- > *Sally Mindrebo* > *Lead Communications Designer, Corporate Accountability Lab > <https://www.legaldesign.org>* > 317.501.0544 *| *205 W. Monroe St. Chicago, IL > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2338): https://lists.spdx.org/g/Spdx-legal/message/2338 Mute This Topic: https://lists.spdx.org/mt/23290149/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: New License/Exception Request: Exception - Font-Embedding
Hi all, Not having heard a response re: versioning, we discussed on the SPDX legal call today and agreed <https://github.com/spdx/license-list-XML/issues/616#issuecomment-393596266> to version by date. This will be included in the 3.2 release of the SPDX License List, slated for the end of June. Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, Apr 19, 2018 at 10:49 PM, Brad Edmondson wrote: > Hi Stefan, > > Apologies for the multiple messages, but I meant to ask whether you > personally were the author of the exception text, or whether you knew who > the author was or how to get in touch with them. > > The purpose of this contact would be to ask whether the author of the > exception text could institute a version number for the text, such that if > they were to ever change the text itself, they would explicitly indicate > that by bumping the version number. This would be upstream (from our > perspective) and allow us to call the current text something like "AGPL-3.0 > font exception PS-PDF *v1.0.*" However, we can't really call it "1.0" > without verifying with the author that they (the author) intend it to be > "1.0" (or 0.95 or 2.2 or whatever) and that they will indicate any changes > with a bump to 1.1 or a 2.0 (which could subsequently be added to the SPDX > License List exceptions, and whose name could be distinguished by version > number). Absent an author's version number, we will probably fall back on > referencing the earliest known date the exception text was used, which in > this case would result in a name something along the lines of "AGPL-3.0 > font exception PS-PDF 20170817" (mmdd from here > <https://github.com/ArtifexSoftware/urw-base35-fonts/commit/9927f3ca634ebb2e02caecee9b4414218dc994e7#diff-9879d6db96fd29134fc802214163b95a> > ). > > Thank you and please let us know within the next week if you can provide > any further information that will help clarify versioning. > > Best, > Brad Edmondson > > -- > Brad Edmondson, *Esq.* > 512-673-8782 | brad.edmond...@gmail.com > > On Thu, Apr 19, 2018 at 2:43 PM, Brad Edmondson > wrote: > >> Hi Stefan, >> >> Thank you for this license request. It has been approved here >> <https://github.com/spdx/license-list-XML/issues/616> and will be added >> to the next release of the SPDX License List. >> >> Best, >> Brad >> >> -- >> Brad Edmondson, *Esq.* >> 512-673-8782 | brad.edmond...@gmail.com >> >> On Tue, Feb 27, 2018 at 10:11 PM, Stefan Brüns < >> stefan.bru...@rwth-aachen.de> wrote: >> >>> Hi, >>> >>> the URW Base 35 fonts are provided under the AGPL-3.0-only license with >>> an >>> embedding exception: >>> >>> https://github.com/ArtifexSoftware/urw-base35-fonts/blob/master/LICENSE >>> --- >>> The font and related files in this directory are distributed under the >>> GNU AFFERO GENERAL PUBLIC LICENSE Version 3 (see the file COPYING), with >>> the following exemption: >>> >>> As a special exception, permission is granted to include these font >>> programs in a Postscript or PDF file that consists of a document that >>> contains text to be displayed or printed using this font, regardless >>> of the conditions or license applying to the document itself. >>> --- >>> >>> It is similar to the Font-exception-2.0, although the latter >>> specifically >>> refers to the GPL, not AGPL. >>> >>> Kind regards, >>> >>> Stefan >>> >>> -- >>> Stefan Brüns / Bergstraße 21 / 52062 Aachen >>> home: +49 241 53809034 mobile: +49 151 50412019 >>> ___ >>> Spdx-legal mailing list >>> Spdx-legal@lists.spdx.org >>> https://lists.spdx.org/mailman/listinfo/spdx-legal >>> >>> >> > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License/Exception Request: Exception - Font-Embedding
Hi Stefan, Thank you for this license request. It has been approved here <https://github.com/spdx/license-list-XML/issues/616> and will be added to the next release of the SPDX License List. Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Tue, Feb 27, 2018 at 10:11 PM, Stefan Brüns <stefan.bru...@rwth-aachen.de > wrote: > Hi, > > the URW Base 35 fonts are provided under the AGPL-3.0-only license with an > embedding exception: > > https://github.com/ArtifexSoftware/urw-base35-fonts/blob/master/LICENSE > --- > The font and related files in this directory are distributed under the > GNU AFFERO GENERAL PUBLIC LICENSE Version 3 (see the file COPYING), with > the following exemption: > > As a special exception, permission is granted to include these font > programs in a Postscript or PDF file that consists of a document that > contains text to be displayed or printed using this font, regardless > of the conditions or license applying to the document itself. > --- > > It is similar to the Font-exception-2.0, although the latter specifically > refers to the GPL, not AGPL. > > Kind regards, > > Stefan > > -- > Stefan Brüns / Bergstraße 21 / 52062 Aachen > home: +49 241 53809034 mobile: +49 151 50412019 > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License Request: TU-Berlin
Hi ARW, Thank you for these license requests. They have been approved here <https://github.com/spdx/license-list-XML/issues/636> and will be added to the next release of the SPDX License List. Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Fri, Apr 6, 2018 at 1:46 PM, Brad Edmondson <brad.edmond...@gmail.com> wrote: > Thanks ARW and Dennis, > > Issue for this opened (and you can track progress) here: > https://github.com/spdx/license-list-XML/issues/636 > > The legal team will assess and decide on these licenses there. We have > just finalized the new licenses for the 3.1 release of the list, so this > will likely need to wait until the release after that. > > Thank you, > Brad Edmondson > > > > -- > Brad Edmondson, *Esq.* > 512-673-8782 | brad.edmond...@gmail.com > > On Fri, Apr 6, 2018 at 12:30 PM, Dennis Clark <dmcl...@nexb.com> wrote: > >> Hi Legal Team, >> >> For the record, the proposed license is currently recognized by ScanCode >> as tu-berlin. >> >> https://github.com/nexB/scancode-toolkit/blob/4e63a6775a895f >> dec5a3a53f96013399fa34b1b7/src/licensedcode/data/licenses/tu-berlin.yml >> >> Regards, >> Dennis Clark >> >> >> On Thu, Apr 5, 2018 at 6:09 PM, A. Wilcox <awil...@adelielinux.org> >> wrote: >> >>> Proposed Full Name: >>> >>> Technische Universitaet Berlin License >>> >>> Permissive Technische Universitaet Berlin License [???] >>> >>> >>> Proposed Short Identifier: >>> >>> TU-Berlin-1.0 >>> >>> TU-Berlin-2.0 >>> >>> >>> URL references: >>> >>> 1.0: >>> >>> http://alpha.tmit.bme.hu/pub/audio/gsm-1.0/copyrigh >>> https://github.com/swh/ladspa/blob/master/gsm/COPYRIGHT >>> >>> >>> 2.0: >>> >>> https://github.com/CorsixTH/deps/blob/master/licences/libgsm.txt >>> https://answers.launchpad.net/ubuntu-leb/oneiric/+source/lib >>> gsm/+copyright >>> >>> >>> OSI-approved? >>> >>> No. >>> >>> >>> Packages using this license: >>> >>> gsm / libgsm >>> >>> via inclusion of gsm code: ladspa, rplay, speex, some builds of vorbis >>> >>> >>> Date: >>> >>> 1.0: 15-Sep-1992 >>> 2.0: 05-Apr-2009 >>> >>> >>> Explanation (non-normative): >>> >>> I did not find any reference to these licenses in the tracking page. I >>> have only seen this used in gsm; I do not know if the university has >>> released other open source projects. (No further packages were found >>> searching for key, unique phrases in DuckDuckGo nor Google nor GitHub.) >>> >>> Fedora seems to consider this "MIT", but other than some similarities in >>> 2.0 to MIT/PetSC and MIT/HP, this license has nothing more than a >>> spiritual relation to MIT in my opinion. >>> >>> If this should instead be considered a MIT variant, I would be willing >>> to resubmit as that. >>> >>> Thanks for your consideration. >>> >>> >>> Best, >>> --arw >>> >>> -- >>> A. Wilcox (awilfox) >>> Project Lead, Adélie Linux >>> http://adelielinux.org >>> >>> ___ >>> Spdx-legal mailing list >>> Spdx-legal@lists.spdx.org >>> https://lists.spdx.org/mailman/listinfo/spdx-legal >>> >>> >> >> ___ >> Spdx-legal mailing list >> Spdx-legal@lists.spdx.org >> https://lists.spdx.org/mailman/listinfo/spdx-legal >> >> > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Past and preview License List releases (was: 3.1 release)
I'm in favor of solving this (making html available for old versions of the license list). I think it will help with adoption too, especially as we move back to a more frequent release cadence. Perhaps add to the errata issue? Or file a separate issue? -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Fri, Mar 23, 2018 at 4:00 PM, W. Trevor King <wk...@tremily.us> wrote: > On Fri, Mar 23, 2018 at 12:14:03PM -0700, Philippe Ombredanne wrote: > > We are pushing new versions of the license lists but we are NOT > > keeping online the previous versions. They are only in git repos. > > I think it would help a lot adopters to have all the versions (at > > least starting with 2.6 and up) available online on the license list > > web page(s). > > An easy way to do this would be to push our website HTML (e.g. [1]) to > the gh-pages branch of license-list-data. I've mocked that up in > [2,3], and you can see old versions of the list in [4,5,…]. > > > It could also make sense as a further refinement to publish a > > preview of a new version list for comments/heads up before it > > becomes the latest. > > You can do this with the gh-pages approach too [6,7], although someone > (possibly a robot) would need to bump gh-pages after each master > commit (or at least whenever you wanted to refresh the preview). > > If this approach seems useful, someone with license-list-data write > access just needs to push my gh-pages branch [8] to the main > repository. > > Cheers, > Trevor > > [1]: https://github.com/spdx/license-list-data/blob/v2.6/website/0BSD > [2]: https://wking.github.io/license-list-data/ > [3]: https://github.com/wking/license-list-data/commit/ > c112d15c76e8c2f0a5c15eca8719a81a765a631f > [4]: https://wking.github.io/license-list-data/v2.6/website/ > [5]: https://wking.github.io/license-list-data/v3.0/website/ > [6]: https://wking.github.io/license-list-data/dev/website/ > [7]: https://github.com/wking/license-list-data/commit/ > 1f7322894a9e3a2a233eca9250549d3cd59f5eeb > [8]: https://github.com/wking/license-list-data/tree/gh-pages > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: [spdx-tech] Proposal for a new project idea for GSoC - request quick response from legal and tech teams
Thanks Gary, I think this is interesting, but I wonder if we can get the same benefit for a lot less work if we whip up a little documentation on how to use a couple of existing XML editors with the XSD schema file (I haven't even tried to get this working but assume it is possible). That wouldn't give us a web-based dev environment, but I don't think we need that if we can get the changed made and new files added that we need. (Actually now that I mention web-based dev, potentially we could document how to use an existing web-based IDE <https://en.wikipedia.org/wiki/Web_integrated_development_environment#See_also> to edit the repo.) What do people think of going in that direction? Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, Mar 22, 2018 at 3:52 PM, Krys Nuvadga <tetechri...@gmail.com> wrote: > Hi Gary, > > It's a genuine concern you just raised. But I'll rather the milestones for > the the two projects be spell out clearly and then we can pick two students > to work on them. I think we already have some proposals for the License > Submittal project that make mention of the including the License XML > editor. Adding that with Django the separate idea can be be developed on > the existing Online tool as Django apps, just to avoid the code overlap and > not spread resources unnecessarily. > > Krys Nuvadga > > > On Thu, Mar 22, 2018 at 8:33 PM, <g...@sourceauditor.com> wrote: > >> *Background*: The GSoC project idea Add New License Submittal Feature to >> Online Tool is quite popular with students >> <https://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeas#Add_New_License_Submital_Feature_to_Online_Tools> >> – at least 4 proposals are in progress for this one project. Since we can >> only select one of the proposals, I would like to add another project idea >> of similar scope and usefulness to the community as an alternative project >> for students. The deadline for submittals is coming up quickly – next >> Tuesday 27th! >> >> >> >> One concern I have with the proposal is there is some overlap in code >> functionality with the existing license submittal project idea. I >> personally think it would be fine to have this overlap and allow some >> duplication of code for the two projects. Once the projects are complete, >> we could have a separate task to refactor and reduce the duplication. >> >> >> >> *Action requested*: For the legal team – please review the proposal >> below and reply if you feel this tool proposal would be useful by end of >> day Friday. For the technical team, please provide feedback if you feel >> this proposal has too much technical overlap with the existing proposals. >> >> >> >> *Proposal*: >> >> Add a License XML Editor >> >> >> >> The SPDX license list (see https://spdx.org/licenses/) is maintained by >> the SPDX legal team. The source for the license list is maintained in the >> SPDX license-list-XML github repository (https://github.com/spdx/licen >> se-list-XML). Making changes to the license requires manually editing an >> XML file which can be challenging for contributors not familiar with XML. >> >> An online program could be created which would take as input a license >> XML file uploaded from the client machine to the server. The editor would >> allow editing of all of the XML fields as well as the optional and >> alternate text properties. The editor would then save the changes and >> allow the updated file to be downloaded to the user’s client machine. An >> optional feature would be to allow the input to be an existing license in >> the repository and automatically create a pull request with the changes. >> Another optional feature would be to allow copy/paste of the license XML >> text into a text pane rather than uploading/downloading the file. >> >> This project could be implemented in Python in the existing online tools. >> Skills Needed >> >> ·Development skills in the Python language >> >> ·Knowledge of Git >> >> ·Understanding of XML >> Available Mentors >> >> Gary O'Neall <g...@sourceauditor.com> Rohit Lodha >> <rohit.lodha...@gmail.com> >> >> >> >> >> >> - >> >> Gary O'Neall >> >> Principal Consultant >> >> Source Auditor Inc. >> >> Mobile: 408.805.0586 <(408)%20805-0586> >> >> Email: g...@sourceauditor.com >> >> >> >> ___ >> Spdx-tech mailing list >> spdx-t...@lists.spdx.org >> https://lists.spdx.org/mailman/listinfo/spdx-tech >> >> > > > -- > krys Nuvadga > Piar, Inc. > > ___ > Spdx-tech mailing list > spdx-t...@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-tech > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Some problems discovered with CC BY-SA license identifiers
Thanks Bradley and David, These are good points, which I have rolled into a Github issue for us to address here: https://github.com/spdx/license-list-XML/issues/618 Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Tue, Mar 13, 2018 at 10:15 AM, Wheeler, David A <dwhee...@ida.org> wrote: > Bradley M. Kuhn: > > I therefore suggest two changes to the SPDX License List: > > > > * Change existing Full Names to: > > "Creative Commons Attribution Share Alike 4.0 International" > > for the 4.0 version and, > > "Creative Commons Attribution Share Alike Unported" > > for the older ones. > > > >It seems that would be an uncontroversial change -- it just involves > >adding "International" and "Unported" into the Full Name field. Does > >anyone have an argument why that *shouldn't* be done? > > I agree. > > > * It *would* surely be controversial to add *every* version of *every* > > jurisdiction-specific CC license in the SPDX license list. Instead > of > > suggesting that, for the moment I suggest that "-Unported" should be > > added to identifier for the pre-4.0 ones (i.e., "CC-BY-SA-3.0" > becomes > > "CC-BY-SA-3.0-Unported") so that no is confused by this situation. > > I disagree, for several reasons. > * Version numbers are normally at the end. > * In practice, I think in almost all cases what is intended is the > *unported*/*international* version, since these materials normally go out > around the world. SPDX license names are long enough; the "short" version > should be the "normal" version. > * This creates yet-another transition problem, and in this case I think an > unnecessary one. Many people already use CC-BY-SA-3.0 to mean the unported > one, so let's just clarify that. > > I actually do *NOT* think it'd be very controversial to add all the > jurisdiction-specific CC licenses that are actually used: > * There's an easy stopping requirement: You have to show that something > was actually *distributed* under that license. Almost all of the possible > license + countries combinations have never been used. > * There are SPDX license identifiers for licenses used by relatively few > programs. > * You could create a convention, e.g., -PORTED-< ISO 3166-1 > alpha-2 country code>-. The SPDX license identifier list > could even standardize that as a convention, instead of listing them all > out. A few lines of text... and you're done. E.g., the US ported version > would be "CC-BY-SA-PORTED-US-3.0". I add the "-PORTED-" because "SA" means > "Saudi Arabia"; without some special keyword it wouldn't be obvious what > "CC-BY-SA" meant. I suggest the 2-character code, that's what most people > use. We could use the "2-character codes as assigned by the Internet > Assigned Numbers Authority". The alpha-2 code for the UK is "GB", but "UK" > is used in domain names & it might be clearer to use that. > > --- David A. Wheeler > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: License list release 2.7 or 3.0? (was: update on license list release)
I don't recall any specifics, just that in Nov/early Dec the tech team told us on a call that it was contemplating some potentially backward-compat-breaking changes. Not sure if those were ultimately agreed upon or what they were, but iirc the legal team took it as received wisdom and bumped to 3.0 (tech thought that the changes were likely enough and likely-big-enough that the spec would need to be 3.0). The tech team would have more people who can speak to the specifics, esp. Kate and Alexios (and Gary). Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Fri, Dec 29, 2017 at 2:41 PM, W. Trevor King <wk...@tremily.us> wrote: > On Fri, Dec 29, 2017 at 02:27:19PM -0500, Brad Edmondson wrote: > > We discussed on the Dec. 7 call and landed on 3.0 -- I think partly > > because the spec was leaning toward 3.0 as well… > > Are we planning on breaking backwards compat with the spec? That > would be fun for me when I'm wearing my spec-editor hat, but less fun > for me when I'm wearing my SPDX-consumer hat ;). Are there any > breaking changes in particular that are driving a 3.0 spec? > > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: License list release 2.7 or 3.0? (was: update on license list release)
We discussed on the Dec. 7 call and landed on 3.0 -- I think partly because the spec was leaning toward 3.0 as well and we wanted to track somewhat closely. https://wiki.spdx.org/view/Legal_Team/Minutes/2017-12-07 Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Tue, Dec 26, 2017 at 4:00 PM, W. Trevor King <wk...@tremily.us> wrote: > On Thu, Dec 21, 2017 at 11:44:44PM -0700, J Lovejoy wrote: > > A handful of us have been working away on the 3.0 release of the > > SPDX License List. > > I think this can be a 2.7 release, with 3.0 to follow if/when some > currently-deprecated identifiers are finally dropped. Are there any > breaking changes being made? The spreadsheet → XML transition is big, > but shouldn't impact most downstream consumers (was the spreadsheet > format ever described as a stable, authoritative list API?). We don't > explicitly claim Semantic Versioning [1] for the list, but I don't > want to startle consumers with a major version bump if we don't expect > major consumer-side changes. > > Is there a 2.7 vs. 3.0 discussion somewhere where I can read up on the > existing discussion? Or is this email the beginning of that > discussion? > > Cheers, > Trevor > > [1]: https://semver.org/ > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Artifex v. Hancom reportedly reaches confidential settlement (GPL "Ghostscript" case)
Hi all, No other confirmation yet, but PRWeb is reporting <http://www.prweb.com/releases/2017/12/prweb14991130.htm> that the Artifex v. Hancom case has settled w/ undisclosed terms. The case had concerned <http://www.theregister.co.uk/2017/05/13/gnu_gpl_enforceable_contract/> dual-licensed PDF libraries called Ghostscript (separate from the GNU Foundation's GhostScript project), and was in the news this fall when a federal judge allowed <https://www.fsf.org/blogs/licensing/update-on-artifex-v-hancom-gnu-gpl-compliance-case-1> Artifex's claim that the GPL was an enforceable contract (not just a copyright license) to proceed past summary judgment. Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: update on only/or later etc.
Hi David, I think your points are good ones, but it seems to me they go to the separate issues of "file:detected license" and "package:concluded license." The clarity of the spec argument is aimed at making the "file:detected license" case more explicit, and if it leaves tools with NOASSERTION for "package:concluded license," then I think that's OK, no? Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Fri, Nov 17, 2017 at 10:35 AM, Wheeler, David A <dwhee...@ida.org> wrote: > J Lovejoy: > > > Do NOT add a identifier or operator, etc. for the > found-license-text-only scenario where you don’t know if the intent of the > copyright holder was “only or “or later” and are thus left to interpret > clause > > I disagree, sorry. > > > - we don’t need to solve this right now and we can always add this > option later > > - without adding a third option, we are in the same position we have > been in since the birth of the SPDX License List. incremental changes have > always been our go-to strategy; let’s take a first step to clarify the > current identifiers in a way that the FSF can get behind. If, for a later > release, we think we need this third option, then we can discuss that > further once we have some time under our belts with this change. > > No, this is the *reason* that there's a problem. The *reason* that > "GPL-2.0" isn't working is, in part, because it overloads two notions. > "GPL-2.0" is supposed to mean "Only 2.0" (per the spec) . But tools only > know "I saw a GPL-2.0 license", so how can they represent that > information? The obvious way is "GPL-2.0", so that same identifier can > mean "2.0 at least, and I don't know if there are other versions allowed". > That's not good. > > If we wait to "add this option later", "GPL-2.0-only" will probably have > morphed in *practice* into "GPL-2.0 at least, and I don't know if it's the > only version". So while everyone can congratulate themselves about the > clarity of the spec, very soon it will predictably be *unclear* in > practice. If we want to be able to express "exactly this version", we also > need to be able to represent "at least this version". > > --- David A. Wheeler > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: update on only/or later etc.
Wow! Hopefully this resolves this issue for the foreseeable future (as I think it should). I echo Karen's sentiments -- great work! As far as the next release, to my mind, the biggest open issue <https://github.com/spdx/license-list-XML/issues/327> is adding XML for the recently added licenses, which I think should be 2.6+. I haven't done a careful check, but based on a quick scan of the Google Sheets document <https://docs.google.com/spreadsheets/d/11AKxLBoN_VXM32OmDTk2hKeYExKzsnPjAVM7rLstQ8s/edit#gid=695212681>, that looks like it could be: - EPL-2.0 - EUPL-1.2 - *BSD-2-Clause-Patent (done)* - W3C-Software-2015 - *Unicode-DFS-2015 (done)* - *Unicode-DFS-2016 (done) * - *TCP-wrappers (done) * - *Net-SNMP (done) * And perhaps also some/all of the licenses still under review: - CDLA-Permissive-1.0 - CDLA-Sharing-1.0 - OSCAT Then we should add the accepted exceptions <https://docs.google.com/spreadsheets/d/11AKxLBoN_VXM32OmDTk2hKeYExKzsnPjAVM7rLstQ8s/edit#gid=0> : - *Linux-syscall-note (done)* - Bootloader-exception And *perhaps* the same for exceptions under review, although I'm not as familiar with these and they may be stale at this point. But as marked, these are "under review": - aptana-exception-3.0 - Cygwin-exception-2.0 - FOSS-License-exception - MySQL-Connector-ODBC-exception-2.0 - OCaml-exception - rrdtool-floss-exception-2.0 - sencha-exception-3.0 - trolltech-gpl-exception-1.2 - wolfcms-exception-2.0 - Zarafa-trademark-exception-3.0 Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, Nov 16, 2017 at 8:35 PM, Copenhaver, Karen <kcopenha...@choate.com> wrote: > There are so many things I admire about the people involved and the > process that has been followed to get to this proposal for consensus. Many > thanks for all Jilayne and Kate and so many others have done to bring SPDX > to a point that exceeds all of our expectations. > > > From: spdx-legal-boun...@lists.spdx.org [spdx-legal-boun...@lists.spdx.org] > on behalf of J Lovejoy [opensou...@jilayne.com] > Sent: Thursday, November 16, 2017 7:37 PM > To: SPDX-legal > Subject: update on only/or later etc. > > Hi All, > > Kate and I just had a call with Richard Stallman of the FSF to try and > come to a resolution everyone can be happy with, taking into consideration > the ask from the FSF and the many thorough discussions we’ve had on the > mailing list and calls. This is similar to an approach we discussed on the > last call, with one variation. As such, I’d like to propose the > followingath forward (again, using GPL-2.0 but for all GNU licenses): > > Deprecate the "GPL-2.0" identifier and add the word “only” for GPL version > 2 only, e.g., "GPL-2.0-only" > - this should not be problematic as it does not change the meaning of the > identifier. GPL-2.0 has meant ‘version 2 only’ since the SPDX License List > was born. We are simply adding explicit language for the identifier. No > backwards compatibility issues in terms of the meaning. > - we can do a “warning” for people using the deprecated identifier for a > period before “GPL-2.0" becomes invalid to give people a chance to update. > This will also encourage people who have been sloppy to fix their > sloppiness. > > Add GPL version 2 or later back to the SPDX License List as it’s own entry > with the short identifier of “GPL-2.0+” or “GPL-2.0-or-later” > - This would essentially put us in the same position we are now: with two > options - “only” and “or later” - it just alters how one gets there, where > one finds it > - this would also put both options back on the license list thus > highlighting that the GNU licenses provides these options more obviously > and hopefully providing a more overt encouragement to using one or the other > - the identifier here could be “GPL-2.0+” (same as always) or > “GPL-2.0-or-later” (differentiation from the + modifier might be better for > tooling?) - we can discuss which is better, FSF is fine with either. > - if we go with “GPL-2.0-or-later”, can take same approach with warning > re: “GPL-2.0+” then invalid? > > Keep the + modifier in the license expression language > - this allows use of + with other licenses as always, no change, no > backwards compatibility > > Do NOT add a identifier or operator, etc. for the found-license-text-only > scenario where you don’t know if the intent of the copyright holder was > “only or “or later” and are thus left to interpret clause 9 > - on the last call, we came up with two proposals that both incorporate 3 > options for each GNU license, see: https://wiki.spdx.org/view/ > Legal_Team/Minutes/2017-11-09<https://wiki.spdx.org/view/ > Legal
Re: signifigance of nested parenthesis with only ORs? (was: OpenJ9 license)
Thanks Bradley, I took Wayne's note to mean he thought it was more human-readable that way (with parens) for people working on his project, not that it would evaluate differently than a list of ORs with no parens. Best, Brad Edmondson -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, Oct 12, 2017 at 2:05 PM, Bradley M. Kuhn <bk...@ebb.org> wrote: > Wayne Beaton wrote on Monday, 2 October: > > (EPL-2.0 OR (LicenseRef-GPL-2.0-with-Assembly-exception OR GPL-2.0 > > with Classpath-exception-2.0)) OR Apache-2.0 > > > > I threw in the extra grouping because it felt like they needed to be > > together. > > Could you explain a bit further why the extra parenthesis grouping is > needed > when only ORs are involved? > > Looking at the SPDX spec at https://spdx.org/spdx- > specification-21-web-version, I see: > > >> For example, when given a choice between the LGPL-2.1 or MIT licenses, > a valid expression would be: > >> (LGPL-2.1 OR MIT) > > >> An example representing a choice between three different licenses would > be: > >> (LGPL-2.1 OR MIT OR BSD-3-Clause) > > It seems that the spec suggests that when you put a bunch of OR's together, > it should be: > > (EPL-2.0 OR LicenseRef-GPL-2.0-with-Assembly-exception OR GPL-2.0 with > Classpath-exception-2.0 OR Apache-2.0) > > The nested parens are covered in a later section, but only for combining > ANDs and ORs. > > What's the significance of the extra parenthesis in the case of only ORs? > It seems not to be covered in the spec at all. (If I just missed that > part, > someone please do point me to where it is covered.) Thanks! > -- > Bradley M. Kuhn > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New license proposal: Verbatim
Hi Marc, Great analysis, and I will echo Jilayne's call for you not to feel like you have to return to lurking. This is open-source, and to get to the best solution, we need everyone with thoughtful analyses and arguments to come forward. With respect to the copyright in the text of a license (the "Verbatim" question), I don't think this is an issue SPDX needs to worry about or to spec out how to describe in SPDX expressions. It's my understanding that there are varying opinions on the question of the copyrightability of a license text (or any legal contract). I tend to think no license text is protectable under copyright, but even assuming *arguendo* that it is protectable, recall that copyright protection is "thin" (as opposed to "thick" protection in patent or, less so, trade secret) and doesn't bar *all* copying/distributing/etc. SPDX arguably has an implied license for every open-source license, excepting perhaps those that are limited to a specific project or company. But more than that, SPDX's license database is almost certainly a fair use of the license text under copyright law. You can go through the four factors and all their sub-factors if you want to, but I think because SPDX is a meta-project to help identify the licenses in question, SPDX itself is non-profit, and there is not "market" (in the copyright sense) for original open-source license texts, I'd say the fair use case is pretty slam-dunk. TL;DR: I don't think we need to add licenses or change the spec to represent any potential copyright in license text, as I rate the risk to be minimal and we have a big enough challenge as it is with our primary goals of identifying licenses and describing licensed files & packages. Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Fri, Sep 8, 2017 at 5:28 AM, Marc Jones <m...@joneslaw.io> wrote: > Sporadic lurker, first time poster. > > Many licenses require you to include an exact copy of the license in the code > base as a condition of the license. So if for example a code base is license > under 3-Clause BSD then you have to "must retain the above copyright notice, > this list of conditions and the following disclaimer." Similarly in GPLv2 if > you are redistributing an exact copy of the code base you must "give any > other recipients of the Program a copy of *this* License along with the > Program." > > It is not clear to me that it makes sense to say a code base is both GPLv2 > and verbatim, simply because the text of the license is copyrighted and you > do not have permission to modify the license text. I don't actually think it > is much different from the 3-Clause BSD license regardless of if the 3-clause > BSD license is in the public domain. It seems to me that even if the 3-Clause > license is in the public domain, you still do not have permission to modify > it in a code base licensed under the 3-clause BSD license. Doing so would > violate a condition of the license to the code base. In which case the > simplest and most accurate thing to do would be to simple say that the code > base is 3-clause BSD. It both accurately states the license of the code and > your permissions to modify the 3-clause BSD file in that code base (i.e. you > aren't allowed to.) Similar argument could be made for GPL licensed programs > as well. > > >For license where we do not feel comfortable concluding a license, we > > >probably want to stop distributing local copies until we figure out>what > >license applies to them (or whether we think they are not>copyrighted, or if > >our complete copy of their text falls under fair>use, or whatever). > > The problem with not including local copies of licenses is that including a > local copy of licenses is actually a condition of a lot of licenses. So > essentially one would have to say that unless the copyright status of the > license text is clear, we can not use SPDX with that license. Which seems to > be entirely self defeating. And also I think taking the concern over a lack > of an explicit license on the license text itself too seriously. I think > there is a solid argument for implied license for all open source licenses to > at least copy them verbatim in a code base under that license. Certainly a > strong case for any license that has been approved by OSI. > > >>* In any case, I’m not sure we need to worry so much about identifying > *>>* the license of the license. > *>Why not? They're generally copyrightable content that we copy > and>distribute, just like code. > > If the point of SPDX is to accurately record the the license of the codebase, > then this just seems like a definitional issue: Is the license text of the > code base par
Re: License checking tool available
Still, as a first effort I really like this. -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Fri, Aug 4, 2017 at 2:30 PM, Michael Dolan <mdo...@linuxfoundation.org> wrote: > > On Fri, Aug 4, 2017 at 2:12 PM, <g...@sourceauditor.com> wrote: > >> When I tested the application, I used the text from the SPDX license list >> pages themselves which match. >> > > That makes sense then. I also tried a copy/paste from the OSI pages and > those didn't work either. > > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Test
Test reply, sent only to list (individual not CC'd). Matija, if you confirm that you see this reply then you should be good. -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, Aug 3, 2017 at 2:04 PM, Matija Šuklje <mat...@suklje.name> wrote: > I apologise for the noise. > > Only a simple test to see if after un- and re-subscribing to the list > makes me > receive the mails again. > > > cheers, > Matija > -- > gsm:tel:+386-41-849-552 > www:http://matija.suklje.name > xmpp: matija.suk...@gabbler.org > sip:matija_suk...@ippi.fr > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License/Exception Request: BTC License (BTC)
Hi Josh, I agree with Philippe here (SPDX looks to use "in the field" as a key factor in adding a license to the list), but I do in fact think your idea of inserting BTC or other crypto addresses in copyright and/or author statements is an interesting one. I hope you won't take this result as discouragement, but rather a win: most SPDX licenses (and not just ISC) are already compatible with your idea! Go forth and be merry, shout it from the rooftops, etc.! I will be interested to see how this goes, as I suspect a non-trivial number of FOSS developers like the idea of credit (somewhat similar to git "blame," yes?) and a simple, low-txn-cost replacement for begware that sometimes accompanies licenses (really, almost frictionless). I wish you luck! Best, Brad Edmondson -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Wed, Jul 12, 2017 at 6:01 AM, Josh Habdas <jhab...@gmail.com> wrote: > Thank you for this valuable information, Philippe. I will pursue your > advice. Thank you all for your time. > > On Wed, Jul 12, 2017 at 5:42 PM Philippe Ombredanne <pombreda...@nexb.com> > wrote: > >> On Wed, Jul 12, 2017 at 10:21 AM, Josh Habdas <jhab...@gmail.com> wrote: >> >> > For the license to receive adoption it needs to be on the SPDX License >> List. >> > I am but I small Fish in a large pond. >> >> Josh: you are getting this entirely backwards. >> >> Instead, for a license to be on the SPDX list it must have received >> adoption first. The purpose of the list is not to bless new licenses >> but to provide a shorthand for common, adopted licenses [1]: >> >> The SPDX License List is a list of commonly found licenses and >> exceptions >> used for open source and other collaborative software. >> >> The key word here is "commonly" And this is further developed on >> the same page. >> If you want a new license to be "open source"-approved, you should >> contact the OSI instead. >> >> > The ideal outcome is to provide a common template for a simple >> permissive >> > canonical crypto license to make it simple for users to add crypto >> wallet >> > addresses as mentioned in the Hacker Noon article. >> > >> > Ideally we can avoid license proliferation here but I need to have a new >> > template accepted for the copyright statement to show the proper way to >> use >> > it. Will that necessitate the creation of a unique new license text, or >> can >> > this be done creatively without causing a new license in terms? >> >> A copyright statement is a copyright statement , a license text is a >> license text. >> As much as you would like these two to be conflated in one, this is >> not the way things work as stated by posts in this thread. >> >> I think you have received a lot of valuable feedback and push back >> here on your idea. >> >> So go ahead and submit your new license idea at the OSI if you feel >> like it, though I consider this a terribly bad idea to submit a new >> text and this will unlikely help your new license to receive any >> adoption. Since there is really nothing novel, and you are eventually >> considering creating a new license text just for the purpose of having >> something different I doubt this would receive much consideration >> there too. >> >> You want to define a new way to use copyright statements creatively. >> So promote this but mixing this up with license texts and asking for a >> unique identifier does not make sense to me and to most on this list. >> There is not much more to say. >> >> [1] https://spdx.org/spdx-license-list/license-list-overview >> -- >> Cordially >> Philippe Ombredanne >> > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License/Exception Request: BTC License (BTC)
Hi Josh, I think the point here is that you can adopt your proposal of using using a BTC wallet address in the copyright-holder field without declaring a new license at all. Since the intent is to use the exact same terms as the ISC, why not just propose using wallet addresses in copyright or author fields of licenses already on the license list? It seems to me like you can just declare victory (compatibility) and run with it, yes? Best, Brad Edmondson -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Tue, Jul 11, 2017 at 12:00 PM, Josh Habdas <jhab...@gmail.com> wrote: > FYI - BTC just hit Hacker Noon. https://hackernoon.com/ > introducing-the-btc-license-28650887eb11 > > On Tue, Jul 11, 2017 at 2:04 PM Josh Habdas <jhab...@gmail.com> wrote: > >> My remaining question to Richard as to how many words I should change to >> make it a unique license, which it already is. >> >> On Tue, Jul 11, 2017 at 1:59 PM Jonas Smedegaard <jo...@jones.dk> wrote: >> >>> Quoting Josh Habdas (2017-07-11 04:47:30) >>> > Haven't heard back and joined the list. Sorry for the noise but is >>> > this request being tracked for discussion? >>> >>> You got a response from Richard Fontana, and you confirmed that this is >>> not a new license, only a new copyright holder. >>> >>> What is left to track or discuss further? >>> >>> >>> - Jonas >>> >>> -- >>> * Jonas Smedegaard - idealist & Internet-arkitekt >>> * Tlf.: +45 40843136 <+45%2040%2084%2031%2036> Website: >>> http://dr.jones.dk/ >>> >>> [x] quote me freely [ ] ask before reusing [ ] keep private >>> >> > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Feedback on SPDX and Legal Team overview for ABA subcommittee (by 3/1)
Hi all, Thanks for all your suggestions and attention to detail. I've incorporated them as best I can, and would like to offer a "release candidate" draft for final review if you would care to do so. It's at the same location: https://docs.google.com/presentation/d/1z4kQdpCjhMLgFUhWL5_U CK5wv8ztRXPcM_RDE3M5TYk/edit?usp=sharing Please leave any comments or suggestions by tomorrow evening 3/1. This deck will be presented <https://www.youtube.com/watch?v=WbSOvS60uWM> on Thurs. 3/2 and circulated to the relevant audience thereafter. Thanks again. Best, Brad PS - If these updates are helpful going forward, please feel free to use them in the SPDX resources slides or your own decks in future. -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Fri, Feb 24, 2017 at 12:14 AM, Brad Edmondson <brad.edmond...@gmail.com> wrote: > Hi all, > > I will be presenting an overview of SPDX and the SPDX legal team to the > Computer > Programs and New Technology > <http://apps.americanbar.org/dch/committee.cfm?com=pt035500> subcommittee > of the IP Law section > <http://www.americanbar.org/groups/intellectual_property_law.html> of the > American Bar Association next Thursday 3/2 at 2pm Eastern (right after our > legal call). There are typically 10-20 attorneys on this call, and my aim > is to educate them about OSS and SPDX, and potentially to inspire new > contributors to the legal team. > > I shared some notes > <https://docs.google.com/document/d/1gx6beTbh0TJ4l7BtDV3zWCSQb0FMh_K-5iq9C_mzji8/edit?usp=sharing> > for this presentation on a legal call a while ago, and got some good > feedback from Dennis and Paul, as well as an introduction to Jack. Since > then, I have integrated those notes into the handy SPDX overview slide deck > available at https://spdx.org/Resources and made a few tweaks of my own. > > The result is this presentation > <https://docs.google.com/presentation/d/1z4kQdpCjhMLgFUhWL5_UCK5wv8ztRXPcM_RDE3M5TYk/edit?usp=sharing> > for the ABA subcommittee, and I'd like to get your feedback before I give > it. That's a clean copy for collecting feedback (though does require a > Google account), so please feel free to comment away, or send your notes in > email. All feedback is welcome and much appreciated, but please try to send > it by Weds. 3/1 so I have time to work it into the deck for Thurs. 3/2. > > Thanks all, and best wishes, > Brad > -- > Brad Edmondson, *Esq.* > 512-673-8782 | brad.edmond...@gmail.com > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Feedback on SPDX and Legal Team overview for ABA subcommittee (by 3/1)
Hi all, Thanks for your access requests so far. I should have noted that there is built-in commenting if you want to highlight a specific point or slide. Everyone who has requested access has commenting rights. Thanks, Brad sent from my mobile device -- Brad Edmondson, Esq. 512-673-8782 | brad.edmond...@gmail.com On Feb 24, 2017 00:14, "Brad Edmondson" <brad.edmond...@gmail.com> wrote: > Hi all, > > I will be presenting an overview of SPDX and the SPDX legal team to the > Computer > Programs and New Technology > <http://apps.americanbar.org/dch/committee.cfm?com=pt035500> subcommittee > of the IP Law section > <http://www.americanbar.org/groups/intellectual_property_law.html> of the > American Bar Association next Thursday 3/2 at 2pm Eastern (right after our > legal call). There are typically 10-20 attorneys on this call, and my aim > is to educate them about OSS and SPDX, and potentially to inspire new > contributors to the legal team. > > I shared some notes > <https://docs.google.com/document/d/1gx6beTbh0TJ4l7BtDV3zWCSQb0FMh_K-5iq9C_mzji8/edit?usp=sharing> > for this presentation on a legal call a while ago, and got some good > feedback from Dennis and Paul, as well as an introduction to Jack. Since > then, I have integrated those notes into the handy SPDX overview slide deck > available at https://spdx.org/Resources and made a few tweaks of my own. > > The result is this presentation > <https://docs.google.com/presentation/d/1z4kQdpCjhMLgFUhWL5_UCK5wv8ztRXPcM_RDE3M5TYk/edit?usp=sharing> > for the ABA subcommittee, and I'd like to get your feedback before I give > it. That's a clean copy for collecting feedback (though does require a > Google account), so please feel free to comment away, or send your notes in > email. All feedback is welcome and much appreciated, but please try to send > it by Weds. 3/1 so I have time to work it into the deck for Thurs. 3/2. > > Thanks all, and best wishes, > Brad > -- > Brad Edmondson, *Esq.* > 512-673-8782 | brad.edmond...@gmail.com > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Feedback on SPDX and Legal Team overview for ABA subcommittee (by 3/1)
Hi all, I will be presenting an overview of SPDX and the SPDX legal team to the Computer Programs and New Technology <http://apps.americanbar.org/dch/committee.cfm?com=pt035500> subcommittee of the IP Law section <http://www.americanbar.org/groups/intellectual_property_law.html> of the American Bar Association next Thursday 3/2 at 2pm Eastern (right after our legal call). There are typically 10-20 attorneys on this call, and my aim is to educate them about OSS and SPDX, and potentially to inspire new contributors to the legal team. I shared some notes <https://docs.google.com/document/d/1gx6beTbh0TJ4l7BtDV3zWCSQb0FMh_K-5iq9C_mzji8/edit?usp=sharing> for this presentation on a legal call a while ago, and got some good feedback from Dennis and Paul, as well as an introduction to Jack. Since then, I have integrated those notes into the handy SPDX overview slide deck available at https://spdx.org/Resources and made a few tweaks of my own. The result is this presentation <https://docs.google.com/presentation/d/1z4kQdpCjhMLgFUhWL5_UCK5wv8ztRXPcM_RDE3M5TYk/edit?usp=sharing> for the ABA subcommittee, and I'd like to get your feedback before I give it. That's a clean copy for collecting feedback (though does require a Google account), so please feel free to comment away, or send your notes in email. All feedback is welcome and much appreciated, but please try to send it by Weds. 3/1 so I have time to work it into the deck for Thurs. 3/2. Thanks all, and best wishes, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Net-SNMP license stack v. using license expressions
Thanks Mark, FWIW I believe that Mark Baushke looked at the current version of the net-SNMP package during our call today and found that its constituent parts all pointed to a single top-level license file that contained the license stack at issue. So while your point is well-taken that the stack is not a license but a license file, it may be that it's used in the wild as an actual license. Mark Baushke, is this a fair characterization of what you saw today? Thanks, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, Dec 22, 2016 at 3:25 PM, Gisi, Mark <mark.g...@windriver.com> wrote: > > > http://net-snmp.sourceforge.net/about/license.html is *not* a license but > a license notice file. License expressions were initially designed to > represent the licensing of a single file whether it be a source file or a > binary library or program. They each represent a complete atomic integrated > (derived) work. Packages are collections or aggregates hence very different > beasts. For example, they could potentially hold a collect of independent > works where one is a GPL-2.0 file and the other is a proprietary file > (which is perfectly legitimate. Currently package level licensing is an > ill-defined concept. Furthermore license expressions as they are defined > today at a package level do not make sense unless the package contain a > single file – e.g., binary (or a collection of binaries for which a single > license express applies to all). Even in this case the expression really > represents the express of the file. I been waiting to have the package > level license discussion so we could move forward to augment the license > expression language to better accommodate packages. I recommended that > topic for the SPDX 2017 roadmap. The Net-SNMP package presents another > reason to have that discussion. > > > > - Mark > > > > *Mark Gisi | Wind River | Director, Open Source & Software Assurance* > > *Tel (510) 749-2016 | Fax (510) 749-4552* > > > > > > *From:* spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal-bounces@ > lists.spdx.org] *On Behalf Of *J Lovejoy > *Sent:* Thursday, December 22, 2016 11:30 AM > *To:* spdx-t...@lists.spdx.org > *Cc:* SPDX-legal > *Subject:* Net-SNMP license stack v. using license expressions > > > > Hi Tech team, > > > > We had a request to add the Net-SNMP license, which is actually a stack of > 6 licenses: http://net-snmp.sourceforge.net/about/license.html > > > > We’d like to get some input from the tooling and automation on this - > notes from today’s discussion are pasted below (with links to other > relevant input). Can you please provide input regarding the questions at > the end in red? > > > > Thanks! > > Jilayne > > > > 1) Review licenses still "under review" on list: https://docs.google.com/ > spreadsheets/d/11AKxLBoN_VXM32OmDTk2hKeYExKzsnPjAVM7rLs > tQ8s/edit?pli=1#gid=695212681 > > • see notes for LPG-Bolivia-1.0 and Unicode licenses in > spreadsheet (to add) > > • Discussed Net-SNMP and corresponding question as to > BSD-3-Clause with additional Sun clauses: > > • This is a stack of licenses with 6 parts, that > includes repetition of BSD-3-Clause, MIT_CMU, and a variation of > BSD-3-Clause with additional info at the top (Sun variation). Should we add > this as a license stack or rely on license expressions to identify? > > • As to adding as full stack: People do reproduce > this as is, project includes file-level references to full stack in a > copying file for recent versions, easier to identify for very common > project. This would require matching as a whole. But also have tried to > avoid adding license "stacks" unless necessary, as can be messy and also > doesn't seem to reflect file-level licensing. If added as a whole, would we > want to add a note that license expressions could also be used? > > • If the latter, then we'd need to either add > BSD-3-Clause-Sun variation or use LicenseRef for that part. > BSD-3-Clause-Sun only seems to appear by itself (to be able to use on its > own) in old version of Net-SNMP, otherwise, appears only as part of license > stack. > > • see previous discussion on this at Aug 4 > meeting: http://wiki.spdx.org/view/Legal_Team/Minutes/2016-08-04 and > email archive: https://lists.spdx.org/pipermail/spdx-legal/ > 2016-August/thread.html > > --> Decided to get input from tech team on this: what is tooling > perspective on adding this license stack versus not? Does adding as a whole > undercut automation and use of license expressions? doe
Re: XML license review update & questions
Hi all, Can two other attorneys review my edits to the and tags for W3C? I think this is ready to merge but would like to get some more eyes on my call in commit 0d92fa8 <https://github.com/spdx/license-list-XML/pull/229/commits/0d92fa853510e30c9c61454af990e5ceb3c06993?diff=split> . https://github.com/spdx/license-list-XML/pull/229 Thanks, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, Nov 10, 2016 at 9:59 PM, Brad Edmondson <brad.edmond...@gmail.com> wrote: > Thanks Jilayne, > > It does help to get a reminder every once in a while to work on these. > I'll see what I can do over the next few weeks. > > *1) License version & date in title field:* I agree that version and > license date should be included in the title section, like we see in > AGPL-3.0. We also see that in APSL > <https://github.com/spdx/license-list-XML/blob/master/src/APSL-1.0.xml>, > MPL <https://github.com/spdx/license-list-XML/blob/master/src/MPL-1.0.xml>, > Apache > <https://github.com/spdx/license-list-XML/blob/master/src/Apache-2.0.xml>, > and others, and the Creative Commons licenses > <https://github.com/spdx/license-list-XML/search?utf8=%E2%9C%93=creative+commons> > all include the version number (but no publication date) in the title field > as well. I think it makes sense to stay consistent here. > > *2) ImageMagick <https://github.com/spdx/license-list-XML/pull/97/files> > preamble & epilogue:* I agree that those should at least be optional, and > possibly removed. If I were ingesting this license from scratch I would > probably remove them altogether and treat them as notes in the HTML page > <http://www.imagemagick.org/script/license.php> that happen to surround > the license, not as part of the license itself. > > *3) PRs with "bug" label:* I think these bugs > <https://github.com/spdx/license-list-XML/pulls?q=is%3Aopen+is%3Apr+label%3Abug> > are all different. I've left comments on each. Can legal weigh in again on > my point on (2) and can Kris/technical look at replacing the hex-encoded > characters in (3) and (4)? > >- Watcom-1.0 list restructure: https://github.com/spdx/licens >e-list-XML/pull/232 >- W3C optional & body tag placement: https://github.com/spdx/licens >e-list-XML/pull/229 >- ODbL-1.0 hex-encoded chars: https://github.com/spdx/licens >e-list-XML/pull/156 > - CDDL-1.0 hex-encoded chars: https://github.com/spdx/licens >e-list-XML/pull/37 > > Jilayne, keep pushing us on this, and I'll keep helping when I can. > > Thanks, > Brad > > -- > Brad Edmondson, *Esq.* > 512-673-8782 | brad.edmond...@gmail.com > > On Thu, Nov 10, 2016 at 6:55 PM, J Lovejoy <opensou...@jilayne.com> wrote: > >> Hi All, >> >> Quick update and a couple questions I came across in the XML markup that >> I am hoping we can resolve via email. >> >> There are 89 remaining pull requests; 28 of those have been reviewed and >> tagged as “has acknowledgement” so holding those for the option of adding >> markup for acknowledgement text —> that leaves 61 that still need review :) >> >> Questions: >> 1) I came across some variations in the AGPL licenses as to what is >> included in the tag >> - AGPL-1.0 puts the version # and license date in the tag —> >> https://github.com/spdx/license-list-XML/pull/12/files >> - but AGPL-3.0 has the same line of text as part of the tag —> >> https://github.com/spdx/license-list-XML/pull/13/files >> >> I think it should be the latter (like AGPL-3.0), which seems to be how it >> is for LGPL-x.y >> >> Do you all agree? >> >> 2) ImageMagick license has a summary at the beginning that starts with, >> "Before we get to the text of the license, …” - we did not mark this as >> optional before and as a informal rule, have not been marking any kind of >> preamble as optional, but considering that language and I thought maybe >> this one warranted that text being optional. >> What do you think? >> >> 3) there are a couple licenses labeled as “bug” (assigned to Brad) - is >> there something we can sort out on those here? >> >> >> Thanks, >> Jilayne >> >> SPDX Legal Team co-lead >> opensou...@jilayne.com >> >> >> >> ___ >> Spdx-legal mailing list >> Spdx-legal@lists.spdx.org >> https://lists.spdx.org/mailman/listinfo/spdx-legal >> >> > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Fwd: Github issue templates
Forwarding per today's legal call. I also just found this article: https://help.github.com/articles/creating-an-issue-template-for-your-repository/ Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com -- Forwarded message -- From: Brad Edmondson <brad.edmond...@gmail.com> Date: Thu, Dec 10, 2015 at 2:12 PM Subject: Github issue templates To: opensou...@jilayne.com, spdx-legal@lists.spdx.org Hi everyone, I'm mostly a lurker on these SPDX calls so far, but I'm very interested in the chance to move to (or at least make more use of) github in 2016, which was mentioned as a potential goal on today's call. I'm not an excellent coder, but I know enough (and have enough experience with github) to be useful/dangerous if we go down this road. Also on today's call, we wondered about the desirability and availability of issue templates for github issues, and it looks like we aren't the first to think this would be helpful. There is a github project to support this here: https://github.com/kentcdodds/issue-template And there is a running instance, which claims to have several repositories on-board (including angular.js -- though they don't seem to mention it here <https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md>) here: http://issuetemplate.com/#/ We could potentially leverage this project, or at least the best practices developed by established github projects, on getting good data from the community into github issues. Best, Brad -- Brad Edmondson Vanderbilt Law School '14 512-673-8782 brad.edmond...@gmail.com ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Joint Call: Tuesday, Oct 25th w/Tech Team
Works for me; thanks Jilayne and Gary. Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Fri, Oct 21, 2016 at 12:29 AM, J Lovejoy <opensou...@jilayne.com> wrote: > We will have a joint call with tech team, joining their regular call time > on *Tuesday, Oct 25th @ 18:00 GMT (10:00AM PT, 11:00 MT, 12:00PM CT, > 1:00PM ET)*. Please mark your calendars. > > Dial-in (same as we use): http://uberconference.com/SPDXTeam or Call: > +1-857-216-2871 > PIN # 38633 > > Agenda: > > Close on the terms and discuss any next steps related to the following > items: > > - Encoding (propose UTF-8) > - The high level element name > - Paragraph tag or p or some other term > - Use of the tags > > All of the proposals except encoding are on the Google docs page: > https://docs.google.com/document/d/1z9n44xLH2MxT576KS_ > AbTOBtecyl5cw6RsrrQHibQtg/edit > > > Thanks, > Jilayne & Paul > SPDX Legal Team co-leads > > > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: First pass of License XML terms completed by Tech Team
Thanks Gary, I've gone through the linked document and made some comments, though I would ask the Tech Team to bear in mind I have some programming experience but none in the task of defining specs. With that said, these are my abbreviated comments: *SPDX element:* I agree this should be changed as it's too vague, but I think I would prefer "SDPXLicense" for a single license and "SPDXLicenseDocument" (or something similar, maybe "SPDXLicenseCollection") representing a collection of SDPXLicense elements. I think "ListedLicense" is too tied to the current problem, and would be awkward for tools operating on single licenses later on. *CrossRefs:* No objection or really any comment per se. It might just help to confirm that (as I assume) this comes from some other spec the Tech Team is familiar with, or is industry-standard and we/I just don't know it. *Avoiding collision with HTML:* Much appreciated; this was super confusing (to me, at least) starting out on the XML conversion project. * or :* This does have a matching purpose and so should probably be kept (as the Tech Team concluded) *:* I'm sensitive to the goal of avoiding the collision with HTML, but this seems a bit cumbersome, and like it could affect the human-readability of the XML. If you look at the GH repo there are tags all over the place. Do we need to have so many tags, or is there some other way we can keep the files somewhat readable? *alt/name/match:* I'm relatively new to SPDX, so I can't say I even begin to understand the difference among these three elements. But if we need them and tech is happy with leaving them as-is, I'm happy even in my ignorance. :-) * / newline:* I have been removing these from the XML licenses I inspect in the GH repo, and I would propose removing it from the spec (replacing them with or tags where they appear). *Should we add or element?* I'm wondering if we should have something to denote section headers/titles analogous to , , etc. in HTML. Note that I have been wrapping these in tags as we import licenses in XML, e.g. here <https://github.com/spdx/license-list-XML/commit/78a582e9d08dc723be8e77a38e3d8c32afe5f39c> . Gary and the rest of the Tech Team, thanks for all your good work, and I look forward to keeping up the momentum on this project, both on the spec side and on the XML-import side. Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Tue, Oct 11, 2016 at 2:27 PM, <g...@sourceauditor.com> wrote: > Greetings tech and legal teams, > > > > In the technical workgroup, we just completed a first pass review of all > of the terms and attributes proposed by Kris and the legal team. > > > > The details can be found in the google doc: https://docs.google.com/ > document/d/1z9n44xLH2MxT576KS_AbTOBtecyl5cw6RsrrQHibQtg/edit > > > > The comments column represents the discussion in the tech team and > includes any proposed changes. I added a column to include the proposed > new name for the element or attribute. > > > > A couple of discussions I would like to highlight for the legal team. > > > > We are proposing changing the names for many of the formatting element > names. > > > > We decided that some of the formatting tags have semantics – such as > ignoring bullets. These should be included in the RDF form of the > license. Some of the formatting tags are strictly formatting – such as > br. These will not be included in the RDF, but will be used to generate > the HTML. > > > > We also felt that we should use terms more human readable and different > from the HTML tags – e.g. newline instead of br. There were two reasons: > > · more human readable for those not familiar with HTML > > · they do represent 2 different problem spaces and should use > distinct terms > > > > We also spent some time discussing the syn element. We all agreed that we > should include a dictionary in XML form that would contain all of the > synonyms documented in the license matching guidelines. We has some > concerns on including a syn element in the license XML files themselves. > In particular, we were concerned that new synonyms could be introduced in > the license text that would be different from the matching guidelines. We > concluded that we may want to push this to a release 2 since it requires > more discussion. > > > > Please let us know if there is any concerns about the proposed terms and > attributes. > > > > Thanks, > Gary > > > > - > > Gary O'Neall > > Principal Consultant > > Source Auditor Inc. > > Mobile: 408.805.0586 > > Email: g...@sourceauditor.com > > > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: [PATCH] Fix typo where the name SUN was split across two lines.
Thanks Mark, I think you have the right idea with that perspective. Also, please note that the GH files are NOT STABLE in structure or in substantive content at this point, so you're right to continue to look to spdx.org for authoritative files. Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Fri, Oct 7, 2016 at 12:33 PM, Mark D. Baushke <m...@juniper.net> wrote: > Hi Brad, > > As no documentation (other than searching the mailing list archive) on > the spdx.org site seems to point to github right now, I think it would > be best if someone could fix git.spdx.org sooner than later. > > I would very much like to see both typos you mention fixed. > > Regarding https://github.com/spdx/license-list-XML > > Are we to assume that all of these are using an encodeing="ISO8859-1" > > I am uncertain if there is any instanes of Unicode 'COPYRIGHT SIGN' > (U+00A9) being encoded as either hex (0xc2, 0xa9) or just hex (0xa9) as > I have found in some source files. (I already expect to see it as (c), > (C), and in various files...) > > Thanks, > -- Mark > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: [PATCH] Fix typo where the name SUN was split across two lines.
Issues here: typo in BSD-3-Clause-No-Nuclear-License.txt https://github.com/spdx/license-list-XML/issues/324 typo in BSD-3-Clause-No-Nuclear-License-2014.txt https://github.com/spdx/license-list-XML/issues/323 Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, Oct 6, 2016 at 12:37 PM, Brad Edmondson <brad.edmond...@gmail.com> wrote: > Thanks very much Mark for pointing out these issues and supplying a patch. > > We are in the middle of a transition from the git repo on SPDX.org to > github <https://github.com/spdx/license-list-XML>, so there will soon be > an easy way to create a pull request for things like this. However, the > BSD-3-Clause-No-Nuclear-License was added to the license list after the > initial migration of existing licenses into the github repo. > > Can Gary or Kris or someone else with more developer experience weigh in > on whether we should (a) do a true-up at the end of the SPDX legal license > review project or (b) import newly accepted licenses into the GH repo one > by one? As it stands I can pull things into GH but I do not have edit > rights on the existing SPDX.org git repository, so I could correct this in > a PR on GH but not in the existing text on git.spdx.org. > > I also noticed a typo on line 2 of BSD-3-Clause-No-Nuclear- > License-2014.txt > <http://git.spdx.org/?p=license-list.git;a=blob;f=BSD-3-Clause-No-Nuclear-License-2014.txt;h=a454f2dd7b0e7364df0a58e00293616f2aa16557;hb=f0c56f89c60469bec90804621f84fb2d9fbe6012> > which should be subject to a similar fix: either fix now in git.spdx.org > and true-up GH later, or pull into GH and correct now. What do we all think > about those options? > > Best, > Brad > > PS - I'll open GH issues for these so we don't forget them. That should be > helpful regardless of which update path we choose. > > -- > Brad Edmondson, *Esq.* > 512-673-8782 | brad.edmond...@gmail.com > > On Wed, Oct 5, 2016 at 11:12 AM, Mark Baushke <m...@juniper.net> wrote: > >> Please pardon if this is the incorrect mailing list for patches to >> existing >> license files. >> >> For your consideration, the following is a suggested patch to the >> http://git.spdx.org/license-list.git BSD-3-Clause-No-Nuclear-License.txt >> file to make the name SUN appear on one line instead of being split >> across two lines. >> >> Note: I would suggest that the files in the git repository use a >> canonical line ending for all of the files. Some files have \r\n >> and some have \n only. Please be consistent where text may >> be intended to be machine readable. >> >> Enjoy! >> -- Mark >> >> >> ___ >> Spdx-legal mailing list >> Spdx-legal@lists.spdx.org >> https://lists.spdx.org/mailman/listinfo/spdx-legal >> >> > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: [PATCH] Fix typo where the name SUN was split across two lines.
Thanks very much Mark for pointing out these issues and supplying a patch. We are in the middle of a transition from the git repo on SPDX.org to github <https://github.com/spdx/license-list-XML>, so there will soon be an easy way to create a pull request for things like this. However, the BSD-3-Clause-No-Nuclear-License was added to the license list after the initial migration of existing licenses into the github repo. Can Gary or Kris or someone else with more developer experience weigh in on whether we should (a) do a true-up at the end of the SPDX legal license review project or (b) import newly accepted licenses into the GH repo one by one? As it stands I can pull things into GH but I do not have edit rights on the existing SPDX.org git repository, so I could correct this in a PR on GH but not in the existing text on git.spdx.org. I also noticed a typo on line 2 of BSD-3-Clause-No-Nuclear-License-2014.txt <http://git.spdx.org/?p=license-list.git;a=blob;f=BSD-3-Clause-No-Nuclear-License-2014.txt;h=a454f2dd7b0e7364df0a58e00293616f2aa16557;hb=f0c56f89c60469bec90804621f84fb2d9fbe6012> which should be subject to a similar fix: either fix now in git.spdx.org and true-up GH later, or pull into GH and correct now. What do we all think about those options? Best, Brad PS - I'll open GH issues for these so we don't forget them. That should be helpful regardless of which update path we choose. -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Wed, Oct 5, 2016 at 11:12 AM, Mark Baushke <m...@juniper.net> wrote: > Please pardon if this is the incorrect mailing list for patches to existing > license files. > > For your consideration, the following is a suggested patch to the > http://git.spdx.org/license-list.git BSD-3-Clause-No-Nuclear-License.txt > file to make the name SUN appear on one line instead of being split > across two lines. > > Note: I would suggest that the files in the git repository use a > canonical line ending for all of the files. Some files have \r\n > and some have \n only. Please be consistent where text may > be intended to be machine readable. > > Enjoy! > -- Mark > > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: meeting minutes and action plan
Thanks Jilayne, I've done my best to push a couple of licenses in the last few days as well. I believe the lower-case spdx tag is almost entirely my doing, so apologies to the group for that! Kris, do you think you can programatically replace all the lower-case spdx tags with SPDX in the licenses that have already been pushed? And if so, can that happen now while we're all still working on the master branch or should we wait until the rest of the licenses get reviewed and pushed? Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, Sep 15, 2016 at 6:01 PM, J Lovejoy <opensou...@jilayne.com> wrote: > putting my money (or in this case, time) where my mouth is: just reviewed > 3 licenses (that needed list tag fixes and were long), I am also fixing the > lower case spdx tag when I come across it. > > 116 showing, of which 30 are labeled approved = 86 to go… > > :) > > J. > > On Sep 15, 2016, at 3:15 PM, J Lovejoy <opensou...@jilayne.com> wrote: > > Hi All, > > I have posted the minutes from today’s call, which are a bit hurly-burly > in showing how the discussion went (as much as I could capture) > http://wiki.spdx.org/view/Legal_Team/Minutes/2016-09-15 > > The outcome of this discussion in manifested in the updated action plan > here: http://wiki.spdx.org/view/Legal_Team/Templatizing/ActionPlan > > For those on the call, please review and amend as you see fit. > > Finally - PLEASE PLEASE PLEASE, let’s all try to pick up some momentum on > the review of the XML files. I know we are all busy, but if we each do a > little bit, we’ll have that last bit finished in no time! > > Thanks, > Jilayne > > SPDX Legal Team co-lead > opensou...@jilayne.com > > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Starting to work on tools for the new XML license
Would this also be an opportune time to think about/discuss (1) a one-time check that our manual modifications haven't borked the text? and (2) some type of continuous integration or unit testing to make sure our changes don't screw up matching against texts we believe should always match? -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Mon, May 16, 2016 at 10:13 AM, Kris.re <kris...@bbhmedia.com> wrote: > I do think we’ll want some sort of XML manifest; we need at least > somewhere to define the synonyms, among other bits. > > > > *From:* Gary O'Neall [mailto:g...@sourceauditor.com] > *Sent:* Sunday, May 15, 2016 14:26 > *To:* Kris.re <kris...@bbhmedia.com>; 'J Lovejoy' <opensou...@jilayne.com>; > 'SPDX-legal' <spdx-legal@lists.spdx.org> > *Subject:* Starting to work on tools for the new XML license > > > > Hi Kris, Jilayne and legal team, > > > > I'm seeing a lot of activity on the XML licenses, so I started looking > into expanding the tools that generate the website to support the new XML > format. > > > > Here's what I'm currently thinking: > > - write a new command line tool which takes three parameters, a tag name > for the Git repo, a release date and the output directory. The tag name > must also be the version name used on the website. The default for the tag > is just the latest from master and the default for release date would be > today's date. > > - The application would fetch the XML files from git and translate them > into the different file formats including the files used to push to the > website. > > > > A few questions: > > > > Would it make sense to have an XML file that describes the release date > and version name in the repo? This would eliminate the second parameter to > the application and provide better control over the release name. Another > alternative would be to pull this info out of the git commit (use the date > of the commit itself for the release date). > > > > Once I get this up and running, do you want me to post the results to > spdx.org/licenses/preview? > > > > Also - Anything else you want me to fix while I'm in there (like the OSI > text in the individual license pages)? > > > > Let me know your thoughts. > > > > Thanks, > Gary > > > > - > > Gary O'Neall > > Principal Consultant > > Source Auditor Inc. > > Mobile: 408.805.0586 > > Email: g...@sourceauditor.com > > > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Nested lists in SPDX XML files.
Thanks Kris for the good recap of where we are on error-correcting the XML representation of required, optional, and replaceable text. Of course it is no fun to manually edit XML, but I think I recall correctly that the group decided at the outset of this github project that since we can programmatically validate (at least the structural legality of) our edits, and eventually adapt existing XML-parsing and editing code into SPDX-specific tooling, this process will be worth it. Especially if Sam continues to pull everyone else's weight on github as well as his own. :-) Thanks also for confirming the possibility of nesting entities. I have made a few edits assuming that nesting is legal, but I made that assumption silently -- props to Sam for specifically raising the question. Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Mon, May 9, 2016 at 10:39 AM, Kris.re <kris...@bbhmedia.com> wrote: > Sam: > > They are definitely supposed to be nested. If you are seeing one like this > than either the original template's spacing was equally flat (I could see > it for one or two, but not many), or the correction pass I made to remove > the redundant list items wasn't quite correct. There were about 3-4 types > of failures that I thought I was able to automatically correct, but > obviously I didn't look quite deep enough. If you spot these, feel free to > label them with a 'bug' label and I will address them in batch. I can roll > back the git history and extract the correctly nested version, or at least > part of it, or convert it by hand or something. > > Philippe: > > The initial proposal tried to minimize the use of XML tags at the cost of > making whitespace significant. After some discussion, this seemed (besides > being a bit of a messy solution) to not meet our needs, and so I revised it > so that whitespace was NOT significant, which required more structural tags > to identify paragraphs and the like. > > Regarding "mixed format and structure", if you're referring to the > tag, it is not a format tag but was intended to be "b for bullet". Many of > the tags are likely getting renamed and this is probably one of them. The > original choice was geared towards having as little visual space taken up > by tags as possible, but as you can see we've moved past the point where > that's a useful compromise here. If you're referring to , , > or , these are indeed structural tags, though the line is a bit fuzzy > because it's often easiest to think about them in formatting terms. We > might think of "" as a new line, which is presentation, as opposed to > a structural break between two sections of text, or "" as two new lines > as opposed to a grouping of text into a paragraph, for example. Their > primary use IS for presentation: we do need to render HTML files as one of > our outputs, so we need enough information about the *structure* of the > document to *format* it usefully. > > > But I think I lost track of the value and purpose of this editing in the > first place... can someone refresh me? > Our purpose right now is not primarily editing, though I welcome Sam's > contributions on this count, since otherwise it'll be me doing this work ;) > The primary work right now is verifying the selection of "matchable > sections" of text, which were done partly by an automated process, and > partly by myself without full legal understanding and context of these > licenses. > > > I am questioning the use of XML in first place, which may be a format > that is barely OK for saving data files, but is quite terrible for editing > IMHO. > I have to agree in most cases, but luckily for us, editing is not > something we should have to do a lot of and when we do it will be pretty > targeted. The bulk of the effort is the initial construction of the XML > file, which can be eased by way of tooling. It does happen that XML is > perfect for our particular use case, in my opinion, since what we need to > do is mark up some source text somewhat arbitrarily to add information > about it. That's something that a data-only format like JSON just doesn't > have the capability to elegantly express. > > > At least why not use plain HTML if you need to mix format and structure? > > You could then use some of the decent HTML WYSIWYG editing tools > available and not have to spend more time on the form than the substance? > I don't know about you, but in the past when I've used such tools, the > output HTML is far from minimal and often times a mess. Different tools > will produce different HTML, which is a problem when working in a shared > space (git repository). A WYSIWYG editor doesn't necessarily have the tools > to represent the informatio
Re: Contact info
Hi Kris, Did I do this <https://github.com/myndzi/license-list-XML/pull/1> correctly? I fixed a tag issue and created a PR for your repo rather than for the SPDX repo. Is that right? Thanks, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, May 5, 2016 at 12:58 PM, Kris.re <kris...@bbhmedia.com> wrote: > If you need to get ahold of me, email k...@pressbuttonllc.com or > kris...@bbhmedia.com – you can also get me on Skype at ‘myndzi’ > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License/Exception Request: BSD-3-Clause-NoNuclear
Hi all, Interesting discussion. I agree with Tom Vidal's interpretation of the sentence as completely precluding licensing in the case of use in nuclear facilities, over and above disclaiming suitability for use in such facilities. I also agree that this is a straightforward application of contract construction and is the same conclusion that virtually all courts would reach given this sentence. Further, it's worth noting that the SPDX license list includes other licenses that mention "nuclear," but all of them go further than disclaiming warranty/suitability for use in nuclear facilities: https://www.google.com/search?q=site:spdx.org%2Flicenses+%22nuclear%22 However, it does appear to be so common on github and in the broader FOSS community that I think it should still be added to the list. Many in the FOSS community may have missed that this license, though common, is technically not compliant with the free software definition or the open-source software definition, and part of the value of SPDX is that we can help repository owners surface that fact. I think we can and should help people match against this license text so that they can clean up their code to more strictly conform to the FSF or OSI definitions if they wish. To Eric's point, it also seems clear that the description of the aim of the SPDX list should be updated to explicitly note that it includes non-FOSS licenses. This seems like a relatively quick change. Could we approve over email so that a more accurate description is ready for the next release? Best, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, Mar 31, 2016 at 11:31 AM, Eric Weddington < eric_wedding...@trimble.com> wrote: > Where SPDX is at now, is that it says one thing, but does another. > > > > Yes, the website says that the SPDX License List is a list of “commonly > found open source licenses”. But if we’re going to talk about restriction > use then it’s too late. The list already has these: > > > > CC-BY-NC-1.0 > > CC-BY-NC-2.0 > > CC-BY-NC-2.5 > > CC-BY-NC-3.0 > > CC-BY-NC-4.0 > > CC-BY-NC-ND-1.0 > > CC-BY-NC-ND-2.0 > > CC-BY-NC-ND-2.5 > > CC-BY-NC-ND-3.0 > > CC-BY-NC-ND-4.0 > > CC-BY-NC-SA-1.0 > > CC-BY-NC-SA-2.0 > > CC-BY-NC-SA-2.5 > > CC-BY-NC-SA-3.0 > > CC-BY-NC-SA-4.0 > > > > The Non Commercial clause of the Creative Commons is a clear restriction > of use. > > > > If SPDX wants to be pedantic about only having open source licenses, then > there is no reason for them to exist. I can just go get the list from OSI, > or whatever the FSF has. > > > > The value, to me, that SPDX has is that it lists common licenses, that > also happen to include all the Open Source licenses too. They list a > superset. > > > > The SPDX is not the OSI, or the FSF, and should never aim to be. Change > the website language to read “commonly found licenses, including open > source”. > > > > I very much appreciate the “wider tent” that SPDX is aiming for. > > > > Eric Weddington > > > > *From:* spdx-legal-boun...@lists.spdx.org [mailto: > spdx-legal-boun...@lists.spdx.org] *On Behalf Of *Tom Vidal > *Sent:* Thursday, March 31, 2016 8:02 AM > *To:* Wheeler, David A > *Cc:* spdx-legal@lists.spdx.org > *Subject:* Re: New License/Exception Request: BSD-3-Clause-NoNuclear > > > > > > So, should we add it or not? I can appreciate the arguments on either > side of the question. Both sides make quality points. Because this is so > plainly non-open, I lean on not including it. I acknowledge Tom's point > that our inclusion guidelines do not require strict compliance. But use > restrictions are pretty black and white in my mind. As Daniel pointed out > (point 3 from his earlier email), SPDX has a mechanism to allow anybody to > maintain SDPX info of non-FOSS licenses. > > > > At some point in time, maybe SPDX's mission will expand to be able to > enable maintenance of all licenses such that it can be used to create a > comprehensive bill of materials for all licenses in a package--open, > proprietary, and whatever lies in between. But that is not where we are > now. > > > > * * * * * * * * * * * * > > THV > > ___ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > > ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
