--- On Wed, 9/26/12, D M German <dmg@...> wrote:

From: D M German <dmg@...>
Subject: licensing data of FOSS
To: spdx@...
Date: Wednesday, September 26, 2012, 1:40 PM

Hi everybody,

We are trying to create a Web site where we publish the
licensing data
of open source applications. This is work in progress, and
it needs
work.

We are trying to analyze different versions of applications
that appear
in Debian. Each app is broken down by license (as identified
by Ninka.

For example, zlib:


http://ag.cs.uvic.ca/project/1114/files/1/

or sqlite

http://ag.cs.uvic.ca/project/1302/files/1/

You can navigate the applications here:

http://ag.cs.uvic.ca/


Hopefully this will help in the development of SPDX.

--dmg


--
Daniel M. German           
     
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Bracewell, Robert
Sent: Friday, August 31, 2012 12:03 AM
To: spdx@...
Subject: Followup question after Linuxcon talk

Thanks for a great discussion on spdx its got me interested in wrapping spdx into my current release activities as a release manager.

Say for example I ship an SDK and for a customer to use this SDK they need to download a number of other files that were unable to ship within the package. What would be the best way with spdx to indicate such? Ideally if I could ship them I would but for reasons outside of my control I am unable to do so.

To date I have been using Nexus pro to decorate the artifacts that make up the bill of materials by adding metadata to this tool. The metadata i've been storing is inline with what spdx already tracks. I wrote my own Maven plugins to take care of the metadata aspect of adding it and pulling it out of Nexus when producing the bill of materials. What I am thinking is that instead of storing metadata i'll just attach an spdx file as an attached artifact with a classifier and for every artifact that is subsequently packaged it will just pull down the spdx files and aggregate.

Looks like I need to do some reading of the spec and whitepapers etc to get up to speed.

--
Robert
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Bracewell, Robert
Sent: Thursday, August 30, 2012 9:03 PM
To: spdx@...
Subject: Followup question after Linuxcon talk

Thanks for a great discussion on spdx its got me interested in wrapping spdx into my current release activities as a release manager.

Say for example I ship an SDK and for a customer to use this SDK they need to download a number of other files that were unable to ship within the package. What would be the best way with spdx to indicate such? Ideally if I could ship them I would but for reasons outside of my control I am unable to do so.

To date I have been using Nexus pro to decorate the artifacts that make up the bill of materials by adding metadata to this tool. The metadata i've been storing is inline with what spdx already tracks. I wrote my own Maven plugins to take care of the metadata aspect of adding it and pulling it out of Nexus when producing the bill of materials. What I am thinking is that instead of storing metadata i'll just attach an spdx file as an attached artifact with a classifier and for every artifact that is subsequently packaged it will just pull down the spdx files and aggregate.

Looks like I need to do some reading of the spec and whitepapers etc to get up to speed.

--
Robert
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx