Hi all,

I'm comparing SPDX and Fossology's licenses IDs and encountered a little difficulty regarding the Sun Industry Standards Source License.
The SPDX id for the version 1.1 of the license is just "SISSL", while Fossology's is "SISSL-1.1". At first glance, it seems that Fossology's choice is more consistent with SPDX's naming scheme, and I don't see the benefits of removing the version number. It also seems that there is a 1.2 version of this license (http://gridscheduler.sourceforge.net/Gridengine_SISSL_license.html ).
So, would adding the version number to the ID be desirable / possible ?

Best,
Camille

--
Gouvernance Open Source - Alter Way www.alterway.fr

hi everybody,

if you use ninka, this might be useful to you.

With the help of Armijn i have been cleaning up some regressions and
improved some licenses.

The new code is now in the github repo:

http://github.com/dmgerman/ninka

- Renamed InterACPILic to IntelACPILic
- Renamed openSSLvar2 to Apachev1.0
- Split QtorGPLv2orv3exception to QtorGPLv2orv3 from the exception
- Better detection fo GPL lcienses
- BSD and MIT spdx licenses detected (prefixed with spdx ie. spdxBSD3)
- Added a bunch of licenses...

unless I find some major problems, I will release a new version in few
days.

--dmg


--
Daniel M. German "There is the greatest difference
between presuming an opinion to be
true, because, with every opportunity
for contesting it, it
has not been refuted,
and assuming its truth for the purpose
John Stuart Mill -> of not permitting its refutation. "
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

When: Wednesday, July 03, 2013 11:00 AM-12:00 PM. (UTC-05:00) Eastern Time (US & Canada)
Where: Bridge info enclosed

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

Hi Michel

I think the "Official Common Platform Enumeration (CPE) Dictionary" http://nvd.nist.gov/cpe.cfm is a good starting point for this topic.
another source to consider is ISO/IEC 19770

all the best!
-roger
;-r

Quoting "RUFFIN, MICHEL (MICHEL)" <michel.ruffin@...>:

hi,

I am currently a senior systems engineer at Nokia, and I can say
without reservation that we face this problem also, identifying
specific versions of software (binaries as well as sources). Binaries
can change, even if the source does not, if for example the compiler
is updated, or associated libraries. This is especially problematic
when the libraries are (as is often the case) dynamically-linked
shared libraries.

This is not my experience at all. In the Binary Analysis Tool I use fingerprinting using string constants, function names, variable names, and so on, and I can reliably tell versions of binaries apart (granted: the information has to be in my database). This is absolutely no problem at all.

armijn

--
Armijn Hemel, MSc
Tjaldur Software Governance Solutions

I am currently a senior systems engineer at Nokia, and I can say
without reservation that we face this problem also, identifying
specific versions of software (binaries as well as sources). Binaries
can change, even if the source does not, if for example the compiler
is updated, or associated libraries. This is especially problematic
when the libraries are (as is often the case) dynamically-linked
shared libraries.

Bill Boyle
Senior Systems Engineer, Nokia Mobile Phones, Itasca, Illinois

On Mon, May 13, 2013 at 9:56 AM, RUFFIN, MICHEL (MICHEL)
<michel.ruffin@...> wrote:

Dear all we are facing a very difficult issue: How to identify uniquely
Software.

In Alcatel-Lucent (ALU) we would like to link all our databases on SW (FOSS
SW, proprietary SW, FOSS SW coming in proprietary solutions, FOSS coming
from outsourcing contracts, …) The goal is to automate a lot of things:
royalty tracking, producing documentations on FOSS respecting the license
obligations automatically, knowing which ALU product is using what SW,
automatically connecting with tools such as Blackduck protex or Palamida or
any others of their competitors, …………………………………………….

The major issue is SW unique identification: Today we have the following:

Maven naming system: but it is limited to java open source libraries
ALU internal system (but so far limited mostly to commercial SW but we are
extending to FOSS but not perfect) and we have to interact with suppliers
and customers on this identification
Blackduck internal unique identification (One millions FOSS but do not cope
with proprietary SW and we do not want to be dependent of a company)
SPDX Check sums for binaries (but do not provide the same checksum with .zip
and .gpz)
SPDX Check sums on source codes but does not work if ALU is doing a small
modification to the comments in the file


I know that SPDX is not perhaps the best place to discuss this issue, but I
would like to engage a discussion on this topic

So my question here is: do you have similar concerns in your companies, and
what can we do to solve this issue (should we create a group on this?)

Michel

Michel.Ruffin@..., PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France




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

Dear all we are facing a very difficult issue: How to identify uniquely Software.

 

In Alcatel-Lucent (ALU) we would like to link all our databases on SW (FOSS SW, proprietary SW, FOSS SW coming in proprietary solutions, FOSS coming from outsourcing contracts, …) The goal is to automate a lot of things: royalty tracking, producing documentations on FOSS respecting the license obligations automatically, knowing which ALU product is using what SW, automatically connecting with tools such as Blackduck protex or Palamida or any others of their competitors, …………………………………………….

 

The major issue is SW unique identification: Today we have the following:

• Maven naming system: but it is limited to java open source libraries
• ALU internal system (but so far limited mostly to commercial SW but we are extending to FOSS but not perfect) and we have to interact with suppliers and customers on this identification
• Blackduck internal unique identification (One millions FOSS but do not cope with proprietary SW and we do not want to be dependent of a company)
• SPDX Check sums for binaries (but do not provide the same checksum with .zip and .gpz)
• SPDX Check sums on source codes but does not work if ALU is doing a small modification to the comments in the file

 

I know that SPDX is not perhaps the best place to discuss this issue, but I would like to engage a discussion on this topic

 

So my question here is: do you have similar concerns in your companies, and what can we do to solve this issue (should we create a group on this?)

 

Michel

 

Michel.Ruffin@..., PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

 

 

 

This is to help better understand current awareness and adoption of SPDX and to get some insight future plans and what we can do to shape that future.  http://www.spdx.org/survey  We started promoting the survey at the Collaboration Summit. Here is how you can help drive further participation:

Take the survey yourself. It should require 5-7 minutes of your time. (A good time would be…now.) 

Solicit friends, colleagues and other industry contacts.

So far we have a reasonable representation of the views of old timers, but we really need this to go broader.

1. Please, take the survey yourself. It should require 5-7 minutes of your time. (A good time would be…now. TGIF.) 
2. Solicit friends, colleagues and other industry contacts. (Feel free to use the text below, if it is helpful)

As you may know, I'm involved with SPDX, an industry standard for exchanging information about software package content and licensing. Please give 5-7 minutes of your time to take a survey which will help the SPDX group assess industry awareness and adoption of SPDX. Even if you know very little about SPDX, the group values your feedback. Thank you in advance.

http://www.spdx.org/survey 

New wiki looks great.

Scott: ++1

The LF hasn't installed a WYSIWYG editor yet but we can request it if

there's a need.

Jack: I'm thinking we should request one. Media wiki syntax while not difficult may seem bizarre to some people?

Scott: yes!

* Marc-Etienne Vargenau <Marc-Etienne.Vargenau@...> [2013-04-11 15:48]:

The e-mail address wiki@... given in page
http://wiki.spdx.org/view/Getting_started
to request an account does not seem to work.

Yeah, I know. I also sent a request to the LF.

You can email me directly in the meantime.

--
Martin Michlmayr
Open Source Program Office, Hewlett-Packard

Le 11/04/2013 12:58, Martin Michlmayr a écrit :

The wiki has been migrated to a proper wiki using MediaWiki. All
content (including past revisions) has been migrated.

You can find the new wiki at http://wiki.spdx.org/view/

Here's a "Getting started" guide:
http://wiki.spdx.org/view/Getting_started

And a set of proposed wiki conventions, although they will have to be
refined as we gain more experience with the new wiki:
http://wiki.spdx.org/view/Wiki_Conventions

If you have any questions, please let me know.

Hello,

The e-mail address wiki@... given in page
http://wiki.spdx.org/view/Getting_started
to request an account does not seem to work.

Best regards,

Marc-Etienne

--
Marc-Etienne Vargenau Marc-Etienne.Vargenau@...
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 1 30 77 28 33 OnNet 2103 2833

I glossed over the Getting Started link. Would it make sense to display it as "Getting Started Using this Wiki"?

Jack