Spdx-legal@lists.spdx.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: signifigance of nested parenthesis with only ORs? (was: OpenJ9 license)

Bradley M. Kuhn: As you guessed, the parentheses are not *needed*. The SPDX spec says that parentheses SHOULD be used when there are multiple license identifiers or license refs, but this is a SHOULD

By David A. Wheeler · #1986 ·

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

By Brad Edmondson · #1985 ·

signifigance of nested parenthesis with only ORs? (was: OpenJ9 license)

Wayne Beaton wrote on Monday, 2 October: Could you explain a bit further why the extra parenthesis grouping is needed when only ORs are involved? Looking at the SPDX spec at

By Bradley M. Kuhn <bkuhn@...> · #1984 ·

Re: only/or later and the goals of SPDX

While SPDX should avoid making legal judgements, I don't think it necessarily follows that they need to enable others to avoid making legal judgements. Concluded licenses are really all about

By W. Trevor King · #1983 ·

Re: meeting at top of the hour

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

By J Lovejoy · #1982 ·

Re: only/or later and the goals of SPDX

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

By David A. Wheeler · #1981 ·

meeting at top of the hour

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

By J Lovejoy · #1980 ·

Re: only/or later and the goals of SPDX

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

By John Sullivan <johns@...> · #1979 ·

Re: only/or later and the goals of SPDX

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

By Mark Gisi · #1978 ·

Re: only/or later and the goals of SPDX

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

By W. Trevor King · #1977 ·

only/or later and the goals of SPDX

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

By J Lovejoy · #1976 ·

Re: OpenJ9 license

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

By Wayne Beaton · #1975 ·

Re: EPL-2.0 and Secondary Licenses

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

By Bradley M. Kuhn <bkuhn@...> · #1974 ·

Re: EPL-2.0 and Secondary Licenses

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

By Richard Fontana · #1973 ·

Re: EPL-2.0 and Secondary Licenses

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

By Bradley M. Kuhn <bkuhn@...> · #1972 ·

Re: EPL-2.0 and Secondary Licenses

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

By Richard Fontana · #1971 ·

Re: EPL-2.0 and Secondary Licenses

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

By J Lovejoy · #1970 ·

Re: OpenJ9 license

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

By J Lovejoy · #1969 ·

Re: OpenJ9 license

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

By Philippe Ombredanne · #1968 ·

Re: EPL-2.0 and Secondary Licenses

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

By Bradley M. Kuhn <bkuhn@...> · #1967 ·

1421 - 1440 of 3406

Home Hashtags Subgroups Terms