Date   

3.8 License List release

Steve Winslow
 

Hello all,

The version 3.8 release of the license list is now tagged and live at https://spdx.org/licenses.

Along with the usual assortment of documentation updates and markup tweaks, 9 new licenses and exceptions were added to the list:

* GPL-3.0-linking-exception
* GPL-3.0-linking-source-exception
* libselinux-1.0
* NTP-0
* OFL-1.0-RFN
* OFL-1.0-no-RFN
* OFL-1.1-RFN
* OFL-1.1-no-RFN
* PSF-2.0

The release notes can be found at https://github.com/spdx/license-list-XML/releases/tag/v3.8

Best regards,
Steve

--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Meeting today, Jan. 30

Steve Winslow
 

The next SPDX legal team meeting will be today, Thursday, Jan. 30 at 9AM PT / noon ET.

We'll focus on finalizing items to be included in the upcoming 3.8 release.

Best,
Steve

= = = = =
Join Zoom Meeting
https://zoom.us/j/611416785

Meeting ID: 611 416 785

One tap mobile
+16465588656,,611416785# US (New York)
+16699006833,,611416785# US (San Jose)

Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 611 416 785
Find your local number: https://zoom.us/u/aceZFvRyln


--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: New License/Exception Request: selinux-nsa-declaration

Steve Winslow
 

Thanks Mark, I've created an issue to track this new request at: https://github.com/spdx/license-list-XML/issues/966

Steve


On Mon, Jan 20, 2020 at 4:42 PM Mark Atwood via Lists.Spdx.Org <atwoodm=amazon.com@...> wrote:
1.    Provide a proposed Full Name for the license or exception.
selinux-nsa-declaration-1.0
2.    Provide a proposed Short Identifier. selinux-nsa-declaration-1.0
3.
https://github.com/SELinuxProject/selinux/blob/master/libselinux/LICENSE
4. License text is attached.
5.  Not OSI approved
6.  Used by SELinux.






--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


New License/Exception Request: selinux-nsa-declaration

Mark Atwood (Amazon.com)
 

1. Provide a proposed Full Name for the license or exception.
selinux-nsa-declaration-1.0
2. Provide a proposed Short Identifier. selinux-nsa-declaration-1.0
3.
https://github.com/SELinuxProject/selinux/blob/master/libselinux/LICENSE
4. License text is attached.
5. Not OSI approved
6. Used by SELinux.


Re: Meeting today, Jan. 16

pmadick
 

Hi Steve, 

I got called out of town for a family emergency and won't be able to make it today. Things are going ok.

Sorry, 

Paul 



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Steve Winslow <swinslow@...>
Date: 1/16/20 6:00 AM (GMT-08:00)
To: SPDX-legal <spdx-legal@...>
Subject: Meeting today, Jan. 16

The next SPDX legal team meeting will be today, Thursday, Jan. 16 at 9AM PT / noon ET.

Today we'll focus on following up on status for the pending 3.8 issues that were selected during the last call on Jan. 2.

Best,
Steve

= = = = =
Join Zoom Meeting
https://zoom.us/j/611416785

Meeting ID: 611 416 785

One tap mobile
+16465588656,,611416785# US (New York)
+16699006833,,611416785# US (San Jose)

Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 611 416 785
Find your local number: https://zoom.us/u/aceZFvRyln


--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Meeting today, Jan. 16

Steve Winslow
 

The next SPDX legal team meeting will be today, Thursday, Jan. 16 at 9AM PT / noon ET.

Today we'll focus on following up on status for the pending 3.8 issues that were selected during the last call on Jan. 2.

Best,
Steve

= = = = =
Join Zoom Meeting
https://zoom.us/j/611416785

Meeting ID: 611 416 785

One tap mobile
+16465588656,,611416785# US (New York)
+16699006833,,611416785# US (San Jose)

Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 611 416 785
Find your local number: https://zoom.us/u/aceZFvRyln


--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


[ANNOUNCE] Open source license compliance tooling meeting and hackathon on January 31st 2020 pre-FOSDEM fringe event in Bruxelles, Belgium

Philippe Ombredanne
 

If you care about open source compliance automation and if you are
going to FOSDEM there is a one day hackathon and meeting taking place
the day before FOSDEM on Friday January 31st as "fringe" event, in
Bruxelles, Belgium.

The topic is open source compliance tooling and automation... the
format is an unconference. I expect several open source projects in
that space to be represented there including ORT, Fossology,
ClearlyDefined, SPDX tools, Scancode and many more.

I am co-organizing this with Michael Jaeger from Fossology.

See https://docs.google.com/document/d/1UphruKKAlsoUEidPCwTF2LCcHFnQkvQCQ9luTXfDupw/edit#heading=h.p2d7mni4lrcu
for details.

To "register", just add you name to this document! (alternatively you
can reply to me off list too)

I look forward to seeing you there!
--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com


Meeting today, Jan. 2

Steve Winslow
 

Happy new year, all!

The next SPDX legal team meeting will be today, Thursday, Jan. 2 at 9AM PT / noon ET.

Since the 3.8 release was delayed due to the holidays and canceled team meetings, today's agenda will focus on triaging issues for what's reasonable to complete for 3.8, and assigning owners who can help shepherd them through to completion.

**Please note** that beginning today, we are switching to using Zoom (as the tech team has previously done). Invite details are below and also in the 2020 calendar invite previously circulated. A dial-in phone number is also available.

Best,
Steve

= = = = =
Join Zoom Meeting
https://zoom.us/j/611416785

Meeting ID: 611 416 785

One tap mobile
+16465588656,,611416785# US (New York)
+16699006833,,611416785# US (San Jose)

Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 611 416 785
Find your local number: https://zoom.us/u/aceZFvRyln

--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Invitation: SPDX legal team meeting @ Every 2 weeks from 12pm to 1pm on Thursday from Thu Jan 2, 2020 to Thu Dec 31, 2020 (EST) (spdx-legal@lists.spdx.org)

Steve Winslow
 

You have been invited to the following event.

SPDX legal team meeting

When
Every 2 weeks from 12pm to 1pm on Thursday from Thu Jan 2, 2020 to Thu Dec 31, 2020 Eastern Time - New York
Where
https://zoom.us/j/611416785 (map)
Calendar
spdx-legal@...
Who
swinslow@... - organizer
spdx-legal@...

Recurring invite for SPDX legal team meetings for 2020.


Please note that we are switching to Zoom instead of UberConference, see below. Dial-in phone numbers are still available as shown below.


= = = = =
Join Zoom Meeting
https://zoom.us/j/611416785

Meeting ID: 611 416 785

One tap mobile
+16465588656,,611416785# US (New York)
+16699006833,,611416785# US (San Jose)

Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 611 416 785
Find your local number: https://zoom.us/u/aceZFvRyln

Going (spdx-legal@...)?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account spdx-legal@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


Happy Holidays (and let's reconvene in the New Year)

J Lovejoy
 

Hi all,

Due to the end of the year craziness many of us are experiencing and resulting low-turnout at recent meetings and on the mailing list, we are going to call it for the year and reconvene (with vigor!) in 2020. This means the 3.8 release will be postponed.

If you do have some cycles over the next couple weeks, please get caught up and dive in on the issues in the license list repo - it takes a village to get a release done. :D

Steve will send a new recurring invite for 2020. In the meantime, enjoy your holidays!

Cheers,
Jilayne


Re: SPDX-License-Identifier for composite-licensed source files

Matija Šuklje
 

Hi Richard,

I think both your possibilities work, and with the current state
of art, I would agree with Kate, Jilayne and Gary.

On the other hand it seems to me that exactly how to mark source
code is perhaps a bit out of the scope of SPDX (I might be wrong
though).

A project that is based on SPDX that is aimed directly at properly
marking up source code is <https://reuse.software>.

For 4.0 (i.e. next major release) spec, one of the bigger tasks is
to properly handle snippets. There is already a ticket open, and
I’d love to hear your (and everyone else’s on this list, of
course) feedback:
<https://github.com/fsfe/reuse-docs/issues/34>


cheers,
Matija Šuklje
--
gsm: +386 41 849 552
www: http://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...


Re: SPDX-License-Identifier for composite-licensed source files

Gary O'Neall
 

+1 on Kate’s recommendation.  This format will be properly parsed by the SPDX Tools parsers (the 3 parsers I am aware of) and I believe represents the intent behind the AND operator.

 

Gary

 

From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Kate Stewart
Sent: Thursday, December 12, 2019 8:49 AM
To: Richard Fontana <rfontana@...>
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: SPDX-License-Identifier for composite-licensed source files

 

Hi Richard,

    I suspect the others will comment as well,  but 

I would hope to see 

"SPDX-License-Identifier: MPL-2.0 AND Apache-2.0"

as a summary. 

 

The second approach may become ambiguous to scanners

as they may try to treat it as an "OR",  and I believe that

"AND" is truer to the intention here.

 

Kate

 

On Thu, Dec 12, 2019 at 10:30 AM Richard Fontana <rfontana@...> wrote:

Suppose you're dealing with the following source file legal notice
(example taken from
https://www.mozilla.org/en-US/MPL/2.0/permissive-code-into-mpl/,
itself adapted from the examples discussed by SFLC in this old paper:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html):

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
 *
 * This file incorporates work covered by the following copyright and
 * permission notice:
 *
 *   Copyright 2013 Joe Bloggs
 *
 *   Licensed under the Apache License, Version 2.0 (the "License");
 *   you may not use this file except in compliance with the License.
 *   You may obtain a copy of the License at
 *
 *        http://www.apache.org/licenses/LICENSE-2.0
 *
 *   Unless required by applicable law or agreed to in writing, software
 *   distributed under the License is distributed on an "AS IS" BASIS,
 *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *   See the License for the specific language governing permissions and
 *   limitations under the License.
 */

Is there a recommended approach to translating this to use
SPDX-Liense-Identifier strings?

One possibility might be:

/* Copyright 2013 Joe Bloggs
 * SPDX-License-Identifier: MPL-2.0 AND Apache-2.0
 */

This approach represents all the copyright and license information in
the original file without making the legal judgment that is implicit
in the original notice (as to the legal effect of one-way
compatibility of the Apache License 2.0 with MPL 2.0), beyond possibly
what someone might choose to infer from the mere ordering of the
conjunctive set of licenses. But it gives the possibly-false
impression that Joe Bloggs is the sole or, in some sense, primary
copyright owner of the code in the file, which results in part from
the absence of a copyright notice for the MPL licensor(s).

Another possibility might be:

/* SPDX-License-Identifier: MPL-2.0
 * This file incorporates work covered by the following copyright
notice and license:
 *   Copyright 2013 Joe Bloggs
 *   SPDX-License-Identifier: Apache-2.0
 */

This is closer to the original, and provides the same opinion on the
licensing consequence of the "incorporation" of the Apache License 2.0
code, but whether that is good or bad I'm not sure. (As I understand
it there's a theme in SPDX of attempting to avoid making legal
judgments.) But it has a verbosity that I would think goes against the
whole spirit of using the SPDX-License-Identifier construct.

What's the best practice for source files of this sort, containing
code under multiple licenses where there is some notion of code under
the more permissive license being subsumed under the more restrictive
license of incorporation?

Richard




Re: SPDX-License-Identifier for composite-licensed source files

J Lovejoy
 



On Dec 12, 2019, at 9:48 AM, Kate Stewart <kstewart@...> wrote:

Hi Richard,
    I suspect the others will comment as well,  but 
I would hope to see 
"SPDX-License-Identifier: MPL-2.0 AND Apache-2.0"
as a summary. 

Agree. And also agree with Richard’s comment about avoiding legal interpretations. When you say that the license is “X AND Y” you are saying both licenses apply. Which is the fact for this file. You are not saying  whether those licenses are compatible (or what one does if they are incompatible) - that would be a legal interpretation.  You are merely reporting what is in the file. 



The second approach may become ambiguous to scanners
as they may try to treat it as an "OR",  and I believe that
"AND" is truer to the intention here.

The second approach is also not an SPDX license expression as defined in the spec, so that’s also problematic when used with “SPDX-License-Identifier” (I think)

Jilayne


Kate

On Thu, Dec 12, 2019 at 10:30 AM Richard Fontana <rfontana@...> wrote:
Suppose you're dealing with the following source file legal notice
(example taken from
https://www.mozilla.org/en-US/MPL/2.0/permissive-code-into-mpl/,
itself adapted from the examples discussed by SFLC in this old paper:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html):

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
 *
 * This file incorporates work covered by the following copyright and
 * permission notice:
 *
 *   Copyright 2013 Joe Bloggs
 *
 *   Licensed under the Apache License, Version 2.0 (the "License");
 *   you may not use this file except in compliance with the License.
 *   You may obtain a copy of the License at
 *
 *        http://www.apache.org/licenses/LICENSE-2.0
 *
 *   Unless required by applicable law or agreed to in writing, software
 *   distributed under the License is distributed on an "AS IS" BASIS,
 *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *   See the License for the specific language governing permissions and
 *   limitations under the License.
 */

Is there a recommended approach to translating this to use
SPDX-Liense-Identifier strings?

One possibility might be:

/* Copyright 2013 Joe Bloggs
 * SPDX-License-Identifier: MPL-2.0 AND Apache-2.0
 */

This approach represents all the copyright and license information in
the original file without making the legal judgment that is implicit
in the original notice (as to the legal effect of one-way
compatibility of the Apache License 2.0 with MPL 2.0), beyond possibly
what someone might choose to infer from the mere ordering of the
conjunctive set of licenses. But it gives the possibly-false
impression that Joe Bloggs is the sole or, in some sense, primary
copyright owner of the code in the file, which results in part from
the absence of a copyright notice for the MPL licensor(s).

Another possibility might be:

/* SPDX-License-Identifier: MPL-2.0
 * This file incorporates work covered by the following copyright
notice and license:
 *   Copyright 2013 Joe Bloggs
 *   SPDX-License-Identifier: Apache-2.0
 */

This is closer to the original, and provides the same opinion on the
licensing consequence of the "incorporation" of the Apache License 2.0
code, but whether that is good or bad I'm not sure. (As I understand
it there's a theme in SPDX of attempting to avoid making legal
judgments.) But it has a verbosity that I would think goes against the
whole spirit of using the SPDX-License-Identifier construct.

What's the best practice for source files of this sort, containing
code under multiple licenses where there is some notion of code under
the more permissive license being subsumed under the more restrictive
license of incorporation?

Richard






Re: SPDX-License-Identifier for composite-licensed source files

Kate Stewart
 

Hi Richard,
    I suspect the others will comment as well,  but 
I would hope to see 
"SPDX-License-Identifier: MPL-2.0 AND Apache-2.0"
as a summary. 

The second approach may become ambiguous to scanners
as they may try to treat it as an "OR",  and I believe that
"AND" is truer to the intention here.

Kate

On Thu, Dec 12, 2019 at 10:30 AM Richard Fontana <rfontana@...> wrote:
Suppose you're dealing with the following source file legal notice
(example taken from
https://www.mozilla.org/en-US/MPL/2.0/permissive-code-into-mpl/,
itself adapted from the examples discussed by SFLC in this old paper:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html):

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
 *
 * This file incorporates work covered by the following copyright and
 * permission notice:
 *
 *   Copyright 2013 Joe Bloggs
 *
 *   Licensed under the Apache License, Version 2.0 (the "License");
 *   you may not use this file except in compliance with the License.
 *   You may obtain a copy of the License at
 *
 *        http://www.apache.org/licenses/LICENSE-2.0
 *
 *   Unless required by applicable law or agreed to in writing, software
 *   distributed under the License is distributed on an "AS IS" BASIS,
 *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *   See the License for the specific language governing permissions and
 *   limitations under the License.
 */

Is there a recommended approach to translating this to use
SPDX-Liense-Identifier strings?

One possibility might be:

/* Copyright 2013 Joe Bloggs
 * SPDX-License-Identifier: MPL-2.0 AND Apache-2.0
 */

This approach represents all the copyright and license information in
the original file without making the legal judgment that is implicit
in the original notice (as to the legal effect of one-way
compatibility of the Apache License 2.0 with MPL 2.0), beyond possibly
what someone might choose to infer from the mere ordering of the
conjunctive set of licenses. But it gives the possibly-false
impression that Joe Bloggs is the sole or, in some sense, primary
copyright owner of the code in the file, which results in part from
the absence of a copyright notice for the MPL licensor(s).

Another possibility might be:

/* SPDX-License-Identifier: MPL-2.0
 * This file incorporates work covered by the following copyright
notice and license:
 *   Copyright 2013 Joe Bloggs
 *   SPDX-License-Identifier: Apache-2.0
 */

This is closer to the original, and provides the same opinion on the
licensing consequence of the "incorporation" of the Apache License 2.0
code, but whether that is good or bad I'm not sure. (As I understand
it there's a theme in SPDX of attempting to avoid making legal
judgments.) But it has a verbosity that I would think goes against the
whole spirit of using the SPDX-License-Identifier construct.

What's the best practice for source files of this sort, containing
code under multiple licenses where there is some notion of code under
the more permissive license being subsumed under the more restrictive
license of incorporation?

Richard





SPDX-License-Identifier for composite-licensed source files

Richard Fontana
 

Suppose you're dealing with the following source file legal notice
(example taken from
https://www.mozilla.org/en-US/MPL/2.0/permissive-code-into-mpl/,
itself adapted from the examples discussed by SFLC in this old paper:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html):

/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*
* This file incorporates work covered by the following copyright and
* permission notice:
*
* Copyright 2013 Joe Bloggs
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

Is there a recommended approach to translating this to use
SPDX-Liense-Identifier strings?

One possibility might be:

/* Copyright 2013 Joe Bloggs
* SPDX-License-Identifier: MPL-2.0 AND Apache-2.0
*/

This approach represents all the copyright and license information in
the original file without making the legal judgment that is implicit
in the original notice (as to the legal effect of one-way
compatibility of the Apache License 2.0 with MPL 2.0), beyond possibly
what someone might choose to infer from the mere ordering of the
conjunctive set of licenses. But it gives the possibly-false
impression that Joe Bloggs is the sole or, in some sense, primary
copyright owner of the code in the file, which results in part from
the absence of a copyright notice for the MPL licensor(s).

Another possibility might be:

/* SPDX-License-Identifier: MPL-2.0
* This file incorporates work covered by the following copyright
notice and license:
* Copyright 2013 Joe Bloggs
* SPDX-License-Identifier: Apache-2.0
*/

This is closer to the original, and provides the same opinion on the
licensing consequence of the "incorporation" of the Apache License 2.0
code, but whether that is good or bad I'm not sure. (As I understand
it there's a theme in SPDX of attempting to avoid making legal
judgments.) But it has a verbosity that I would think goes against the
whole spirit of using the SPDX-License-Identifier construct.

What's the best practice for source files of this sort, containing
code under multiple licenses where there is some notion of code under
the more permissive license being subsumed under the more restrictive
license of incorporation?

Richard


meeting tomorrow POSTPONED to next week, Dec 19th / release update

J Lovejoy
 

Hi all,

Due to some unforeseen circumstances, both Steve and I are not available tomorrow. Given this would be our last meeting for 2019 (unless people wanted to meet on Dec 26th?), I'd like to postpone to next week, Dec 19th. Please adjust your calendars accordingly.

Also, we have not had enough help to get through many of the issues in the queue for the next release, which would normally occur at the end of the month. If you use the SPDX License List in anyway, if you are reading this message, PLEASE check the issues in the Github repo and provide any help you can.

Thanks,

Jilayne
SPDX legal team co-lead


Re: Request for adding Eclipse Distribution License - v 1.0

Alexios Zavras
 

We should have a “note” on the BSD-3-Clause license.

 

-- zvr

 

From: Spdx-legal@... <Spdx-legal@...> On Behalf Of CARLIER Aurelien
Sent: Wednesday, 11 December, 2019 08:34
To: spdx-legal@...
Cc: Wayne Beaton <wayne.beaton@...>; Philippe Ombredanne <pombredanne@...>
Subject: Re: Request for adding Eclipse Distribution License - v 1.0

 

Hello,

 

Thank you Wayne and Philippe for giving an answer that quickly J. I agree with the statement.

 

Maybe it (former suggestion by Wayne) would be mentioned in the "license and exceptions tracking page" not to be requested again (I've checked before sending the email, trying to make things the right way).

 

Regards,

Aurélien

 

[@@ THALES GROUP INTERNAL @@]

 

De : Wayne Beaton [mailto:wayne.beaton@...]
Envoyé : mardi 10 décembre 2019 20:04
À : CARLIER Aurelien
Cc : spdx-legal@...
Objet : Re: Request for adding Eclipse Distribution License - v 1.0

 

We've discussed this previously (at my suggestion on behalf of the Eclipse Foundation).

 

My recollection is that it was decided that SPDX would not add EDL-1.0 or any other licenses based on the BSD-3-Clause template because doing so would set a precedent drawing in literally hundreds of other licenses based on that template.

 

For Eclipse projects that use EDL-1.0, we just use BSD-3-Clause as the SPDX code.

 

Wayne

 

On Tue, Dec 10, 2019 at 12:36 PM CARLIER Aurelien <aurelien.carlier@...> wrote:

Hello,

 

I would like to request addition of the Eclipse Distribution License in the SPDX license list. The EDL-1.0 is a variation of the New BSD License (fixing . Here is what I would suggest:

 

1.    License name: Eclipse Distribution License 1.0

2.    Proposed Identifier: EDL-1.0

3.    URL: https://www.eclipse.org/org/documents/edl-v10.php

4.    See attached file.

5.    Indicate whether the license is OSI-approved : “The Eclipse Distribution License is an OSI Approved Open Source License by means of the New BSD License.” As said on the license’s full text page

6.    This license is used by Eclipse JGIT https://github.com/eclipse/jgit/blob/master/LICENSE with the following text:

This program and the accompanying materials are made available

under the terms of the Eclipse Distribution License v1.0 which

accompanies this distribution, is reproduced below, and is

available at http://www.eclipse.org/org/documents/edl-v10.php

 

Thank you in advance to take this request into account.

 

Regards,

Aurélien

 

[@@ THALES GROUP INTERNAL @@]

 


 

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


Re: Request for adding Eclipse Distribution License - v 1.0

CARLIER Aurelien
 

Hello,

 

Thank you Wayne and Philippe for giving an answer that quickly J. I agree with the statement.

 

Maybe it (former suggestion by Wayne) would be mentioned in the "license and exceptions tracking page" not to be requested again (I've checked before sending the email, trying to make things the right way).

 

Regards,

Aurélien

 

[@@ THALES GROUP INTERNAL @@]

 

De : Wayne Beaton [mailto:wayne.beaton@...]
Envoyé : mardi 10 décembre 2019 20:04
À : CARLIER Aurelien
Cc : spdx-legal@...
Objet : Re: Request for adding Eclipse Distribution License - v 1.0

 

We've discussed this previously (at my suggestion on behalf of the Eclipse Foundation).

 

My recollection is that it was decided that SPDX would not add EDL-1.0 or any other licenses based on the BSD-3-Clause template because doing so would set a precedent drawing in literally hundreds of other licenses based on that template.

 

For Eclipse projects that use EDL-1.0, we just use BSD-3-Clause as the SPDX code.

 

Wayne

 

On Tue, Dec 10, 2019 at 12:36 PM CARLIER Aurelien <aurelien.carlier@...> wrote:

Hello,

 

I would like to request addition of the Eclipse Distribution License in the SPDX license list. The EDL-1.0 is a variation of the New BSD License (fixing . Here is what I would suggest:

 

1.    License name: Eclipse Distribution License 1.0

2.    Proposed Identifier: EDL-1.0

3.    URL: https://www.eclipse.org/org/documents/edl-v10.php

4.    See attached file.

5.    Indicate whether the license is OSI-approved : “The Eclipse Distribution License is an OSI Approved Open Source License by means of the New BSD License.” As said on the license’s full text page

6.    This license is used by Eclipse JGIT https://github.com/eclipse/jgit/blob/master/LICENSE with the following text:

This program and the accompanying materials are made available

under the terms of the Eclipse Distribution License v1.0 which

accompanies this distribution, is reproduced below, and is

available at http://www.eclipse.org/org/documents/edl-v10.php

 

Thank you in advance to take this request into account.

 

Regards,

Aurélien

 

[@@ THALES GROUP INTERNAL @@]

 


 

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.


Re: Request for adding Eclipse Distribution License - v 1.0

Philippe Ombredanne
 

Hi Aurelien:

On Tue, Dec 10, 2019 at 6:36 PM CARLIER Aurelien
<aurelien.carlier@...> wrote:
I would like to request addition of the Eclipse Distribution License in the SPDX license list.
The EDL-1.0 is a variation of the New BSD License
As far as I can remember, since this is the same as the BSD-3-Clause
license text (using the matching guidelines), it was never added as
its own license id.

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com


Re: Request for adding Eclipse Distribution License - v 1.0

Wayne Beaton
 

We've discussed this previously (at my suggestion on behalf of the Eclipse Foundation).

My recollection is that it was decided that SPDX would not add EDL-1.0 or any other licenses based on the BSD-3-Clause template because doing so would set a precedent drawing in literally hundreds of other licenses based on that template.

For Eclipse projects that use EDL-1.0, we just use BSD-3-Clause as the SPDX code.

Wayne

On Tue, Dec 10, 2019 at 12:36 PM CARLIER Aurelien <aurelien.carlier@...> wrote:

Hello,

 

I would like to request addition of the Eclipse Distribution License in the SPDX license list. The EDL-1.0 is a variation of the New BSD License (fixing . Here is what I would suggest:

 

1.    License name: Eclipse Distribution License 1.0

2.    Proposed Identifier: EDL-1.0

3.    URL: https://www.eclipse.org/org/documents/edl-v10.php

4.    See attached file.

5.    Indicate whether the license is OSI-approved : “The Eclipse Distribution License is an OSI Approved Open Source License by means of the New BSD License.” As said on the license’s full text page

6.    This license is used by Eclipse JGIT https://github.com/eclipse/jgit/blob/master/LICENSE with the following text:

This program and the accompanying materials are made available

under the terms of the Eclipse Distribution License v1.0 which

accompanies this distribution, is reproduced below, and is

available at http://www.eclipse.org/org/documents/edl-v10.php

 

Thank you in advance to take this request into account.

 

Regards,

Aurélien

 

[@@ THALES GROUP INTERNAL @@]

 



--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

561 - 580 of 3280