Date   

Re: SPDX License List license inclusion guidelines

Kyle Mitchell
 

William,

Sorry to air-drop into this conversation. I've been lurking
fairly reliably, but have been too slammed to keep an active
voice in all the various places where people are typing.

Is there any kind of summary or similarly short,
approachable artifact you could point me to for the current
namespacing proposal? For reasons in line with a few of
Philippe's comments, I'm interested to see what there is in
terms of viability or outreach to the package manager
implementers.

The primary driver for SPDX identification requests in my
nick of the woods has been people trying to put an SPDX
identifier in a package manifest where one is required.
RubyGems for Ruby. npm for JavaScript. Cargo for Rust.
And so on. All of these projects use the license list, and
just the license list, as a kind of "library", divorced from
SPDX as a whole. npm and Cargo have also taken the
expression syntax, or variations of it, but that's it.

If the namespace proposal's too complex or esoteric, or too
tightly coupled to the XML-file use case of SPDX, I'd fear
divergence with the fast-moving packager and utility people,
myself probably included.

--
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933


Re: Deprecate Entessa in favour of Apache-1.1?

Karsten Klein
 

How do we deal with the slightly different obligation?

I would argue that this is not the same.

- Regards,
Karsten




metaeffekt GmbH
Firmensitz: Renettenweg 6/1, 69124 Heidelberg
Registergericht: Amtsgericht Mannheim, HRB 725313
Geschäftsführer: Karsten Klein
USt.-IdNr.: DE307084554

Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen beinhalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, informieren Sie bitte den Absender und löschen Sie diese E-Mail und alle Kopien umgehend. Eine unbefugte Weitergabe der E-Mail oder deren Inhalte und Anhänge ist nicht gestattet.

Möchten Sie als Empfänger keine Informationen dieser Art erhalten, setzen Sie sich bitte unmittelbar mit dem Absender der E-Mail in Verbindung. Die metaeffekt GmbH unterstützt Ihre Datenhoheit und informationelle Selbstbestimmung und übermittelt Informationen ausschließlich auf der Rechtsgrundlage der europäischen Datenschutzgrundverordnung (DSGVO). Weitere Informationen zu den Datenverarbeitungsvorgängen und insbesondere Ihrer Rechte entnehmen Sie der Datenschutzerklärung der metaeffekt GmbH <http://www.metaeffekt.com/files/metaeffekt-data-privacy_v2018-05-29.pdf>.



On 12.03.20, 13:00, "Matija Šuklje" <Spdx-legal@... on behalf of matija@...> wrote:

On sreda, 11. marec 2020 22:47:40 CET, J Lovejoy wrote:

> And SPDX License List endeavored to add any and all licenses
> ever approved by OSI in the early days, so… here we are. We
> didn’t have the matching guidelines established back then, I
> don’t think, but in any case, it has been on the OSI approved
> list for a very long time (as in before SPDX License List birth,
> I believe). OSI considers it a “vanity” license, in so many
> words - which is probably why we don’t have any markup on the
> acknowledgment statement.

I suspected as such, yes. I did check the OSI list when I stumbled upon it.

> Would a Note explaining this suffice?

Ideally I would like to have it deprecated (also on OSI), but note would
work as well.

Thanks for looking into this. I didn’t want to open an issue right away, as
I suspected it was some legacy thing.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...


Re: SPDX License List license inclusion guidelines

J Lovejoy
 

Philippe,

Did you actually read the proposed draft? It’s has more clarity as to key and practical aspects we already look for (e.g., stable license text) and relaxes the must-be-free requirement we have been operating under. 

And what William said. 

I’m not sure what your specific concern is. 

Jilayne 

Sent from my phone, please excuse brevity and typographical errors. 

On Mar 12, 2020, at 3:30 PM, William Bartholomew <iamwillbar@...> wrote:

Philippe,

I agree with you but I think it is orthogonal, the SPDX license inclusion guidelines would govern what goes in the official SPDX license namespace, it does not restrict what could go into other license namespaces (which would be implemented by the other proposal currently being discussed).

William

On 3/12/20 2:23 PM, Philippe Ombredanne wrote:
Hi Jilayne:

On Thu, Mar 12, 2020 at 12:59 PM J Lovejoy <opensource@...> wrote:
I’m sending this to both the legal and general mailing lists to ensure
greatest visibility.  The legal team has come up with a final draft of the
license inclusion guidelines based on various conversations and feedback
over the past 8 months of intermittent discussion.
The pull request representing this draft is located here:
https://github.com/spdx/license-list-XML/pull/990
On January 31st a compliance tooling meeting and hackathon took place
in Brussels before FOSDEM [1]. One of the session topics was SPDX.
Everyone there agreed that SPDX license inclusion criteria should be
relaxed.

Adding more restrictions and filters is IMHO counterproductive in several ways:
- it requires more work to apply these restrictions and filters
- more work means fewer licenses are added
- as a shared "vocabulary" the utility function of the license list is
directly related to the number of "words" we can use.

Restricting the number of words in the license vocabulary only means
that these words cannot be used in shared conversation about licenses.

But these licenses still exist, so the restrictions impact mostly the
usefulness and expressiveness of SPDX, especially in the more common
cases where license expressions are used without an SPDX document.

This could increasingly make the SPDX License list irrelevant if it is
missing important license vocabulary. The existing and proposed license
inclusion criteria seem counterproductive and likely to subtract value from
SPDX.

The community does not need SPDX to police or enforce OSS license
"purity" via the license list. Instead there should be fewer barriers
to adding new licenses to the list in order to optimize the utility of
the SPDX license list and the number of common licenses SPDX
expressions can deal with.

Since SPDX does not interpret license conditions, the inclusion
guidelines should be loosened to include commonly-used and public
licenses without an OSS litmus test (e.g. free proprietary licenses).
This will become more important for SPDX as more organizations become
more focused on compliance and are looking for a way to account for
all licenses detected from scans or other analysis.

[1] https://docs.google.com/document/d/1UphruKKAlsoUEidPCwTF2LCcHFnQkvQCQ9luTXfDupw/edit#
--
Cordially
Philippe Ombredanne






Re: SPDX License List license inclusion guidelines

William Bartholomew
 

Philippe,

I agree with you but I think it is orthogonal, the SPDX license inclusion guidelines would govern what goes in the official SPDX license namespace, it does not restrict what could go into other license namespaces (which would be implemented by the other proposal currently being discussed).

William

On 3/12/20 2:23 PM, Philippe Ombredanne wrote:
Hi Jilayne:

On Thu, Mar 12, 2020 at 12:59 PM J Lovejoy <opensource@...> wrote:
I’m sending this to both the legal and general mailing lists to ensure
greatest visibility. The legal team has come up with a final draft of the
license inclusion guidelines based on various conversations and feedback
over the past 8 months of intermittent discussion.
The pull request representing this draft is located here:
https://github.com/spdx/license-list-XML/pull/990
On January 31st a compliance tooling meeting and hackathon took place
in Brussels before FOSDEM [1]. One of the session topics was SPDX.
Everyone there agreed that SPDX license inclusion criteria should be
relaxed.

Adding more restrictions and filters is IMHO counterproductive in several ways:
- it requires more work to apply these restrictions and filters
- more work means fewer licenses are added
- as a shared "vocabulary" the utility function of the license list is
directly related to the number of "words" we can use.

Restricting the number of words in the license vocabulary only means
that these words cannot be used in shared conversation about licenses.

But these licenses still exist, so the restrictions impact mostly the
usefulness and expressiveness of SPDX, especially in the more common
cases where license expressions are used without an SPDX document.

This could increasingly make the SPDX License list irrelevant if it is
missing important license vocabulary. The existing and proposed license
inclusion criteria seem counterproductive and likely to subtract value from
SPDX.

The community does not need SPDX to police or enforce OSS license
"purity" via the license list. Instead there should be fewer barriers
to adding new licenses to the list in order to optimize the utility of
the SPDX license list and the number of common licenses SPDX
expressions can deal with.

Since SPDX does not interpret license conditions, the inclusion
guidelines should be loosened to include commonly-used and public
licenses without an OSS litmus test (e.g. free proprietary licenses).
This will become more important for SPDX as more organizations become
more focused on compliance and are looking for a way to account for
all licenses detected from scans or other analysis.

[1] https://docs.google.com/document/d/1UphruKKAlsoUEidPCwTF2LCcHFnQkvQCQ9luTXfDupw/edit#
--
Cordially
Philippe Ombredanne


Re: SPDX License List license inclusion guidelines

Philippe Ombredanne
 

Hi Jilayne:

On Thu, Mar 12, 2020 at 12:59 PM J Lovejoy <opensource@...> wrote:
I’m sending this to both the legal and general mailing lists to ensure
greatest visibility. The legal team has come up with a final draft of the
license inclusion guidelines based on various conversations and feedback
over the past 8 months of intermittent discussion.
The pull request representing this draft is located here:
https://github.com/spdx/license-list-XML/pull/990
On January 31st a compliance tooling meeting and hackathon took place
in Brussels before FOSDEM [1]. One of the session topics was SPDX.
Everyone there agreed that SPDX license inclusion criteria should be
relaxed.

Adding more restrictions and filters is IMHO counterproductive in several ways:
- it requires more work to apply these restrictions and filters
- more work means fewer licenses are added
- as a shared "vocabulary" the utility function of the license list is
directly related to the number of "words" we can use.

Restricting the number of words in the license vocabulary only means
that these words cannot be used in shared conversation about licenses.

But these licenses still exist, so the restrictions impact mostly the
usefulness and expressiveness of SPDX, especially in the more common
cases where license expressions are used without an SPDX document.

This could increasingly make the SPDX License list irrelevant if it is
missing important license vocabulary. The existing and proposed license
inclusion criteria seem counterproductive and likely to subtract value from
SPDX.

The community does not need SPDX to police or enforce OSS license
"purity" via the license list. Instead there should be fewer barriers
to adding new licenses to the list in order to optimize the utility of
the SPDX license list and the number of common licenses SPDX
expressions can deal with.

Since SPDX does not interpret license conditions, the inclusion
guidelines should be loosened to include commonly-used and public
licenses without an OSS litmus test (e.g. free proprietary licenses).
This will become more important for SPDX as more organizations become
more focused on compliance and are looking for a way to account for
all licenses detected from scans or other analysis.

[1] https://docs.google.com/document/d/1UphruKKAlsoUEidPCwTF2LCcHFnQkvQCQ9luTXfDupw/edit#
--
Cordially
Philippe Ombredanne


SPDX License List license inclusion guidelines

J Lovejoy
 

Hi all,

I’m sending this to both the legal and general mailing lists to ensure greatest visibility. The legal team has come up with a final draft of the license inclusion guidelines based on various conversations and feedback over the past 8 months of intermittent discussion.

The pull request representing this draft is located here: https://github.com/spdx/license-list-XML/pull/990

We are looking to provide another two weeks for review and comment and then finalize and publish this. Please do comment either on the PR, the issue below or the legal team mailing list. (including +1 if you think it’s all good!)

The issue where some of the discussion has taken place is here: https://github.com/spdx/license-list-XML/issues/925

Thanks!

Jilayne
SPDX legal team co-lead


Re: Deprecate Entessa in favour of Apache-1.1?

Matija Šuklje
 

On sreda, 11. marec 2020 22:47:40 CET, J Lovejoy wrote:

And SPDX License List endeavored to add any and all licenses ever approved by OSI in the early days, so… here we are. We didn’t have the matching guidelines established back then, I don’t think, but in any case, it has been on the OSI approved list for a very long time (as in before SPDX License List birth, I believe). OSI considers it a “vanity” license, in so many words - which is probably why we don’t have any markup on the acknowledgment statement.
I suspected as such, yes. I did check the OSI list when I stumbled upon it.

Would a Note explaining this suffice?
Ideally I would like to have it deprecated (also on OSI), but note would work as well.

Thanks for looking into this. I didn’t want to open an issue right away, as I suspected it was some legacy thing.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...


Re: Deprecate Entessa in favour of Apache-1.1?

J Lovejoy
 

Hi Matija,

Hmm… I thought we had put a Note in Entessa explaining this, but apparently not.  Perhaps there is another case like this that I am thinking of:

The reason we have Entessa on the SPDX License List is because OSI approved it as a separate license. See https://opensource.org/licenses/Entessa

And SPDX License List endeavored to add any and all licenses ever approved by OSI in the early days, so… here we are.  We didn’t have the matching guidelines established back then, I don’t think, but in any case, it has been on the OSI approved list for a very long time (as in before SPDX License List birth, I believe).  OSI considers it a “vanity” license, in so many words - which is probably why we don’t have any markup on the acknowledgment statement.

Would a Note explaining this suffice?

Jilayne

On Mar 11, 2020, at 12:05 PM, Matija Šuklje <matija@...> wrote:

Hi,

I just stumbled upon Entessa for the first time in real life, and
upon checking it with both FOSSology/Monk and SPDX License Diff,
I can’t see how it qualifies as a separate license, instead of a
variation of Apache-1.1.

Is it possible to deprecate it in favour of the Apache-1.1
template?

The only difference that seems to be outside of the current
Apache-1.1 template is the wording:
“This product includes open source software”(Entessa)
instead of only:
“This product includes software” (Apache-1.1)

relevant old issue:
https://github.com/spdx/license-list-XML/issues/840

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








Deprecate Entessa in favour of Apache-1.1?

Matija Šuklje
 

Hi,

I just stumbled upon Entessa for the first time in real life, and
upon checking it with both FOSSology/Monk and SPDX License Diff,
I can’t see how it qualifies as a separate license, instead of a
variation of Apache-1.1.

Is it possible to deprecate it in favour of the Apache-1.1
template?

The only difference that seems to be outside of the current
Apache-1.1 template is the wording:
“This product includes open source software”(Entessa)
instead of only:
“This product includes software” (Apache-1.1)

relevant old issue:
https://github.com/spdx/license-list-XML/issues/840

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


Re: Meeting tomorrow, Mar. 12

Steve Winslow
 

Sounds great, thank you Jilayne! Looking forward to discussing on the call.

On Wed, Mar 11, 2020 at 12:31 PM J Lovejoy <opensource@...> wrote:
Hi all,

I just merged that PR - we had a bunch of comments and figured it’d be easier to have a clean iteration to look at for the meeting. Please see: https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md

README and some aspects of CONTRIBUTING have also seen updates, so please have a look and provide comments or suggestions in the repo.

Thanks,
Jilayne

On Mar 11, 2020, at 8:57 AM, Steve Winslow <swinslow@...> wrote:

Hello all, the next regularly-scheduled SPDX legal team meeting will be tomorrow, Thursday, Mar. 12 at 9AM PDT / noon EDT.

The primary agenda item will be to discuss, and ideally finalize for now, the license inclusion principles update at https://github.com/spdx/license-list-XML/pull/985. We will also discuss whether to push out the 3.9 release deadline to incorporate this and some of the relevant related license requests.

= = = = =
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



--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: Meeting tomorrow, Mar. 12

J Lovejoy
 

Hi all,

I just merged that PR - we had a bunch of comments and figured it’d be easier to have a clean iteration to look at for the meeting. Please see: https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md

README and some aspects of CONTRIBUTING have also seen updates, so please have a look and provide comments or suggestions in the repo.

Thanks,
Jilayne

On Mar 11, 2020, at 8:57 AM, Steve Winslow <swinslow@...> wrote:

Hello all, the next regularly-scheduled SPDX legal team meeting will be tomorrow, Thursday, Mar. 12 at 9AM PDT / noon EDT.

The primary agenda item will be to discuss, and ideally finalize for now, the license inclusion principles update at https://github.com/spdx/license-list-XML/pull/985. We will also discuss whether to push out the 3.9 release deadline to incorporate this and some of the relevant related license requests.

= = = = =
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 tomorrow, Mar. 12

Steve Winslow
 

Hello all, the next regularly-scheduled SPDX legal team meeting will be tomorrow, Thursday, Mar. 12 at 9AM PDT / noon EDT.

The primary agenda item will be to discuss, and ideally finalize for now, the license inclusion principles update at https://github.com/spdx/license-list-XML/pull/985. We will also discuss whether to push out the 3.9 release deadline to incorporate this and some of the relevant related license requests.

= = = = =
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: Tagging of UNCOPYRIGHTABLE material

Matija Šuklje
 

On sreda, 11. marec 2020 09:42:15 CET, michael.kaelbling@... wrote:

What about cases that have been adjudged by the court as uncopyrightable or public domain contrary to a claim within the source?
What would one expect to see in the License-Identifier, LicenseConcluded, and LicenseComment fields?
Would one expect an Annotation?
I would say that CCM would be the best way to go right now, as David Wheeler already explained in detail before. Unless someone knows of a better commonly used/tested suggestion for a public domain mark.

I also agree with David that it would make sense to include CCM into the SPDX License List and finally deprecate CC-PDDC.

https://creativecommons.org/share-your-work/public-domain/pdm/

Until then you can still create a SPDX-compliant name for it – e.g. `LicenseRef-CCM` and use that.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...


Re: Tagging of UNCOPYRIGHTABLE material

michael.kaelbling@...
 

yes to your clarification, Matija -- I was talking about my/our own works.

However ...
What about cases that have been adjudged by the court as uncopyrightable or public domain contrary to a claim within the source?
What would one expect to see in the License-Identifier, LicenseConcluded, and LicenseComment fields?
Would one expect an Annotation?


Re: Tagging of UNCOPYRIGHTABLE material

Richard Fontana
 

On Tue, Mar 10, 2020 at 9:58 AM Carmen Bianca Bakker
<carmenbianca@...> wrote:

Even so, slapping a license on an uncopyrightable thing doesn't get you
in any legal trouble, so it's fine.
Except, apparently, if you're a conservative lawyer at certain U.S.
federal government agencies!

Richard


Re: Tagging of UNCOPYRIGHTABLE material

Karsten Klein
 

Hi there,

just our two cents...

When looking at a linux distribution we recently ran into the following package text:

"The contents of this package are ineligible for copyright protection."

We decided to identify this explicitly as license 'none'.

It would be great to have an SPDX-ID for such a case. A tool that matches this text can identify the non-existent license with such id.
One would also be able to mark the own files (i.e. config files) with such an identifier.

Connecting such a case to the public domain appears inappropriate to us. It's not quite what the author intended to say.

Regards,
Karsten


Re: Tagging of UNCOPYRIGHTABLE material

Mark D Baushke <mdb@...>
 

Hi Matija,

Wouldn't that have been lapsus digiti rather than lapsus calami?

I will admit that my latin is mostly self-taught. But a slip of the
finger might be a miskeying rather than the pen, unless you were
scribing with a digital pen or something...

Curious,
-- Mark


Re: Tagging of UNCOPYRIGHTABLE material

Matija Šuklje
 

On torek, 10. marec 2020 14:55:17 CET, Carmen Bianca Bakker wrote:
1) if it is not copyrightable, you have clearly marked it as such, and the SPDX-FileCopyright tag is merely used as a contact for anyone requiring extra info
I would counter that marking something as CC0-1.0 does not clearly
communicate something as uncopyrightable.
You’re correct. Lapsus calami due to writing before finishing my morning tea. CC0-1.0 marks it that whatever that thing is, its author either waives all their rights, or if they can’t do that (e.g. in most of EU) gives you a very permissive right and promisses not to enforce any of the rights that they could not waive. Which is as close to something being in public domain as possible.

As such, ad 1) I meant that if you mark something as CC0-1.0 and that thing is not copyrightable, you have clearly communicated to the public that they should act as if it is in public domain – regardless whether a) it trully is (i.e. uncopyrigtable from the start) rendering the CC0 moot, you b) hereby waived your rights, or c) you hereby gave a very permissive license.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...


Re: Tagging of UNCOPYRIGHTABLE material

Carmen Bianca Bakker
 

Je mar, 2020-03-10 je 10:04 +0100, Matija Šuklje skribis:
If so, I would still suggest marking it with CC0-1.0 as explained in REUSE:

1) if it is not copyrightable, you have clearly marked it as such, and the
SPDX-FileCopyright tag is merely used as a contact for anyone requiring
extra info
I would counter that marking something as CC0-1.0 does not clearly
communicate something as uncopyrightable.

Even so, slapping a license on an uncopyrightable thing doesn't get you
in any legal trouble, so it's fine.

Kindly,
Carmen


Re: Tagging of UNCOPYRIGHTABLE material

Matija Šuklje
 

Just to clarify … your question is solely about marking your own works – i.e. stuff that if it were copyrightable, you would hold copyright it?

If so, I would still suggest marking it with CC0-1.0 as explained in REUSE:

1) if it is not copyrightable, you have clearly marked it as such, and the SPDX-FileCopyright tag is merely used as a contact for anyone requiring extra info

2) even if it can be deemed copyrightable, you have released it as CC0-1.0, and the SPDX-FileCopyright tag fulfils all its roles.



If you planning to mark files that other people (would) hold copyright in (if they were copyrightable), than that is different and more touchy question.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...

521 - 540 of 3281