we hit our limit on the regular conference line - please go to: Join the call: https://www.uberconference.com/katestewart Optional dial in number:877-297-7470 Alternate number: 512-910-4433 No PIN

John Sullivan: Not exactly. In many cases it's clearly licensed under GPLv2. The issue is that often we don't know if "or any later version" applies. The proposal, as I understand it, is these

HI all, We have our usual call at the top of the hour, usual dial-in. http://wiki.spdx.org/view/Legal_Team We will start by checking in on progress of the next release, XML work, and then pick up the

Hi Jilayne, Thanks for writing this up. A key part is missing in the description of the original FSF proposal here though -- which is deprecating the existing GPL-2.0 and similar "plain" identifiers

Hi Jilayne, It would be helpful to provide actual source code examples of where the proposed operator would be applicable. This was done for each operator included in the first release of the

This may be cutting it to cleanly. For full SPDX documents, there are comment fields (e.g. PackageLicenseComments [1]) for motivating your concluded license. I think that motivation is especially

Hi all, I was reviewing the notes from our last call and discussion as to the “only/or later/unclear operators and GNU licenses and still have not posted them as it was hard to take notes that make

For entertainment purposes, here's what I'm currently using for a project. (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

Richard Fontana wrote: I have generally thought of SPDX license identifier formulations as describing the licensing options available to the recipient of the artifact in question, rather than a

I think they aren't comfortable with the idea that they would be distributing code under the GPL themselves. They just want to solve a license compatibility problem. They're okay with facilitating

Richard Fontana wrote: I can't imagine any other SPDX formulation that could describe the licensing scenario, and it seems right to me. (Noting of course the problem with GPL-2.0 as an identifier

That was what I was originally suggesting for what bkuhn calls EPL-2.0-original, but I think it was the cognitive dissonance that this created which in part led to the creation of what bkuhn

I think at first (when I wrote the first sentence) it seemed like there could be some privity issue and I had to think through who would be suing who and for what. after thinking through that, I ended

Thanks Philippe - that was my understanding from reading the previous thread, but I wanted to be sure. and yes, I agree - one exception to deal with this seems the best way to go, especially if the

Jilayne: Here are my 2 cents: - the text of the “assembly exception” is specific to the OpenJDK and derivatives: this code is used widely but there are very few projects that can use this

As a copyleft enforcement expert, I'll comment on this part: J Lovejoy wrote: ... I am perhaps missing a legal subtlety of the EPL-2.0-revised [0], but I suspect that when Exhibit A is exercised by

Thanks Gary!

Hi Wayne, Just found this after sending last message. I believe you noted that the “assembly exception” was not on the SPDX License List. Sounds like we should add this. I’m not sure if it

Hi All, We didn’t get a chance to discuss this on the call, so I’m sending around my thoughts as to the newly minted EPL-2.0 (which will be officially added to the SPDX License List for the next

Hi Colin, The website should be fixed. Let me know if you run into any other issues. Best regards, Gary