Date   

Feb 7 SPDX General Meeting Reminder

Phil Odence
 

GENERAL MEETING

 

Meeting Time: Thurs, Feb 7, 8am PST / 10 am CST / 11am EST / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

New dial in number: 415-881-1586

No PIN needed

The weblink for screenshare will stay the same at: 
http://uberconference.com/SPDXTeam

 

Administrative Agenda

Attendance

Minutes Approval: https://wiki.spdx.org/view/General_Meeting/Minutes/2019-01-03

 

Technical Team Report – Kate/Gary

 

Legal Team Report – Jilayne

 

Outreach Team Report – Jack

 

Any Cross Functional Issues –All

 

 

L. Philip Odence
General Manager, Black Duck On-Demand
Synopsys Software Integrity Group, Burlington, MA
O: +1.781.313.6655
| M: +1.781.258.9502


banner

L. Philip Odence
General Manager, Black Duck On-Demand
Synopsys Software Integrity Group
800 District Avenue, Suite 101, Burlington, MA 01803-5061
W: +1.781.313.6801; M: +1.781.258.9502

www.blackducksoftware.com  

 

 


Re: Standalone license tools for scanning debian/ubuntu apps?

Kate Stewart
 



On Tue, Feb 5, 2019 at 5:32 PM Dan Kegel <dank@...> wrote:
On Tue, Feb 5, 2019 at 1:30 PM Jeremiah C. Foster <jfoster@...> wrote:
> If I'm not mistaken, copyright has to be a string because it has to be legible by humans. This means you can likely grep through source code as scancode does with a fair degree of confidence and use 'strings' on binaries.
>
> Using DEP-5 and Debian Copyright files where you can should also be sufficient for due diligence in most jurisdictions, but I can't point to any legal precedent as evidence.
>
> SPDX helps by creating a framework for human and machine readable documentation of your work, but you'll still need to scan code for copyright.
>
> Binaries likely require a bit of reverse engineering.

Yes, absolutely.

SPDX's set of standard licenses and ids (and scancode's somewhat
expanded similar set) are great for stating license info succinctly.

scancode is great at collecting the info that should go into the
debian copyright file.

My goal for this iteration at our licensing process was to automate
collection of license info for the shared libraries our binary uses.

Hi Dan,
    Am not sure what you're using for a build infrastructure, but there
are some solutions emerging in Yocto that may be relevant, as well
as the other projects that Philippe outlines.    

 I checked with Richard and he confirms that
" The Yocto Project already builds everything with debug symbols which
get linked and separated into separate packages. It already uses
dwarfsrcfiles to generate a list of source code files which went into
creating a given binary.

The Project also has license information for each software recipe it
builds.

There are some work in progress patches, not quite ready to merge yet
but working which combine these two pieces of information, along with
scanning the source files for SPDX headers to give information about
the possible license a binary may be under."

So if you're using Yocto for your builds, and want to help get with the development
of this capability available faster,  rather than create a stand-alone tool feel free to 
reach out to Richard (on cc). 

Thanks, Kate


Re: Standalone license tools for scanning debian/ubuntu apps?

Philippe Ombredanne
 

Hi Dan:
You are asking a simple question for which is there is no simple
answer: this is not yet a solved problem and there is no easy button
to press.
Hence the long answer.

On Mon, Feb 4, 2019 at 8:20 PM Dan Kegel <dank@...> wrote:

Hi all!

Coming up with a list of licenses a binary is bound by is
a mind-boggling task that I avoid whenever possible.
I've been watching spdx and friends from afar for some time
in hopes they will help.

Recently I was asked to write a stateless, standalone tool that takes
a path to a
dynamically linked linux binary, and outputs an approximate list of licenses
the shared libraries it uses are bound by. Here's my current draft:
https://github.com/Oblong/obs/blob/master/ob-list-licenses

Roughly, it uses ldd and dpkg-query to locate copyright files
for all shared libraries it references, and then either
just outputs the License: values for DEP-5 copyright files,
or uses scancode to detect them for non-DEP-5 copyright files.

Now I'm plugging along, adding optional heuristics like
"XXX of dependencies can be filtered out (because I'm only interested
in the bits pulled in via dynamic linking)"
where XXX is "files: debian/*" and "files: doc/*"

Am I duplicating work? I looked at fossology, but its complexity kind
of disqualifies it
(nothing about it seems standalone or stateless).
Since you are trying to figure out the license of a shared object (aka
library, or DLL) you need to know the license of the files that are
compiled/linked in it.
And quite rightly, using Debian copyright files will help you find out
the license of the source files. So will a ScanCode scan (and it will
also look in the binaries and report anything that can be found
there).

But that would not help you find out which set of source files are
baked in that shared object and what is the effective license of the
shared object in many cases (short of applying some extra heuristics
or work on top).

The most common problem is when a package provides a library and a
command line too/utilities and each use a different license (typically
the library is LGPL and the command line utilities are GPL). There are
also other files such as build scripts, test files, documentation,
tools, etc that may use several other licenses. These are not linked
in the shared library and therefore would need to be parsed out to
properly conclude what is the effective shared object license.

As an example libcap-ng (one of the package you listed) is both small
and typical of many Linux libraries licensing and code organization
and the issues that come up when you are trying to find which license
applies to what.

- It is overall under LGPL-2.1 or later and in particular its library
is using this license [1] but its RPM spec file (libcap-ng.spec) is
not up to date and refers to an LGPL-2.0+ instead of a 2.1 version.
- Command line utilities are under GPL 2.0 [2]
- Some build scripts are MIT-licensed (configure.ac), or use other
similar licenses (INSTALL is FSFAP) or are GPL- or LGPL-licensed
(Makefile.am)
- The root directory contains a copy of the GPL 2 (COPYING) and LGPL
2.1 (COPYING.LIB) and another copy of the LGPL (LICENSE). But there
are no indication of which one applies to what except for the not
entirely correct spec file mentioned above.
- The corresponding Debian copyright file [3] is not structured to be
machine readable yet . Yet it provides a bit more information: the top
level license is properly reported as an LGPL-2.1 or later. And there
is a mention of the GPL-2.0-licensed build scripts and command line
utilities. But it also introduces a new GPL-3.0 license for the Debian
packaging removing some clarity to the licensing documentation.

The overall licensing is pretty clear when you are used to this after
a quick review (and the help of a ScanCode scan of course ;)): the
shared library license is LGPL-2.1-or-later and nothing else but
things are mighty difficult to automate to come to the same correct
conclusion.

If you could know which exact files are included in the shared
object/library, you could get back to these source files to get the
licensing information.
For this there are a few ways to go:
1. trace which files are compiled and linked the DLL
2. obtain that information from a DB or from a tool (without tracing)

1. For the tracing part
1.1- in the world of ELFs, you could use a debug build and parse out
debug symbols to get back the list of actual source files that are
based in that executable. There is contributed code in scancode [4] to
extract DWARF debug symbols and get the corresponding source code file
paths but that has not been fully integrated yet in the main tool.

1.2- you could trace the build such that you know exactly which files
are used and included in the .so. I maintain TraceCode for this [5]
and quartermaster [6] is also doing similar things (with different
approaches). TraceCode works from an strace system calls trace of an
unmodified/uninstrumented build to recreate/reverse engineer a build
graph as it happens in user space. This is not a magically automated
solution though and results require review and interpretation. But it
works not too badly on single libraries.

2. To obtain the information without tracing:
Some tool or database could have told which files are in the library
and which files are in the CLI utilities and which are build scripts
in a structured way. This is what are called facets [7] in scancode
which is a concept borrowed from ClearlyDefined [8]. But being able to
define facets and having facets defined is not the same. Scancode can
report facets for each file if you tell it. But it does not have yet
the ability to infer facets from the code such as for instance
assigning "Makefile.am" to a development/build scripts facets. Working
together on this would go a long way. There are a few Scancode pending
tickets on this [9] [10].
As for ClearlyDefined, our goal (I contribute to the project) is to
have facets possibly contributed as part of the curation and review
process. And any enhancement to Scancode to infer facets would also
benefit ClearlyDefined and would likely be of a great help to Debian
to improve copyright files that are not yet machine readable too.

[1] https://github.com/stevegrubb/libcap-ng/blob/master/libcap-ng.spec#L7
[2] https://github.com/stevegrubb/libcap-ng/blob/master/libcap-ng.spec#L57
[3] https://metadata.ftp-master.debian.org/changelogs/main/libc/libcap-ng/libcap-ng_0.7.7-3_copyright
[4] https://github.com/nexB/scancode-toolkit-contrib/tree/develop/src/compiledcode
[5] https://github.com/nexB/tracecode-toolkit
[6] https://github.com/QMSTR/qmstr
[7] https://github.com/nexB/scancode-toolkit/blob/develop/src/summarycode/facet.py#L58
[8] https://clearlydefined.io/
[9] https://github.com/nexB/scancode-toolkit/issues/1036
[10] https://github.com/nexB/scancode-toolkit/issues/377
--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
ScanCode maintainer


SPDX General Meeting 2018 (replacement)

Phil Odence
 

When: Occurs every month on the first Thursday of the month from 11:00 AM to 12:00 PM effective 8/2/2018 until 1/1/2020. (UTC-05:00) Eastern Time (US & Canada)
Where: Bridge info enclosed

*~*~*~*~*~*~*~*~*~*

I’m extending this recurring meeting to run through 2019. Please accept so it is updated on your calendar, however no need to send a response to me.



New dial in number: 415-881-1586

No PIN needed

The weblink for screenshare will stay the same at:
http://uberconference.com/SPDXTeam



MEETING MINUTES FOR REVIEW: http://spdx.org/wiki/meeting-minutes-and-decisions



Re: Standalone license tools for scanning debian/ubuntu apps?

Dan Kegel
 

On Tue, Feb 5, 2019 at 1:30 PM Jeremiah C. Foster <@jeremiah> wrote:
If I'm not mistaken, copyright has to be a string because it has to be legible by humans. This means you can likely grep through source code as scancode does with a fair degree of confidence and use 'strings' on binaries.

Using DEP-5 and Debian Copyright files where you can should also be sufficient for due diligence in most jurisdictions, but I can't point to any legal precedent as evidence.

SPDX helps by creating a framework for human and machine readable documentation of your work, but you'll still need to scan code for copyright.

Binaries likely require a bit of reverse engineering.
Yes, absolutely.

SPDX's set of standard licenses and ids (and scancode's somewhat
expanded similar set) are great for stating license info succinctly.

scancode is great at collecting the info that should go into the
debian copyright file.

My goal for this iteration at our licensing process was to automate
collection of license info for the shared libraries our binary uses.

Here's the pipeline I set up to do that:

1) https://github.com/Oblong/obs/blob/master/ob-filter-licenses reads
a DEP-5 (aka Debian copyright) file and filters out any clauses that
(most likely) do not propagate to shared library artifacts
2) https://github.com/Oblong/obs/blob/master/ob-parse-licenses reads a
Debian copyright file, filters it through ob-filter-licenses, and
outputs spdx ids. (For non-DEP-5 copyright files, it uses scancode to
guess licenses.)
3) https://github.com/Oblong/obs/blob/master/ob-list-licenses uses ldd
to look up shared libraries used by a binary, uses dpkg-query to look
up the containing packages, and runs ob-parse-licenses on them.

For instance, running "ob-list-licences /bin/login" outputs:

libaudit1 https://people.redhat.com/sgrubb/audit/
GPL-2
LGPL-2.1

libc6 https://www.gnu.org/software/libc/libc.html
libc6-special

libcap-ng0 http://people.redhat.com/sgrubb/libcap-ng
GPL-2.0-or-later
LGPL-2.1-only
GPL-1.0-or-later

libpam0g http://www.linux-pam.org/
BSD-3-Clause
GPL-1.0-or-later
GPL-2.0-only

This of course only solves a small part of the license / copyright
problem, and only approximately, but it found interesting things for
us.
- Dan


Re: Standalone license tools for scanning debian/ubuntu apps?

Jeremiah C. Foster
 

If I'm not mistaken, copyright has to be a string because it has to be legible by humans. This means you can likely grep through source code as scancode does with a fair degree of confidence and use 'strings' on binaries.

Using DEP-5 and Debian Copyright files where you can should also be sufficient for due diligence in most jurisdictions, but I can't point to any legal precedent as evidence.

SPDX helps by creating a framework for human and machine readable documentation of your work, but you'll still need to scan code for copyright.

Binaries likely require a bit of reverse engineering.


From: Dan Kegel <dank@...>
Sent: Monday, February 4, 2019 23:49
To: spdx@...
Subject: Re: [spdx] Standalone license tools for scanning debian/ubuntu apps?

I did look a bit at those, but they seemed more about unpacking
binaries than about wrangling copyrights.






This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.


Re: Standalone license tools for scanning debian/ubuntu apps?

Dan Kegel
 

I did look a bit at those, but they seemed more about unpacking
binaries than about wrangling copyrights.


Re: Standalone license tools for scanning debian/ubuntu apps?

Kate Stewart
 


On Mon, Feb 4, 2019 at 8:47 PM Jeremiah C. Foster <jfoster@...> wrote:
Have you looked at the binary analysis tool?

There's also BANG! (Binary Analysis Next Generation) that is in beta now.

Kate


Re: Standalone license tools for scanning debian/ubuntu apps?

Jeremiah C. Foster
 

Have you looked at the binary analysis tool?

Regards,

Jeremiah 

On Feb 4, 2019, at 14:20, Dan Kegel <dank@...> wrote:

Hi all!

Coming up with a list of licenses a binary is bound by is
a mind-boggling task that I avoid whenever possible.
I've been watching spdx and friends from afar for some time
in hopes they will help.

Recently I was asked to write a stateless, standalone tool that takes
a path to a
dynamically linked linux binary, and outputs an approximate list of licenses
the shared libraries it uses are bound by. Here's my current draft:
https://github.com/Oblong/obs/blob/master/ob-list-licenses

Roughly, it uses ldd and dpkg-query to locate copyright files
for all shared libraries it references, and then either
just outputs the License: values for DEP-5 copyright files,
or uses scancode to detect them for non-DEP-5 copyright files.

Now I'm plugging along, adding optional heuristics like
"XXX of dependencies can be filtered out (because I'm only interested
in the bits pulled in via dynamic linking)"
where XXX is "files: debian/*" and "files: doc/*"

Am I duplicating work?  I looked at fossology, but its complexity kind
of disqualifies it
(nothing about it seems standalone or stateless).

Thanks,
Dan






This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.


Standalone license tools for scanning debian/ubuntu apps?

Dan Kegel
 

Hi all!

Coming up with a list of licenses a binary is bound by is
a mind-boggling task that I avoid whenever possible.
I've been watching spdx and friends from afar for some time
in hopes they will help.

Recently I was asked to write a stateless, standalone tool that takes
a path to a
dynamically linked linux binary, and outputs an approximate list of licenses
the shared libraries it uses are bound by. Here's my current draft:
https://github.com/Oblong/obs/blob/master/ob-list-licenses

Roughly, it uses ldd and dpkg-query to locate copyright files
for all shared libraries it references, and then either
just outputs the License: values for DEP-5 copyright files,
or uses scancode to detect them for non-DEP-5 copyright files.

Now I'm plugging along, adding optional heuristics like
"XXX of dependencies can be filtered out (because I'm only interested
in the bits pulled in via dynamic linking)"
where XXX is "files: debian/*" and "files: doc/*"

Am I duplicating work? I looked at fossology, but its complexity kind
of disqualifies it
(nothing about it seems standalone or stateless).

Thanks,
Dan


[Openchain-japan-wg] Question about SPDX Light: Supported Fields

Shane Coughlan <coughlan@...>
 

Dear all

We have an active discussion via the OpenChain Japan Work Group (mostly in Japanese) about SPDX. Several Japanese companies are using SPDX in production today and are collaborating to this through a common approach and “ask” for suppliers, particularly those with a relatively limited understanding of open source.

This “ask” will be a subset variant of SPDX informally dubbed “SPDX Light.” It is not intended to break the SPDX Mandatory / Optional fields. Instead it is looking like a series of core fields plus some optional codified into one clear procurement request from multiple companies. One note and comment about this is below (English after the Japanese).

Please note:
(1) Japanese companies operate mostly in Japanese, which is why this discussion has not been occurring on the SPDX mailing list
(2) SPDX calls are at inaccessible times for Japanese companies, which has further hindered interaction

Nevertheless, this is a great moment for us all to jump into a shared discussion.

Regards

Shane 


Begin forwarded message:

From: <Hiroyuki.Fukuchi@...>
Date: 16 January 2019 at 12:34:57 GMT+9
To: <openchain-japan-wg@...>
Subject: [Openchain-japan-wg] Question about SPDX Light: Supported Fields

皆様

福地です

組織間のライセンス情報授受のSGで検討している仮称SPDX light
ですが、ISSUEリストに海外の方(mcjaeger)から書き込みがありました。

SPDX lightというミニマムセットを作るコンセプトに賛成のようで、
その上で提案と質問が来ています。

関心のある方は、彼の提案を読んでコメントを頂けませんでしょうか。


Question about SPDX Light: Supported Fields #2
https://github.com/OpenChain-Project/Japan-WG-General/issues/2

hello,

regarding the SPDX light proposal I would like to express more a question rather than an issue. I like the SPDX light proposal very much. I was wondering about the following additional elements more like a question:

for package information: I found the checksum very useful to exchange information about packages, maybe it could be considered as well? is it maybe confusing hwne the same package was compiled multiple times?

How about an acknowledgement field attached to license information? (For licenses that ask for acknowledgement, such as https://spdx.org/licenses/BSD-4-Clause-UC.html because then, acknowledgement documentation could easily generated from SPDX.

Export control and customs, ECC notice (since patent notice is already envisaged) for a package could be used (with reference in which file it was found)

would be package download location also the package management id? (for example it is named "artefact id" for maven packages)

ignore flag for files which could be info that this file was not part of license analysis or isnot considered as license analysis because it is considered irrelevant.

Please see my remarks just as quick feedback from the posting on openchain mailing list. My idea was it could be a good place here to ask a question about this document:

https://github.com/OpenChain-Project/Japan-WG-General/blob/master/License-Info-Exchange/Doc-at-Meeting/Candidate-of-SDPX-light.md


---
福地 弘行 (Hiroyuki.Fukuchi@...)
ソニー(株)UX企画部 アライアンス業務課

_______________________________________________
Openchain-japan-wg mailing list
Openchain-japan-wg@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain-japan-wg


Re: [OpenChain] Knowledge Sharing: Reference guideline for exchanging license information in the supply chain

Shane Coughlan <coughlan@...>
 

HI Fukuchi San

Very interesting and exciting collaboration. I understand that companies like Fujitsu are actively deploying SPDX.

I think you have already spoken about your activity with Kate. I think the basic note is: if using a cut down version of SDPX the important thing is to have the File Analyzed attribute set to “false”.

I am adding SDPX mailing list to CC.

Regards

Shane

On Jan 11, 2019, at 18:10, <Hiroyuki.Fukuchi@...> <Hiroyuki.Fukuchi@...> wrote:

Hi all,

Yesterday, the subgroup held a face-to-face meeting to discuss SPDX light.
(Members belong to the automotive, consumer electronics and IT industries.)
The outcome is here:
https://github.com/OpenChain-Project/Japan-WG-General/blob/master/License-Info-Exchange/Doc-at-Meeting/Candidate-of-SDPX-light.md

You can see which items in SPDX are being discussed.

---
Hiro Fukuchi (Hiroyuki.Fukuchi@...)
Sony

-----Original Message-----
From: Fukuchi, Hiroyuki (Sony)
Sent: Friday, January 11, 2019 9:27 AM
To: Shane Coughlan <coughlan@...>; Jeff McAffer
<Jeff.McAffer@...>
Cc: OpenChain <openchain@...>;
openchain-japan-wg@...
Subject: RE: [OpenChain] Knowledge Sharing: Reference guideline for
exchanging license information in the supply chain

Hi Jeff-san,

• Is there more detail somewhere on SPDX light?
Now Japan WG is considering the "SPDX light".

The current format under discussion is shared at GitHub:
(An Example of Minimum License Information List (Automotive))
https://github.com/OpenChain-Project/Japan-WG-General/blob/master/Licens
e-Info-Exchange/Doc-at-Meeting/License-Info-list-automotive.md

We will prepare a brief explanation, a sample data and a procedure to produce it.


The concept is:
The target user of "SPDX light" is a supplier who do not have enough knowledge
about SPDX and OSS compliance.
It is easy to use without tool, but having minimum set for compliance and
SPDX-affinity.


---
Hiro Fukuchi (Hiroyuki.Fukuchi@...) Sony

-----Original Message-----
From: openchain-bounces@...
<openchain-bounces@...> On Behalf Of Shane
Coughlan
Sent: Thursday, January 10, 2019 3:56 PM
To: Jeff McAffer <Jeff.McAffer@...>
Cc: OpenChain <openchain@...>;
openchain-japan-wg@...
Subject: Re: [OpenChain] Knowledge Sharing: Reference guideline for
exchanging license information in the supply chain

Hi Jeff!

Great question. The OpenChain Japan WG has adjacent material on
SDPX/FOSSology:
https://www.openchainproject.org/news/2019/01/09/knowledge-sharing-how
- to-use-spdx-and-fossology-from-the-openchain-japan-work-group
(Just announced a couple of minutes ago)

About ClearlyDefined, absolutely. All community projects should align
closely for cross-use and interoperability. Let me hook you up to the
Japan WG (in CC) so you can chat direct about how the reference materials can
be expended.

Regards

Shane

On Jan 10, 2019, at 15:49, Jeff McAffer <Jeff.McAffer@...> wrote:

Looks good Shane. Two questions:
• Is there more detail somewhere on SPDX light?
• Would it make sense for ClearlyDefined to be a Community source
of
license and copyright info?

Jeff


From: openchain-bounces@...
<openchain-bounces@...> On Behalf Of Shane
Coughlan
Sent: Wednesday, January 9, 2019 10:34 PM
To: OpenChain <openchain@...>
Subject: [OpenChain] Knowledge Sharing: Reference guideline for
exchanging
license information in the supply chain

<image001.jpg>
The OpenChain Project Japan Work Group is creating a reference
guideline for
exchanging license information in the supply chain. The basic concept
is that all the entities, suppliers, integrators and OSS communities
exchange license information by SPDX (Software Package Data Exchange),
an open standard for communicating software bill of material information.

Learn More:
• Japan work group:
https://github.com/OpenChain-Project/Japan-WG-General
• SPDX: https://spdx.org/
• REUSE initiative: https://reuse.software/

--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan
--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Schedule a call:
https://calendly.com/shanecoughlan


Re: [EXTERNAL] Re: [spdx-tech] [spdx] Need Help for contrubuting in GSOC 2019 #spdx

Gary O'Neall
 

In addition to Java, we have quite a few tools written in Python.  We just added libraries written in go. 

 

Gary

 

From: spdx@... <spdx@...> On Behalf Of Manbeck, Jack via Lists.Spdx.Org
Sent: Friday, January 11, 2019 1:04 PM
To: varsha kukreja <varshak333@...>; spdx@...
Subject: Re: [EXTERNAL] Re: [spdx-tech] [spdx] Need Help for contrubuting in GSOC 2019 #spdx

 

Sure. Were just now starting the process of applying to Google for their Summer of Code 2019. If we do get awarded slots there is a specific process you must follow. I suggest you get signed up with them and review what the process is. You would need to submit a proposal for any of the projects we have, assuming we are selected.   We then go through the proposals and pick the best one. I’m over simplifying this a bit but that’s the general idea.

 

The spdx tools themselves are based on Java.  You can visit our github project here:  https://github.com/spdx

 

We have a few other online tools but off hand I don’t recall what they are written in. Possibly some python and others.

 

Gary, can you fill in that gap?

 

 

Jack

 

 

 

From: varsha kukreja [mailto:varshak333@...]
Sent: Friday, January 11, 2019 1:50 PM
To: Manbeck, Jack; spdx@...
Subject: Re: [EXTERNAL] Re: [spdx-tech] [spdx] Need Help for contrubuting in GSOC 2019 #spdx

 

Hey Can i know which languages are used in backend of spdx?

 

On Thu, Jan 10, 2019 at 10:35 PM varsha kukreja <varshak333@...> wrote:

HI .Thank you Sir for the response and the link..I would like to work on a google summer of code project for SPDX for GSOC 2019 ..But I would also be interested to contribute to SPDX tools if that makes me familiar with the community and helps getting selected for your organization in GSOC 2019

 

On Thu, Jan 10, 2019 at 7:51 PM Manbeck, Jack <j-manbeck2@...> wrote:

Hi Varshak,

 

Are you looking to work on a google summer of code project for SPDX or help contribute to the SPDX tools or specification, etc.,. (not google summer of code)?

 

Thanks

 

Jack

 

 

From: Spdx-tech@... [mailto:Spdx-tech@...] On Behalf Of Kate Stewart
Sent: Thursday, January 10, 2019 9:07 AM
To: varshak333@...
Cc: spdx-tech@...
Subject: [EXTERNAL] Re: [spdx-tech] [spdx] Need Help for contrubuting in GSOC 2019 #spdx

 

Hi Varshak,

     Welcome!   Glad you're interested in participating in our community.  I am copying the spdx-tech mail list where we 

discuss the GSoC efforts.

 

     Ideas we've come up with so far are listed on: https://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeas,  but we're in active idea gathering  mode this week,  so suggestions are welcome as well.

 

Kate

 

 

On Thu, Jan 10, 2019 at 7:36 AM <varshak333@...> wrote:

I would like to contribute to the open source community ..I have majorly worked on backend on 2 college sponsored projects and working currently on a project by Government Organization. I have fair knowledge in Javascript, NodeJs, Typescript, Spring Boot, Laravel , Docker and apache thrift. It woukd be great if could if someone could help me get started

 

 


 

--

Kate Stewart

Sr. Director of Strategic Programs,  The Linux Foundation

Mobile: +1.512.657.3669

Email / Google Talk: kstewart@...

 


Re: [EXTERNAL] Re: [spdx-tech] [spdx] Need Help for contrubuting in GSOC 2019 #spdx

Manbeck, Jack
 

Sure. Were just now starting the process of applying to Google for their Summer of Code 2019. If we do get awarded slots there is a specific process you must follow. I suggest you get signed up with them and review what the process is. You would need to submit a proposal for any of the projects we have, assuming we are selected.   We then go through the proposals and pick the best one. I’m over simplifying this a bit but that’s the general idea.

 

The spdx tools themselves are based on Java.  You can visit our github project here:  https://github.com/spdx

 

We have a few other online tools but off hand I don’t recall what they are written in. Possibly some python and others.

 

Gary, can you fill in that gap?

 

 

Jack

 

 

 

From: varsha kukreja [mailto:varshak333@...]
Sent: Friday, January 11, 2019 1:50 PM
To: Manbeck, Jack; spdx@...
Subject: Re: [EXTERNAL] Re: [spdx-tech] [spdx] Need Help for contrubuting in GSOC 2019 #spdx

 

Hey Can i know which languages are used in backend of spdx?

 

On Thu, Jan 10, 2019 at 10:35 PM varsha kukreja <varshak333@...> wrote:

HI .Thank you Sir for the response and the link..I would like to work on a google summer of code project for SPDX for GSOC 2019 ..But I would also be interested to contribute to SPDX tools if that makes me familiar with the community and helps getting selected for your organization in GSOC 2019

 

On Thu, Jan 10, 2019 at 7:51 PM Manbeck, Jack <j-manbeck2@...> wrote:

Hi Varshak,

 

Are you looking to work on a google summer of code project for SPDX or help contribute to the SPDX tools or specification, etc.,. (not google summer of code)?

 

Thanks

 

Jack

 

 

From: Spdx-tech@... [mailto:Spdx-tech@...] On Behalf Of Kate Stewart
Sent: Thursday, January 10, 2019 9:07 AM
To: varshak333@...
Cc: spdx-tech@...
Subject: [EXTERNAL] Re: [spdx-tech] [spdx] Need Help for contrubuting in GSOC 2019 #spdx

 

Hi Varshak,

     Welcome!   Glad you're interested in participating in our community.  I am copying the spdx-tech mail list where we 

discuss the GSoC efforts.

 

     Ideas we've come up with so far are listed on: https://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeas,  but we're in active idea gathering  mode this week,  so suggestions are welcome as well.

 

Kate

 

 

On Thu, Jan 10, 2019 at 7:36 AM <varshak333@...> wrote:

I would like to contribute to the open source community ..I have majorly worked on backend on 2 college sponsored projects and working currently on a project by Government Organization. I have fair knowledge in Javascript, NodeJs, Typescript, Spring Boot, Laravel , Docker and apache thrift. It woukd be great if could if someone could help me get started

 

 


 

--

Kate Stewart

Sr. Director of Strategic Programs,  The Linux Foundation

Mobile: +1.512.657.3669

Email / Google Talk: kstewart@...


Re: [EXTERNAL] Re: [spdx-tech] [spdx] Need Help for contrubuting in GSOC 2019 #spdx

varshak333@...
 

Hey Can i know which languages are used in backend of spdx?


On Thu, Jan 10, 2019 at 10:35 PM varsha kukreja <varshak333@...> wrote:
HI .Thank you Sir for the response and the link..I would like to work on a google summer of code project for SPDX for GSOC 2019 ..But I would also be interested to contribute to SPDX tools if that makes me familiar with the community and helps getting selected for your organization in GSOC 2019

On Thu, Jan 10, 2019 at 7:51 PM Manbeck, Jack <j-manbeck2@...> wrote:

Hi Varshak,

 

Are you looking to work on a google summer of code project for SPDX or help contribute to the SPDX tools or specification, etc.,. (not google summer of code)?

 

Thanks

 

Jack

 

 

From: Spdx-tech@... [mailto:Spdx-tech@...] On Behalf Of Kate Stewart
Sent: Thursday, January 10, 2019 9:07 AM
To: varshak333@...
Cc: spdx-tech@...
Subject: [EXTERNAL] Re: [spdx-tech] [spdx] Need Help for contrubuting in GSOC 2019 #spdx

 

Hi Varshak,

     Welcome!   Glad you're interested in participating in our community.  I am copying the spdx-tech mail list where we 

discuss the GSoC efforts.

 

     Ideas we've come up with so far are listed on: https://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeas,  but we're in active idea gathering  mode this week,  so suggestions are welcome as well.

 

Kate

 

 

On Thu, Jan 10, 2019 at 7:36 AM <varshak333@...> wrote:

I would like to contribute to the open source community ..I have majorly worked on backend on 2 college sponsored projects and working currently on a project by Government Organization. I have fair knowledge in Javascript, NodeJs, Typescript, Spring Boot, Laravel , Docker and apache thrift. It woukd be great if could if someone could help me get started

 

 


 

--

Kate Stewart

Sr. Director of Strategic Programs,  The Linux Foundation

Mobile: +1.512.657.3669

Email / Google Talk: kstewart@...


Re: Need Help for contrubuting in GSOC 2019 #spdx

Kate Stewart
 

Hi Varshak,
     Welcome!   Glad you're interested in participating in our community.  I am copying the spdx-tech mail list where we 
discuss the GSoC efforts.

     Ideas we've come up with so far are listed on: https://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeas,  but we're in active idea gathering  mode this week,  so suggestions are welcome as well.

Kate


On Thu, Jan 10, 2019 at 7:36 AM <varshak333@...> wrote:
I would like to contribute to the open source community ..I have majorly worked on backend on 2 college sponsored projects and working currently on a project by Government Organization. I have fair knowledge in Javascript, NodeJs, Typescript, Spring Boot, Laravel , Docker and apache thrift. It woukd be great if could if someone could help me get started
 
 



--
Kate Stewart
Sr. Director of Strategic Programs,  The Linux Foundation
Mobile: +1.512.657.3669
Email / Google Talk: kstewart@...


Need Help for contrubuting in GSOC 2019 #spdx

varshak333@...
 

I would like to contribute to the open source community ..I have majorly worked on backend on 2 college sponsored projects and working currently on a project by Government Organization. I have fair knowledge in Javascript, NodeJs, Typescript, Spring Boot, Laravel , Docker and apache thrift. It woukd be great if could if someone could help me get started
 
 


SPDX January General Meeting Minutes

Phil Odence
 

https://wiki.spdx.org/view/General_Meeting/Minutes/2019-01-03

 

 

General Meeting/Minutes/2019-01-03

< General Meeting‎ | Minutes

·         Attendance: 15

·         Lead by Phil Odence

·         Minutes of Dec meeting approved 

 

Contents

 [hide

·         1 Guest Presentation, JC Herz

·         2 Tech Team Report - Kate/Gary

·         3 Legal Team Report - Jilayne

·         4 Outreach Team Report

·         5 Attendees

Guest Presentation, JC Herz[edit]

·         Background

·         Years of working with companies and DOD in open source

·         The Issues/concerns

·         License issues- SPDX handles well

·         Concerns about security close on the heels

·         Compliance is an additional step- Jumping through the hoops to document

·         SEVA Software Evidence Archive

·         Elements

·         Serves S-BOM function

·         Augments with content that needs to travel with software

·         Therefore allowing compliance work to be automated

·         Freeing up valuable resources to do what they are supposed to do

·         Can apply to a single component or a full application, so SEVA doesn’t distinguish

·         Format Issue

·         Customers required XML, beyond SEVA JSON

·         To be useable by a highly secure facility, data has to be hardened for which XML is better suited

·         Can be constrained and format can be verified (and extended)

·         SPDX and SEVA Overlap

·         License Info

·         For the most part SPDX handles beautifully

·         Government also needs to distinguish government open source

·         A little more information about state of software (e.g. pre-release)

·         Security extra needs

·         Some concern about spurious vulnerabilities

·         Answer is to extend a BoM to include patch info, etc

·         End of life indicator

·         They take SPDX familiar thing and provide some extensibility

·         How to name “supplier”?

·         Working with Kate 

·         OSS organization for example

·         A bank’s black list

·         Vulnerabilities

·         Key requirement for vulnerabilities info in SBOM, although just a link might make more sense

·         Reason is “audit” function. What you knew when. So needs a time stamp.

·         Bureaucratic are not going to change in favor of something that makes more sense for developers 

·         Concerns that this will get worse over time

·         Other Side - Logistics

·         Moving and shipping of SW/chain of custody- Where did it come from exactly

·         Not something OSS community has had to worry about

·         Bad mirror issue, for example.

·         Signed? Timestamp? Delivery date and time for software.

·         Something like FedEx analogy

·         Package URL helps identify

·         Q&A

·         What can SPDX group do?

·         JC thinks that they should open source SEVA

·         Could contribute to LinuxF perhaps

·         Understand and need to balance needs of OSS consumers and dev communities

·         Don’t want to burden them

·         Automate

·         Challenge- How to distinguish enterprise quality OSS vs. pet projects

 

Tech Team Report - Kate/Gary[edit]

·         Tools

·         Starting to plan for GSoC submissions with Gary/Kate

·         Steve has been trained on releasing License list, so Gary now has backup

·         Steve has been working on some new tools for summarizing the SPDX_license_ids based on a new SPDX go library - currently its just supporting TV, but he hopes to add in the other formats

·         Specification

·         Gary & James have been working through SeVA XML and working through how it can be added.

Legal Team Report - Jilayne[edit]

·         License List

·         V3.4 out before Christmas

·         Big success to not have to scramble through holidays

·         Release notes in the GitHub repo

·         Instructions for requesting now live in Repo as well

·         Leverage GSOC work has been automated.

·         New frontier- Getting open hardware licenses on list

·         Expanding definition of what goes on the list

 

Outreach Team Report[edit]

·         None this month

Attendees[edit]

·         Phil Odence, Black Duck/Synopsys

·         Kate Stewart, Linux Foundation

·         Jilayne Lovejoy

·         Steve Winslow, LF

·         Alexios Zavras, Intel

·         Luis Villa, Tidelift

·         Jams Neushal, Neushul Solutions

·         Matthew Crawford, ARM

·         Kevin Nelson, Optim Tech UHG

·         Dennis Clark, NexB

·         Thomas Steenbergen, HERE

·         Bradlee Edmondson, Harvard

·         Gary O’Neall, SourceAuditor

·         Nicholas Toussaint, Orange

·         JC Herz, Ionchannel

 

 


Re: Jan 3 SPDX General Meeting Reminder

Phil Odence
 

Apologies for the extra email, but someone kindly pointed out an error on my part. The correct time for the General Meeting is 16:00 UTC.

Meeting Time: Thurs, Jan 3, 8am PT / 10 am CT / 11am ET / 16:00 UTC. 

 

From: "podence@..." <podence@...>
Date: Wednesday, January 2, 2019 at 8:17 AM
To: "spdx@..." <spdx@...>
Cc: JC Herz <jc.herz@...>
Subject: FW: Jan 3 SPDX General Meeting Reminder

 

Re-reminding now that most folks are back from the holidays.

 

From: "podence@..." <podence@...>
Date: Thursday, December 20, 2018 at 10:04 AM
To: "spdx@..." <spdx@...>
Cc: JC Herz <jc.herz@...>
Subject: Jan 3 SPDX General Meeting Reminder

 

Hello, all. Wishing the best to you for the holidays. As many will have time off between now and the New Year.

 

A new direction from SPDX is to expand into handling security information in addition to license and copyrights. JCC Herz will be talking about this in in the Jan 3 meeting. JC is the COO of Ion Channel, a software supply chain assurance and software logistics platform. JC co-wrote open source acquisition policy for the Defense Department in the mid-2000’s to curtail vendor-driven FUD about OSS, and has worked in large-scale enterprises to accelerate and enable verification, audit and continuous assurance of OSS for mission critical applications. 

 

Here's what she’ll be talking about-

“Evolving SPDX for Open Source Security: Lessons Learned from the Software Evidence Archive (SEVA)”

In the early days of enterprise OSS use, corporate concern tended to stem from licensing status, and SPDX operationalizes and automates risk management in that domain. As concerns around OSS have shifted towards security and supply chain risk, there are enterprise workflows for security approval, audit and compliance that require more and different details to augment transitive dependencies and licensing - some of which are not immediately obvious to developer communities outside the bureaucracies where these workflows exist. In the development of the SEVA (Software Evidence Archive), Ion Channel needed to augment the content of a standard SBOM with security, audit and compliance fields to satisfy the security, audit and compliance requirements of large IT bureaucracies in an an automated fashion. Because of large and escalating regulatory requirements for security, audit and compliance, these workflows are not going away. To that end, Ion Channel seeks to support SPDX with an open source XML implementation that includes these fields, so that large regulated customers can more easily adopt, maintain and update OSS applications and components. 

 

 

 

GENERAL MEETING

 

Meeting Time: Thurs, Jan 3, 8am PDT / 10 am CDT / 11am EDT / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

New dial in number: 415-881-1586

No PIN needed

The weblink for screenshare will stay the same at: 
http://uberconference.com/SPDXTeam

 

Administrative Agenda

Attendance

Minutes Approval: https://wiki.spdx.org/view/General_Meeting/Minutes/2018-12-06

 

Guest Speaker  – JC Herz

 

Technical Team Report – Kate/Gary

 

Legal Team Report – Jilayne/Paul

 

Outreach Team Report – Jack

 

Any Cross Functional Issues –All

 

 

L. Philip Odence
General Manager, Black Duck On-Demand
Synopsys Software Integrity Group
800 District Avenue, Suite 101, Burlington, MA 01803-5061
Note new work #: W: +1.781.313.6801; M: +1.781.258.9502

www.blackducksoftware.com  

 

 


FW: Jan 3 SPDX General Meeting Reminder

Phil Odence
 

Re-reminding now that most folks are back from the holidays.

 

From: "podence@..." <podence@...>
Date: Thursday, December 20, 2018 at 10:04 AM
To: "spdx@..." <spdx@...>
Cc: JC Herz <jc.herz@...>
Subject: Jan 3 SPDX General Meeting Reminder

 

Hello, all. Wishing the best to you for the holidays. As many will have time off between now and the New Year.

 

A new direction from SPDX is to expand into handling security information in addition to license and copyrights. JCC Herz will be talking about this in in the Jan 3 meeting. JC is the COO of Ion Channel, a software supply chain assurance and software logistics platform. JC co-wrote open source acquisition policy for the Defense Department in the mid-2000’s to curtail vendor-driven FUD about OSS, and has worked in large-scale enterprises to accelerate and enable verification, audit and continuous assurance of OSS for mission critical applications. 

 

Here's what she’ll be talking about-

“Evolving SPDX for Open Source Security: Lessons Learned from the Software Evidence Archive (SEVA)”

In the early days of enterprise OSS use, corporate concern tended to stem from licensing status, and SPDX operationalizes and automates risk management in that domain. As concerns around OSS have shifted towards security and supply chain risk, there are enterprise workflows for security approval, audit and compliance that require more and different details to augment transitive dependencies and licensing - some of which are not immediately obvious to developer communities outside the bureaucracies where these workflows exist. In the development of the SEVA (Software Evidence Archive), Ion Channel needed to augment the content of a standard SBOM with security, audit and compliance fields to satisfy the security, audit and compliance requirements of large IT bureaucracies in an an automated fashion. Because of large and escalating regulatory requirements for security, audit and compliance, these workflows are not going away. To that end, Ion Channel seeks to support SPDX with an open source XML implementation that includes these fields, so that large regulated customers can more easily adopt, maintain and update OSS applications and components. 

 

 

 

GENERAL MEETING

 

Meeting Time: Thurs, Jan 3, 8am PDT / 10 am CDT / 11am EDT / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

New dial in number: 415-881-1586

No PIN needed

The weblink for screenshare will stay the same at: 
http://uberconference.com/SPDXTeam

 

Administrative Agenda

Attendance

Minutes Approval: https://wiki.spdx.org/view/General_Meeting/Minutes/2018-12-06

 

Guest Speaker  – JC Herz

 

Technical Team Report – Kate/Gary

 

Legal Team Report – Jilayne/Paul

 

Outreach Team Report – Jack

 

Any Cross Functional Issues –All

 

 

L. Philip Odence
General Manager, Black Duck On-Demand
Synopsys Software Integrity Group
800 District Avenue, Suite 101, Burlington, MA 01803-5061
Note new work #: W: +1.781.313.6801; M: +1.781.258.9502

www.blackducksoftware.com