Re: meeting minutes from today

2019-05-31 Thread Dave Marr 
+1

SPDX is only pragmatically useful to me if it generally reflects the licenses 
I’m likely to encounter when vetting community software.

Dave

From: Spdx-legal@lists.spdx.org  On Behalf Of Phil 
Odence
Sent: Friday, May 31, 2019 5:12 AM
To: Michael Dolan ; J Lovejoy 

Cc: SPDX-legal 
Subject: Re: meeting minutes from today


CAUTION: This email originated from outside of the organization.
I agree we should err on the inclusive side. In concept, I think the driver 
should be popularity more than OSS definition. It’s better for users to include 
commonly used open source-like license. JSON and WTFPL (maybe this complies, 
but it’s not on the OSI list anyway), for example. We do need to be mindful of 
the capacity of the team and it makes sense to prioritize compliant licenses, 
but at a high-level the LL is to minimize the need to locally define license in 
SPDX docs and so should cover the licenses that users are likely to run into.
Phil

From: "spdx-legal@lists.spdx.org" 
mailto:Spdx-legal@lists.spdx.org>> on behalf of 
"mdo...@linuxfoundation.org" 
mailto:mdo...@linuxfoundation.org>>
Date: Thursday, May 30, 2019 at 3:44 PM
To: Jilayne Lovejoy mailto:opensou...@jilayne.com>>
Cc: "spdx-legal@lists.spdx.org" 
mailto:Spdx-legal@lists.spdx.org>>
Subject: Re: meeting minutes from today



On Thu, May 30, 2019 at 3:23 PM J Lovejoy 
mailto:opensou...@jilayne.com>> wrote:

3) Need more feedback on documentation updates - see email sent earlier this 
week, comment on PRs in Github
·discussed licenses that aren't squarely open source and variations on 
how far fall out and how to deal with this potential slippery slope. Some are 
clearly not open source (use, technology restrictions), then there are licenses 
intended to be open source, but impose new copyleft-type conditions (SSPL, 
Parity). We don't want to get into the business of defining what is open 
source, but we have to make a call on these licenses - how to do this without 
getting into the middle of the debate?
_._,_.

I tend to think SPDX should error on being more inclusive as we're expecting 
tool providers, end users and others scanning code to recognize and match the 
licenses. If they're not listed in SPDX, they have to merge in another list. I 
completely agree the current definitions are less inclusive for good reasons, 
but re-defining  "what is open source and others" for an SPDX license list is 
not going to be helpful either. That said, I look at being OSI or FSF approved 
as "properties" of the license. They're a feature. Some will consider them 
important features, but some just need to match the text in a header to some 
list of licenses that knows what this text in the header is. And for that we 
can get functionally practical. My suggestion for defining the rules for what 
gets in or doesn't would follow a similar logic.

SPDX license list may include:

  *   Licenses that show up in public source code repositories,
  *   for source code that is used by a project community directly or as a 
dependency,
  *   and have more than 1 known user of the project codebase
SPDX license list does not include:

  *   commercial licenses for use by a company's licensees
  *   vanity licenses adding a proper noun, minor modification or non-licensing 
elements (e.g. Bitcoin donation address) to a known license
  *   licenses that have no known users
  *   licenses with no known integration or dependency with other codebases
Maybe I'll start a huge debate with this, but if I were to draw a line in the 
sand without any input from others, this is where I'd probably start. So it 
likely needs input from others - let's refine it or throw it out for something 
someone has that's better. I have no emotional or intellectual attachment to 
this line in the sand. :-)



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2603): https://lists.spdx.org/g/Spdx-legal/message/2603
Mute This Topic: https://lists.spdx.org/mt/31872337/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

SPDX-Copyright

2019-05-31 Thread Carmen Bianca Bakker 
Hi spdx-legal,

I'm following up from a thread in linux-spdx[1] and a response to that
thread by Jilayne[2].

At this year's LLW in Barcelona, Max Mehl, Kate Stewart, Oliver Fendt,
Jeff McAffer and I got together to discuss some potential for
collaboration. Jeff brought up the idea of an "SPDX-Copyright" tag to
accompany the existing "SPDX-License-Identifier" tag. An issue[3] has
been opened on GitHub regarding this proposal, but Jilayne suggested
that this mailing list would also be interested in this change.

The shortest summary of this change is that this line:

Copyright 2019 Free Software Foundation Europe e.V. 

can be expressed as:

SPDX-Copyright: 2019 Free Software Foundation Europe e.V. 

The FSFE has an interest in this change via REUSE, because it would
make comment headers visually consistent and unambiguously parseable.
The ideal goal of REUSE is to get developers to put these kinds of
headers in every single file in their projects:

# SPDX-Copyright: 2019 Jane Doe 
#
# SPDX-License-Identifier: GPL-3.0-or-later

Potential advantages of this change are:

- It is visually consistent with the accompanying "SPDX-License-
Identifier" tag.

- It is trivially parseable, as opposed to using heuristics to figure
out whether a line starting with "Copyright" is a copyright notice.

- It could possibly have a strict syntax, though this is currently
debated in the issue.

- Together with the "SPDX-License-Identifier" tag, it allows one to
indicate the full copyright and licensing information of a file.

Knowing that some people will stick to existing convention (i.e.,
"Copyright [...]"), the proposed REUSE spec[4] allows both types of
copyright notices.

REUSE will not adopt this tag if SPDX turns down the proposal.

What are the thoughts of spdx-legal?

Yours with kindness,
Carmen

[1]: https://www.spinics.net/lists/linux-spdx/msg00688.html
[2]: https://www.spinics.net/lists/linux-spdx/msg01388.html
[3]: https://github.com/spdx/spdx-spec/issues/122
[4]: https://github.com/fsfe/reuse-docs/pull/23

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2602): https://lists.spdx.org/g/Spdx-legal/message/2602
Mute This Topic: https://lists.spdx.org/mt/31881952/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: This is a digitally signed message part

Re: meeting minutes from today

2019-05-31 Thread Phil Odence 
I agree we should err on the inclusive side. In concept, I think the driver 
should be popularity more than OSS definition. It’s better for users to include 
commonly used open source-like license. JSON and WTFPL (maybe this complies, 
but it’s not on the OSI list anyway), for example. We do need to be mindful of 
the capacity of the team and it makes sense to prioritize compliant licenses, 
but at a high-level the LL is to minimize the need to locally define license in 
SPDX docs and so should cover the licenses that users are likely to run into.
Phil

From: "spdx-legal@lists.spdx.org"  on behalf of 
"mdo...@linuxfoundation.org" 
Date: Thursday, May 30, 2019 at 3:44 PM
To: Jilayne Lovejoy 
Cc: "spdx-legal@lists.spdx.org" 
Subject: Re: meeting minutes from today



On Thu, May 30, 2019 at 3:23 PM J Lovejoy 
mailto:opensou...@jilayne.com>> wrote:

3) Need more feedback on documentation updates - see email sent earlier this 
week, comment on PRs in Github
· discussed licenses that aren't squarely open source and variations on 
how far fall out and how to deal with this potential slippery slope. Some are 
clearly not open source (use, technology restrictions), then there are licenses 
intended to be open source, but impose new copyleft-type conditions (SSPL, 
Parity). We don't want to get into the business of defining what is open 
source, but we have to make a call on these licenses - how to do this without 
getting into the middle of the debate?
_._,_.

I tend to think SPDX should error on being more inclusive as we're expecting 
tool providers, end users and others scanning code to recognize and match the 
licenses. If they're not listed in SPDX, they have to merge in another list. I 
completely agree the current definitions are less inclusive for good reasons, 
but re-defining  "what is open source and others" for an SPDX license list is 
not going to be helpful either. That said, I look at being OSI or FSF approved 
as "properties" of the license. They're a feature. Some will consider them 
important features, but some just need to match the text in a header to some 
list of licenses that knows what this text in the header is. And for that we 
can get functionally practical. My suggestion for defining the rules for what 
gets in or doesn't would follow a similar logic.

SPDX license list may include:

  *   Licenses that show up in public source code repositories,
  *   for source code that is used by a project community directly or as a 
dependency,
  *   and have more than 1 known user of the project codebase
SPDX license list does not include:

  *   commercial licenses for use by a company's licensees
  *   vanity licenses adding a proper noun, minor modification or non-licensing 
elements (e.g. Bitcoin donation address) to a known license
  *   licenses that have no known users
  *   licenses with no known integration or dependency with other codebases
Maybe I'll start a huge debate with this, but if I were to draw a line in the 
sand without any input from others, this is where I'd probably start. So it 
likely needs input from others - let's refine it or throw it out for something 
someone has that's better. I have no emotional or intellectual attachment to 
this line in the sand. :-)



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2601): https://lists.spdx.org/g/Spdx-legal/message/2601
Mute This Topic: https://lists.spdx.org/mt/31872337/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-