Re: [spdx-tech] FOSDEM face-to-face meeting

[Philippe Ombredanne]

Hi Alexios:

We had to move the venue to Hotel Bedford and this was completed yesterday.
The key reason is we have many more registrations and wanted to make
sure we could have a better spot with comfortable and enough space!

See https://www.hotelbedford.be/en/meetings-and-events/

We will be in the larger Galileo room:
See http://www.immodeposit.com/projects/bedford/panos.html?s=pano1019#pano1019

There are likely many more options there.
--
Cordially
Philippe



On Fri, Jan 26, 2024 at 12:18 PM Alexios Zavras
 wrote:
>
> Hi all,
>
>
>
> We are organizing a face-to-face meeting in Brussels, just before FOSDEM. As 
> many of us will be there, we thought it would be a great opportunity to 
> gather and engage in some insightful technical discussions.
>
>
>
> Since a number of us will be present at the event organized by Philippe on 
> Friday, our meeting will take place right after that one, at the same place.
>
> So, mark your calendars for meeting us on Friday 2 February 2024 at 17:00, at 
> La Tricoterie!
>
>
>
> The primary topic of our discussion will be automatically processing the 
> SPDXv3 RDF ontology to create classes for various programming languages. This 
> topic aims to explore ways to make implementations of SPDXv3 handling much 
> easier and efficient.
>
> However, the discussion is not limited to this topic alone. We encourage you 
> to bring up any other technical subjects that you believe would be of 
> interest to the group. Your input and expertise would be greatly appreciated 
> and beneficial to our collective learning.
>
>
>
> There is no need to register, or even inform anyone about attending; just 
> show up!
>
> Looking forward to seeing you there and having an engaging discussion.
>
>
>
> --
>
> zvr
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>
> 



-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
AboutCode - Open source for open source - https://www.aboutcode.org
VulnerableCode - the open code and open data vulnerability database -
https://github.com/nexb/vulnerablecode
ScanCode - scan your code, for origin/license/vulnerabilities, report
SBOMs - https://github.com/nexB/scancode-toolkit
https://github.com/nexB/scancode.io
package-url - the mostly universal SBOM identifier for packages -
https://github.com/package-url
DejaCode - What's in your code?! - http://www.dejacode.com
nexB Inc. - http://www.nexb.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5504): https://lists.spdx.org/g/Spdx-tech/message/5504
Mute This Topic: https://lists.spdx.org/mt/103974053/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[spdx-tech] [ANNOUNCE] FOSDEM 2024 - Fringe event - open source SBOM and SCA tooling workshop on Friday 2024-02-02

[Philippe Ombredanne]

Hello everyone!
This is a one time announcement.
Are you heading to FOSDEM? Join us for a one-day workshop for
developers and users of open source SCA, SBOM, and license and
security compliance tools on Friday, February 2nd, 2024 in Brussels
just before FOSDEM 2024:
https://opencollective.com/aboutcode/events/fosdem-2024-fringe-workshop-on-foss-license-and-security-compliance-tools-ea75e63c

As distinguished SPDX experts, you are super welcome to join!
The event is also co-sponsored by SPDX.

The program will be an unconference with the day split in two: tools
developers share their plans in the morning and users share their
requirements in the afternoon.

Registration is required and free (including a free lunch and free
coffee), but we encourage your contributions to help us pay for the
event's expenses!
We booked at https://www.tricoterie.org/en that some of you may know
from past FOSS events.

We're also looking for generous sponsors to help fund the venue and
catering - you can contribute online directly or email me directly at
pombreda...@nexb.com

I look forward to seeing you there.
--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
AboutCode - Open source for open source - https://www.aboutcode.org
ScanCode - scan your code, for origin/license/vulnerabilities, report
SBOMs - https://github.com/nexB/scancode-toolkit
https://github.com/nexB/scancode.io
package-url - the mostly universal SBOM identifier for packages -
https://github.com/package-url
DejaCode - What's in your code?! - http://www.dejacode.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5483): https://lists.spdx.org/g/Spdx-tech/message/5483
Mute This Topic: https://lists.spdx.org/mt/103662233/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Handling invalid licenses

[Philippe Ombredanne]

Anthony:

On Thu, Mar 16, 2023 at 7:41 PM Anthony Harrison
 wrote:
> In generating SBOMs, I am encountering a lot of issues with licence 
> information obtained from either ecosystem meta data or actual source files 
> most do not appear to be using SPDX license identifiers. If I report the 
> actual licence text then the generated SBOM is invalid; however reporting it 
> as NOSASSERTION or NONE doesn’t seem correct because the author has made some 
> attempt at identifying the license albeit incorrectly.
>
> What is the correct behaviour when an invalid license is detected?

Can you share some concrete examples?

-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
AboutCode - Open source for open source - https://www.aboutcode.org


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5042): https://lists.spdx.org/g/Spdx-tech/message/5042
Mute This Topic: https://lists.spdx.org/mt/97657161/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[spdx-tech] [ANNOUNCE] License and Security Compliance tools users and developers meeting on Feb. 3rd 2023, one day before FOSDEM in Brussels

[Philippe Ombredanne]

Hi:

If you drop by FOSDEM, there is this one day event before FOSDEM, on
Feb. 3rd 2023, in Brussels.
https://opencollective.com/aboutcode/events/fosdem-2023-fringe-event-foss-license-and-security-compliance-tools-developers-and-users-workshop-bruxelles-2023-02-03-159433c1

Registration is needed but free (or for a fee) and we have limited seating.

FOSDEM Fringe event - Friday February 3rd 2023
FOSS license and security compliance tool developers and users workshop

We are organizing a one day workshop for developers and users of open
source compliance tools. This is planned in Brussels just before
FOSDEM on Friday February 3rd, 2023. We are inviting anyone interested
in open source license and security compliance tools to join.

The goal of this one day event is for open source developers, users
and contributors to exchange around tool requirements, plans, and
collaboration opportunities.

Which tools is this about? FOSS tools for software provenance
detection tools, license detection and compliance tools, code scanning
tools, package dependency analysis tools, container analysis tools,
SBOM creation and consumption tools, and license or vulnerability
databases

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
AboutCode - Open source for open source - https://www.aboutcode.org


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4913): https://lists.spdx.org/g/Spdx-tech/message/4913
Mute This Topic: https://lists.spdx.org/mt/96199732/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Multiple Licenses in a single LicenseRef?

[Philippe Ombredanne]

Hi Rose:
Welcome back!

On Fri, Dec 2, 2022 at 10:55 PM Rose Judge via lists.spdx.org
 wrote:

> Tern is a tool that can generate SPDX documents for containers.
> When we are collecting license information for Debian packages
> inside a container, we must scan the copyright files to gather any
> type of license information for that package. We do this with the
> Debian-inspector library; other package managers like apk or
> rpm can provide a direct license for a package with a straightforward
> command.

First, thank you for using the debian-inspector library
https://github.com/nexB/debian-inspector !

I have observed that RPM and Alpine seldom provide straightforward
package licenses.
They each provide a brief license summary but based on extensive scan
reviews my take is this:

- Alpine has a fair share of approximative license statements that are
outdated and out of sync with the code,
- RPMs license tags are heavily summarized hiding several details;
extra attached license texts need scan treatment to make sense of.
- In contrast, Debian is extra verbose and is lacking the
summarization provided by these two.

Nothing is perfect in this lowly world.

> This means that licenses associated with a debian package
> typically look something like this after scanning the copyright text:
> GPL-2, GPL-2+, GPL-3+, LGPL, LGPL-3+, MIT, public-domain
>
> Is it possible to create a LicenseRef of the entire string of multiple 
> licenses? I.e.:
> PackageLicenseDeclared: LicenseRef-123456
> LicenseID: LicenseRef-123456
> ExtractedText: Original license: GPL-2, GPL-2+, GPL-3+, LGPL,
> LGPL-3+, MIT, public-domain

You could of course do this, but this would create mostly harmless
SPDX documents depleted of actionable information. I have seen
perfectly valid SPDX documents created this way in the docfest using
only local LicenseRef and they are mostly useless: they require full
reprocessing to re-detect the licenses (with ScanCode).

> Or, does the spec require that we separate each license into a separate
> LicenseRef?

There is no requirement in the spec to otherwise prohibit you to
happily create a massive LicenseRef with the major side effects I
mentioned above and below.

> The issue with the latter option is I’m not sure choosing AND
> or OR to join the various license refs is something Tern should be doing
> as each infers a different compliance obligation.

You can combine these all with an AND because this is the meaning of
what you get from a Debian copyright file.
But the caveat is that MIT, public-domain are NOT license keys and not
SPDX ids either. These are merely references in the style of a local
LicenseRef and their actual meaning is entirely determined by the
license or noice text that comes after them.

Sadly enough, existing tools all assume incorrectly that these Debian
codes are license keys and end up doing a big disservice to their
users with fairly inaccurate or misleading license data at scale. The
devil is in getting the details right.

The solution is to use ScanCode and since tern already embeds it
already, you should look at the code we crafted to properly detect and
make sense of Debian copyright files whether they are structured
machine-readable files or legacy non-structured.

ScanCode has about 2000 lines of Python code (on top of the
debian-inspector code base) to process these. This gives a sense of
the complexity of the task at hand. There is no other tool that can
make sense of Debian copyright files like ScanCode that I have heard
of.

The common Debian license symbols are listed there:
https://github.com/nexB/scancode-toolkit/blob/d64acdded0b1f9e760cb9a5e47aecffab814b811/src/packagedcode/debian_copyright.py#L987
But there are hundreds of others that are not reliably mappable to
SPDX. You need a full scancode detection on the license text or notice
that follows in the deb822 paragraph. There is also a notion of
primary/default and secondary licenses that is not entirely trivial to
capture and ScanCode handles this too.

You can see the toolkit code here:
https://github.com/nexB/scancode-toolkit/blob/develop/src/packagedcode/debian_copyright.py
and here:
https://github.com/nexB/scancode-toolkit/blob/develop/src/packagedcode/debian.py

And this is used also in ScanCode.io for Debian/Ubuntu for VM and
docker image scanning in
https://scancodeio.readthedocs.io/en/latest/

Please tell me how I can help so this becomes easy enough for you to
reuse this in tern.
--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
AboutCode - Open source for open source - https://www.aboutcode.org
VulnerableCode - the open code and open data vulnerability database -
https://github.com/nexb/vulnerablecode
ScanCode - scan your code, for origin/license/vulnerabilities, report
SBOMs - https://github.com/nexB/scancode-toolkit
https://github.com/nexB/scancode.io
package-url - the mostly universal SBOM identifier for packag

Re: [spdx-tech] Another party claiming that SBOM is bad

[Philippe Ombredanne]

Hi Dick:
Thank you for this and your other email wrt. the ITIC SBOM push back

On Wed, Nov 30, 2022 at 8:35 PM Dick Brooks
 wrote:
> https://insidecybersecurity.com/share/14118
> Wow, some people seem to think this “SBOM thing” looks like the birthchild of 
> communism and the black plague.
> I don’t understand why people are so afraid of SBOM.  It’s just a text file. 
> WAZZUP with that.

Here are direct links for reference:
- 
https://www.uschamber.com/assets/documents/221122_Coalition_SBOMs_S.4543_FY23NDAA_ArmedServices_HomelandCommittees.pdf
- https://www.itic.org/documents/public-sector/ITILettertoOMBreM-22-18.pdf

There is something I find puzzling when I see the ITIC
membership
https://www.itic.org/about/membership/iti-members

This reads like a who's who in tech and a large number of the
contributors here and elsewhere are likely employed by these firms
including several core contributors and chairs of this group!

Are these organizations really representative of all their members' positions?
I cannot understand how all these ITIC member companies could be
supporting and be against SBOM at the same time.

I would kindly urge employees of the companies listed at
https://www.itic.org/about/membership/iti-members
to reach out to this organization and/or their internal contact to
apply pressure and sort out this mess.

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4864): https://lists.spdx.org/g/Spdx-tech/message/4864
Mute This Topic: https://lists.spdx.org/mt/95366174/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Reminder - meeting tomorrow on License Namespaces

[Philippe Ombredanne]

Dear David:

On Thu, Jun 16, 2022 at 6:57 AM David Kemp  wrote:
>
> Philippe,
>
>> I am not sure I read you correctly but if are you suggesting that
>> Dennis, other ScanCode contributors and I are "refusing to collaborate
>> on deconflicting local IDs" for SPDX license ids, that's quite the
>> opposite.
>
>
> I did not think that, and I sincerely apologize for ineptly giving that 
> impression. My intention was to thank Dennis for the opportunity to learn 
> about ScanCode, and to express puzzlement that a namespacing approach was 
> being considered.
>
> I hope that processes and procedures for maintaining a coordinated license 
> list can be worked out, and I'll try to avoid further interfering with that 
> process.

You are not interfering at all... and I found your reply and insights
super useful. I do not know your background, but it is clear that you
have experience in this domain. So please do not stop!

-- 
Cordially
Philippe Ombredanne


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4584): https://lists.spdx.org/g/Spdx-tech/message/4584
Mute This Topic: https://lists.spdx.org/mt/91653387/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Reminder - meeting tomorrow on License Namespaces

[Philippe Ombredanne]

e incorrectly assuming that Dennis, ScanCode and its
contributors are "not agreeing on a unified local ID list". Again
that's quite the opposite and speaking on behalf of this community, I
am 100% for a unified license ID list which will benefit everyone and
be a disservice to none.

Please tell me if this is a correct reformulation: you are suggesting
having a single, unified list of license identifiers maintained at
SPDX and assigned on a first-come-first-served basis. And with a
simple rule that no two ids conflict ignoring case and no two ids
point to the same text (say using SPDX matching guidelines).

If this is what you suggest, I couldn't agree more and I would support
this 100%. Weirdly enough I do not think that this has ever been
suggested before. Let's do it! This feels massively simpler and more
efficient than qualifying license ids with a namespace.
--
Cordially,
Philippe Ombredanne


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4582): https://lists.spdx.org/g/Spdx-tech/message/4582
Mute This Topic: https://lists.spdx.org/mt/91653387/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] capitalization rules for SPDX license ids and operators

[Philippe Ombredanne]

Alexios, Jilayne:

On Thu, Jul 29, 2021 at 9:52 AM Alexios Zavras  wrote:
> You can refresh your memory on the discussions (2015-2020) by reading 
> https://github.com/spdx/spdx-spec/issues/63
> I still like my example from that thread: Do we really want to be able to 
> understand
> Mit and gpl-2.0 And Gpl-1.0+ aNd ePl-1.0 aND isc
> or can we simplify our lives and have one way of expressing the combinations?

>> From: Spdx-tech@lists.spdx.org  On Behalf Of J 
>> Lovejoy
>>> However, please be aware that it is often important to match with the case 
>>> of the canonical identifier on the SPDX License List. This is because the 
>>> canonical identifier's case is used in the URL of the license's or 
>>> exception's entry on the List, and because the canonical identifier is 
>>> translated to a URI in RDF documents.
>> I'm wondering - was there a particular reason that the license expression 
>> operators are case-sensitive (while the license ids are not)?

IMHO it would be a good time to revisit this.
The case of license identifier does not and never did really matter
otherwise. It does not matter to users. And most tools do not care
either.
The tyranny of a serialization format (e.g. RDF) or a technical
requirement such as URL on a website should not impact everyone. These
should be solved differently.

What about adopting a simple way: define once for all that a canonical
license expression and identifier representation are either all
lowercase or all uppercase and be done with this topic for good.
-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4140): https://lists.spdx.org/g/Spdx-tech/message/4140
Mute This Topic: https://lists.spdx.org/mt/84509878/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[spdx-tech] Using SPDX for Python packages license documentation

[Philippe Ombredanne]

Dear Special People Doing eXceptional things:

FYI, I have been working with the Python community to specify how
Python package distributions can use SPDX license expressions for
their Core metadata.

The draft of this spec (called a PEP for Python Enhancement Proposal) is at:
https://www.python.org/dev/peps/pep-0639/

Comments and feedback are welcomed at:
https://discuss.python.org/t/2154

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3919): https://lists.spdx.org/g/Spdx-tech/message/3919
Mute This Topic: https://lists.spdx.org/mt/77195586/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Tech Meeting Agenda

[Philippe Ombredanne]

Hi Nisha:

You wrote:
> Rose and I would really like to be able to apply for GSoC this year.
> I wonder if the SPDX community can help us with this, specifically
> with providing tips on filling out the application and vouching for Tern.

I would be happy to help and usher you through the process and vouch
(for you, Rose and the Tern project) and more in anyway I can. Feel
free to reach out to me off-list. We can further iron out the details
in person @ FOSDEM in Brussels since you have planned to join the
pre-FOSDEM hackathon at
https://docs.google.com/document/d/1UphruKKAlsoUEidPCwTF2LCcHFnQkvQCQ9luTXfDupw/edit#
--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com

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

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

[spdx-tech] [ANNOUNCE] Open source license compliance tooling meeting and hackathon on January 31st 2020 pre-FOSDEM fringe event in Bruxelles, Belgium

[Philippe Ombredanne]

If you care about open source compliance automation and if you are
going to FOSDEM there is a one day hackathon and meeting taking place
the day before FOSDEM on Friday January 31st as "fringe" event, in
Bruxelles, Belgium.

The topic is open source compliance tooling and automation... the
format is an unconference. I expect several open source projects in
that space to be represented there including ORT, Fossology,
ClearlyDefined, SPDX tools, Scancode and many more.

I am co-organizing this with Michael Jaeger from Fossology.

See 
https://docs.google.com/document/d/1UphruKKAlsoUEidPCwTF2LCcHFnQkvQCQ9luTXfDupw/edit#heading=h.p2d7mni4lrcu
for details.

To "register", just add you name to this document! (alternatively you
can reply to me off list too)

I look forward to seeing you there!
--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com

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

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

[spdx-tech] Working with Python maintainers to adopt SPDX license expressions

[Philippe Ombredanne]

All:
I started working with the Python community to draft what we call a
PEP (Python Enhancement Proposal) to adopt SPDX license expressions to
document the license of Python packages.
You can join the discussions here:
https://discuss.python.org/t/improving-license-clarity-with-better-package-metadata/2154/57
And see, comment and propose updates to the draft PEP here:
https://github.com/pombredanne/spdx-pypi-pep/pull/2
-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com

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

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

Re: [spdx-tech] "Or later" operator is not well defined

[Philippe Ombredanne]

Hi David:

On Mon, Jul 1, 2019 at 9:00 PM Wheeler, David A  wrote:
> Philippe Ombredanne  wrote:
>> What looks as a version number in an SPDX license identifier is NOT
>> like a software version number. This is purely indicative and is not
>> something that is specified to have any meaning. Actually nothing in
>> an identifier has any specified meaning at all.
>
> I know, that's the defect we're trying to fix.  There's an "or later"
> operator in the SPDX license expressions that has no defined meaning.
> It *implies* a use of the version number field in the SPDX license id,
> but fails to actually state this, so it needs to be stated.

This "+" aka. "or later" operator is indeed in need for a fix. The fix
we need is retirement, not expansion. It has served its purpose and is
no longer needed IMHO.

It has now been replaced mostly by concrete licenses with their own ids.
If there is anything we could fix that would be to check if there are
**any** license that would need such a variation. I do not known of any
that is in any kind of usage, even rare usage. MPLs, CPLs and EPLs do
not have such variation (they always allow any other version AFAIK). All
the FSF licenses have been taken care of. So I do not think there is
anything left.

This + seems to be now only a source of bloat and rightful confusion.

>> It just happens that as a convenience, folks like to put version
>> numbers in licenses and these have been carried on in the license
>> identifiers.  You could have a license id of 234dssds-23.3475 and
>> that would be OK. So  please do not start to try to infer versions,
>> relations and other things based on identifier strings, that's a
>> dangerous slope.
>> Instead, you may want and could track relations between licenses, as
>> attributes of a license. For instance you could track that EPL-1.0
>> next version is EPL-2.0 and so on. But this becomes an explicitly
>> stored relationship and not something vaguely inferred from opaque
>> ids.
>
> Requiring humans to ignore the version numbers embedded in license ids
> is the MUCH MORE dangerous slope.
>
> By that theory it would be okay to have LICENSE-1.0, followed by
> LICENSE-3.0, followed by LICENSE-2.0.  Then "LICENSE-3.0+" would
> include "LICENSE-2.0".  That would be horrifically awful for
> usability, and basically guarantee mistakes.

I am not saying you should ignore anything from an id string... I am
just saying that no id part has any special meaning. Actually there are
no parts in an id at all and there is no version part. The meaning is in
the text referenced by the id and not in the id.

Furthermore, the legal team assigns ids sensibly and they would never
come with something that does not make sense. So your theoretical case
would not happen in practice.

Instead, the proper way to track relationships between versions (and more
generally between licenses) would be to do that with attributes, not
with ids.

--
Cordially
Philippe Ombredanne

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

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

Re: [spdx-tech] "Or later" operator is not well defined

[Philippe Ombredanne]

Dear Vladimir:

On Mon, Jul 1, 2019 at 7:58 PM Vladimir Sitnikov
 wrote:
>
> Philippe>And in the same way,  the -only and -or-later suffixes applied to 
> some
> Philippe>ids have no meaning whatsoever of their own
>
> Even though currently "-or-later" is an opaque string, it looks like it might 
> make sense to add "only this version" modifier to "spdx expressions".
> What do you think?
>
> How could it look like?
> EPL-1.0 ONLY
> EPL-1.0-only
>
> The second option is not that bad in my opinion.

I do not see the purpose of changing the expression syntax for
something which is at best rare and arcane beyond a few of the common
FSF licenses and this has been addressed alright.
As for your second option "EPL-1.0-only" that's a new license id
alright which is fine for the rare cases when and if you would want to
track these kind of options in a more sophisticated way than with a
"+". It does not require any changes to the spec as again, identifiers
have no meaning at all. They are just made so that they are easy to
read and remember for us poor humans... But we could just as well have
assigned 2342342sSDSFE423 as an id to the MIT license: that would be
silly but that's just to highlight my point. That's actually a good
thing that they have no meaning because that way they do not have to
be parsed: they were never designed for that, hence you cannot easily
infer a syntax to break them in parts: they have no parts, no part
separator, no prefix, no suffix and no version (even though it may
look like it).

--
Cordially
Philippe Ombredanne

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

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

Re: [spdx-tech] "Or later" operator is not well defined

[Philippe Ombredanne]

David, Vladimir:

On Mon, Jul 1, 2019 at 6:34 PM David A. Wheeler  wrote:
> > From: Vladimir Sitnikov 
> > It looks like you are inclined that "SDPX should have some definition of 
> > or-later". That is good to know.
> I think standards should be as clear and precise as possible, so sure.
> David>Maybe we should claim that a version number is the first match
>
> > How about Spencer-86, Spencer-94, Spencer-99?
> > How about Unicode-DFS-2015, Unicode-DFS-2016?
> > W3C-19980720, W3C-20150513, W3C?
>
> None of those match the proposed pattern, so by my proposal none of them have 
> a version number.  I'm fine with that.  The Spencer-86 can be reworked that 
> as Spencer-86.0.  If someone wants something different propose that instead.
>
> > David>Maybe we should claim that a version number is the first match after 
> > a "-" to some pattern like this regex:
> > How that classifies 1.3a vs 1.3c? Is "c" a part of the license name?
>
> Yes, as defined by the proposed regex, and I did that on purpose.
> This is all just a discussion right now, of course.  Perhaps people think a 
> different pattern would be better.  But "1.3c" is a plausible version number.


What looks as a version number in an SPDX license identifier is NOT
like a software version number. This is purely indicative and is not
something that is specified to have any meaning. Actually nothing in
an identifier has any specified meaning at all. It just happens that
as a convenience, folks like to put version numbers in licenses and
these have been carried on in the license identifiers.   You could
have a license id of 234dssds-23.3475 and that would be OK. So please
do not start to try to infer versions, relations and other things
based on identifier strings, that's a dangerous slope These are opaque
strings used as "natural keys" nothing more than that.

Instead, you may want and could track relations between licenses, as
attributes of a license. For instance you could track that EPL-1.0
next version is EPL-2.0 and so on. But this becomes an explicitly
stored relationship and not something vaguely inferred from opaque
ids.

And in the same way,  the -only and -or-later suffixes applied to some
ids have no meaning whatsoever of their own. They just happen to be
handy IDs for licenses. They do not need to be specified either: again
identifier are opaque ids.

-- 
Cordially
Philippe Ombredanne

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

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

Re: [spdx-tech] "Or later" operator is not well defined

[Philippe Ombredanne]

David, Vladimir:

On Thu, Jun 13, 2019 at 9:40 PM David A. Wheeler  wrote:
> The last number (if there is one) in a SPDX license id is the version number.
> Everything before that number (and its leading “-“), is the unversioned ID.
> There’s a recent exception for the GPL etc., but those are exceptions.

As far as I know this is completely unspecified. So it may look like
it, but it will most not likely not hold on all keys, not hold in the
future and not be guaranteed. There is no specific relationship
between any license identifiers so far (I am not saying that it would
be bad to have one though)

-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com

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

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

Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion

[Philippe Ombredanne]

Kyle:
On Wed, Mar 13, 2019 at 6:54 PM Kyle Mitchell  wrote:
> How will you handle name disputes?  How will you deal with
> complaints (to SPDX/LF) about the identifiers being used by
> private parties under their assigned namespaces?
>
> Prior art: https://www.npmjs.com/policies/disputes

Thankyou: that's all valuable things to consider indeed and hard
earned from the leftpad issues.
Though I doubt mere licenses will ever be as successful as npm!
-- 
Cordially
Philippe Ombredanne

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

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

Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion

[Philippe Ombredanne]

Richard:

On Mon, Mar 11, 2019 at 10:32 PM Richard Fontana  wrote:
> This sounds appealing to me (if I'm understanding it correctly). From
> Red Hat's perspective one of the great impracticalities of SPDX has
> been that, after many years of SPDX's existence, its adopted
> identifiers still represent only a small portion of the licenses
> encountered in much of the the software we encounter in our product
> and project development.

Let me recap my understanding:

I think everyone agrees that we want want more licenses in SPDX.
Anyone against this, please voice your concerns now.

The review of new licenses for list is an all-volunteers process with
a certain level of ceremony explained here
https://spdx.org/spdx-license-list/license-list-overview and therefore
it takes time. But it takes too much time.

Why do I want an id for stable/well-defined licenses? This would make
it easier to talk about and exchange licenses and it does not require
the reproduction of the license text at all times.

Why not using a LicenseRef for these? This would still require
reproducing always the license text in every SPDX document, which does
not help when there is no document (e.g. in a package manifest such as
an npm or an RPM). NOASSERTION as used for now in ClearlyDefined is
also fraught with problems as highlighted by Richard earlier.

There are two main use cases for more licenses: private or public
licenses. The main concern is to ensure that these license ids are
unique enough in both cases, and that there is minimum or no
duplication of license texts across ids.

-  For private licenses, the only concern is to ensure that names are
unique enough. Mark suggested using a reverse domain name prefix for
this. I suggested a lightweight registration of a prefix that would
not require one to own/buy a DNS domain name. The two can likely work
together (e.g. you could use a domain name or anything and still do a
one time registration). In anycase, I become the master of the license
texts and ids in my namespace.

-  For public licenses one could use a prefix/namespace plus the
optional registration of actual license id/name/texts. A
content-defined fingerprint id may not help in practice as I explained
in a previous email as too brittle.

In light of all this, here is my suggestion:


1. Establish a lightweight, easy and fast registration process for
SPDX license id prefix (aka namespace). As simple as a quick PR in a
Git repo. This prefix can be made of any character that would be a
valid license identifier. This is used to prefix ids (and not in
LicenseRef). This way you can use both DNS and non-DNS names alright.
This can be used for both public and private namespaces.

2. Establish a lightweight, easy and fast registration process for
prefixed SPDX license ids in an existing namespace. As simple as a
quick PR in a Git repo.

Submissions are very lightly moderated (we want to register licenses
but not cooking recipes).

There is no need for any markup or other annotations at this stage:
only basic id, name, text and possibly URLs.

When submitted, there is an automated deduplication triggered (e.g. we
run a license scan on this license text) and if a submission is the
same or mostly the same as any existing SPDX licenses, the check
fails. (This is a CI script). The submitter can then reuse instead a
pre-existing license id.

4. We add a status for licenses records such that they are either
reviewed/approved by the SPDX legal team or not. The submissions of
namespaced ids would NOT be in the approved status.

5. From that point on, the SPDX legal team can use not only direct
requests for license additions but also can funnel selected public
registrations as candidates for inclusion in the main SPDX
non-namespaced License List.

Done.

-- 
Cordially
Philippe Ombredanne

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

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

Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion

[Philippe Ombredanne]

Richard, Jeff:

On Mon, Mar 11, 2019 at 10:32 PM Richard Fontana  wrote:
> Use of "LicenseRef" (not to mention something like
> NOASSERTION) is a nonstarter for the use cases we are most interested
> in. What we've actually done in some cases is use the nonstandard
> identifiers created by nexB.

Agreed. What I am trying to achieve here is to make these become "standard" and
known at SPDX. I think this is possible.

On Sun, Mar 10, 2019 at 12:44 PM Jeff McAffer
 wrote:
>> IMO the "ideal" here is that there is some automated way of
>> "fingerprinting" license texts such that two parties, given more or less
>> the same text, can independently come up with the same id. At that point
>> you would not need a registry, just a shared algorithm. When/if eventually
>> SPDX does recognize a given license and gives it a formal id, there could
>> be a relatively simple aliasing step where SPDX id "SomeCoolLicense-1.0"
>> is AKA "LicenseRef-43bdf298"

This ideal works in theory but for several reasons I outline below would be
too brittle in practice as you would have different fingerprints too often for
this to be working. Instead running a full license detection is a better way
to dedupe things. And this requires some form of centralization but could be
fully automated alright.  The other thing is that IMO giving a name/id does
matter a lot: the license named 43bdf298 is not really human friendly.

Now even if license-text-fingerprint-as-id were to work out, the difficult part
is not so much the algorithm for computing these, but the content you feed for
fingerprinting. And that part is not easily to automate:

 - For instance, is a copyright part of the license or not (I think not, but
   YMMV)?

 - Or what about statements around a license? For instance these two SPDX
   licenses may not really deserve a different id yet they have one:

   https://spdx.org/licenses/bzip2-1.0.6.html and
   https://spdx.org/licenses/bzip2-1.0.5.html

   The LICENSE file in the original code archives does not have a patent
   disclaimer statement footer seen in bzip2-1.0.5's SPDX license text.
   That footer is present on the archive.org website only. I would not treat
   this as part of the license, but this was treated as part of it here. This
   is a judgment call.

 - Or for instance, there are 6+ version of the text of the GPL-2.0 which are
   really the same but would fingerprint differently.

Therefore a fingerprint algorithm would be hard to generalize as there would be
many exceptions or a simple one would be too brittle in too many cases.
Deduping is best achieved by license detection with a full diff (which
is what scancode does FWIW).

Let me follow up with my suggestion.
--
Cordially

Philippe Ombredanne

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

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

Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion

[Philippe Ombredanne]

Hi Jilayne:
On Sat, Mar 9, 2019 at 6:40 PM J Lovejoy  wrote:
> Hi Philippe,
> I’m a bit lost on what the goal of this is. Can you provide a bit more 
> context.
>
> I looked at a couple entries and noticed, for example, this one:
> https://github.com/nexB/spdx-license-namespaces-registry/blob/master/scancode/licenseref-scancode-bsd-innosys.spdx
>
> which then points to this: 
> https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/bsd-innosys.yml
>
> which notes that this is common in the Linux kernel.
>
> Weren’t we going to add to the SPDX License List some of the other common 
> licenses you all were finding in the kernel?
>
> > and https://github.com/nexB/spdx-license-namespaces-registry/pull/1
> >

I sent it quickly during the legal team call on Thursday and sorry for
not providing much background then.
Here it is:

There has been a recent discussion initiated by Mark Atwood to create
stable, yet private SDPX identifiers.
And there is a similar need for ScanCode licenses too (See
https://github.com/nexB/scancode-toolkit/issues/532 and has been
requested by several users too.

Through the discussions, Kate and Gary suggested that we could reuse
LicenseRef and create an SPDX document for each license.  The example
repository and example pull request that I linked above are to provide
an example of what this would look like if we were to have such a
system where there could be two level of registrations: simple
namespace and namespace + licenses ... all using LicenseRef
The benefit is that there would be no change to the spec required at
all and could be used today.
Now, the actual content of the repo I linked is based on a completely
random subset of non-SPDX-listed licenses that exists in ScanCode, so
their actual content is not relevant here.

I reckon that I still owe you to submit all the licenses that we found
in the kernel that are not yet in SPDX I am terribly late on that
part.

The two are not directly related... yet I could see the submission of
namespaced licenses as being a funnel for actual additions to the SPDX
list proper. Some may be worthy of that addition while some may not
make the cut.

--
Cordially
Philippe Ombredanne

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

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

Re: [spdx-tech] A proposal for SPDX Private License Identifiers. Example: .com.amazon.-.ASL-2.0

[Philippe Ombredanne]

Hi Mark:

On Mon, Feb 4, 2019 at 9:57 PM Mark Atwood wrote:
> Just following up, does anyone have any comments or suggestions for my
> proposal for SPDX Private License Identifiers?

We surely could use a way to have namespaces of sorts for extra, non
SPDX-listed license identifiers. This is something that I could use
alright for ScanCode where we track roughly an extra 1000 licenses and
exceptions more than in the SPDX list (ScanCode has 1456 licenses and
exceptions and there are 415 in the SPDX list)

ScanCode handles this today by returning a well defined LicenseRef-xxx
in SPDX documents for non SPDX-listed licenses . And a recent
contribution by Tobias Furuholm created a "namespace"-like convention
to use this for ids for such licenses:

License-Ref-scancode-

The project  guarantees the  to be stable
overtime (e.g. they can be deprecated if needed but never deleted) .
See https://github.com/nexB/scancode-toolkit/issues/532 for some discussions

> SPDX-License-Identifier: .com.amazon.-.ASL-2.0
> https://aws.amazon.com/doc/ASL-2.0
[...]
> In a SPDX-License-identifier declaration, a Private License Identifier can
> optionally be followed by a URI pointing to the canonical license text.
> This URI should be under the control of the entity that controls the DNS
> namespace of the Private License Identifier.

SPDX-License-Identifier is not declaring an id, but instead using ids
in an expression so I think this would break the license expression
syntax may be? Otherwise how would express something such as:
my-private-license1 AND my-private-license2

As a recap I think that:
1. having some kind of namespacing is a great idea
2. I find reverse DNS and dots hard to read and I would likely make
many typos when writing/typing these down.
3. an SPDX-License-identifier is a whole expression so changes should
not break license expressions.
4. it might be clearer to distinguish naming (giving an id) and
documenting that id separately (providing extra information about this
id such as at a URL to a text or other data) and not try to put them
all in one place.
5. LicenseRef (and possibly some specified or conventional way to
structure them) may be a way to consider
--
Cordially
Philippe

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

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

Re: [spdx-tech] SPDX tech agenda - extending Annotations in 2.2

[Philippe Ombredanne]

All:
I am not able to join this week due to a conflicting appointment.
--
Cordially
Philippe

On Tue, May 1, 2018 at 4:35 PM, Kate Stewart
 wrote:
> Hi,
> Just a reminder that we'll be having our weekly tech call in a couple
> of hours,  and the topic for today is how to handle some of the
> requested changes to annotation types in SPDX Spec 2.2.
>
> The github issues to review prior to the meeting is at:  #25
> Expand §8.3.4 Annotation Type with new values (LICENSE, PATENT, COPYRIGHT,
> EXPORT, TRADEMARK) and change cardinality
>
> Goal is to confirm we're all ok with the enhancement, come out with an
> outline of the approach, and next steps to add it.
>
> Meeting info:
>
>  Tuesdays at 17:00 UTC (10:00AM PDT, 11:00 MDT, 12:00PM CDT, 1:00PM EDT,
> 18:00 WAT, 19:00 CEST).
>  Optional dial in number: +1-415-881-1586
>  No PIN needed
>
>
> Thanks,
> Kate & Gary
>
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [spdx-tech] SPDX short-form IDs site

[Philippe Ombredanne]

Steve:

On Wed, Apr 11, 2018 at 8:56 PM, Steve Winslow
<swins...@linuxfoundation.org> wrote:
> Hello all,
>
> I've been working on a few pages on the SPDX website on why and how to use
> SPDX short-form IDs. This is intended to be developer-focused, usable by
> someone who isn't otherwise familiar with SPDX, to get them to start putting
> SPDX identifiers in their source code.
>
> The first cut at this is now available at https://spdx.org/ids. There are a
> few "read more..." pages linked from that URL. These pages are visible but
> not yet linked from the rest of the site.
>
> I'd welcome feedback and edits, if you have any, before linking this into
> the main site. In particular it would be great to know if it looks okay on
> other browsers, since this is the first time I've worked with Drupal and I
> may have bent a few things...

You positively rock!

My only comment is that I did not see a GPL license in the expression
animation ;)

BTW, I just pushed an update to Scancode the other day that at last
detects all these correctly.
And deals with less well formed variants too.

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [spdx-tech] spdx/tools-go

[Philippe Ombredanne]

Hi Will,

On Fri, Feb 23, 2018 at 1:09 PM, Will Norris via Spdx-tech
<spdx-tech@lists.spdx.org> wrote:
> SPDX Tech folks,
>
> I'm curious, does anyone know if the spdx/tools-go repo is being actively
> maintained or developed right now?  Just looking at the commit history, my
> guess is that it's not... it looks like it was originally written by Vlad
> Velici, but that he's no longer working on it?  So then I guess a better
> question is if anyone is really interested in it?  Do you know if anyone is
> actively using it?

It is not super active indeed. And I do not know who is using it.
Vlad made it as part of his GSoC project so it would be great to
further it (and it make even more sense that Google would benefit from
it)

> I'm investigating using it in some work we're doing here at Google (since
> all of our existing compliance tooling is already in Go), and so had two
> questions that related to the above:
>  1. If I send some changes, is there anyone around to merge them?  (Philippe
> looks to have merged the last couple of PRs)

I will review and merge these alright switftly. Though you could very
quickly become the maintainer/co-maintainer on this ;)

>  2. Who might I break if I made major changes?  That is, how important is
> backwards compatibility?  (I haven't looked at the code closely enough to
> know whether I would even propose any breaking changes, but curious to know
> from the outset who would be impacted)

We can tag the repo and break compatibility alright. I would not be
too worried there.
If anything that would make folks that use it and may be broken chime
in and participate.
I am not saying this in an evil way, of course, but in a positive way!

> Also, does anyone have a sense of how widely adopted the various versions of
> SPDX are?  For our initial purposes, we only care about 2.1, since that's
> what scancode-toolkit emits.  1.x and 2.x seem different enough that
> supporting both would be a bit of work, so I'd be tempted to drop 1.x
> support altogether.  (Again, provided that this wouldn't actually break any
> active users)

Dropping 1.x support would make 100% sense. I would not even
contemplate using and supporting 1.x at this stage.
And again that's what version control is used for. So no worries.

And as a side note: great to know that you can have some use for
scancode-toolkit

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [spdx-tech] New SPDX Generation Tool

[Philippe Ombredanne]

On Fri, Feb 9, 2018 at 4:11 AM, Ben Boyter <b...@boyter.org> wrote:
> Hi All,
>
> Thanks for the feedback before when I was seeking clarification about how to
> generate portions of the SPDX. One of the issues I had with getting SPDX
> adopted was to have a simple tool that would do it can could be hooked into
> CI pipelines and the like So I made one,
>
> https://github.com/boyter/lc
>
> I just released version 1.0.0 and would love to get some feedback on it. Its
> written in Go which was a decision I made in order to learn it and because I
> wanted a single binary that was easy to distribute. It works pretty well for
> all of the example projects I have tried and I will be using it on client
> sites where possible.

This is awesome!
You may have not seen that there is a Golang lib that could have
helped you a bit... but you asked here for a Python reference and not
Go ;)

https://github.com/spdx/tools-go

-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [spdx-tech] Hello, Seeking Clarrification of 2.1 Package Verification Code

[Philippe Ombredanne]

Ben,

On Wed, Feb 7, 2018 at 6:29 AM, Ben Boyter <b...@boyter.org> wrote:
> Hi All,
>
> First time using the lists for me, but I have been somewhat involved with
> SPDX for a while now. I am in the middle of implementing at SPDX 2.1
> automated parser and am seeing come clarification of the Package
> Verification Code logic
>
> https://spdx.org/spdx-specification-21-web-version#h.2p2csry
>
> The algorithm as listed seems incomplete. I was wondering if there was an
> example implementation in something like Python or otherwise that can be
> used as a reference? If not can there be a better spec of is listed and I
> will be happy to build an implementation to work with.
>
> Hoping someone has one lying around.

Hey Ben!
Good to see around!

If you want my take, these codes are a major PITA. Especially in the
case where you want to provide data about a package and do not care
much about having ultra precision and self-verifiable content and
instead want something that is good enough and uses the SPDX format.
With that said they are computed alright in the Python library [1] in
this function [2]


[1] https://github.com/spdx/tools-python
[2] 
https://github.com/spdx/tools-python/blob/a48022e65a8897d0e4f2e93d8e53695d2c13ea23/spdx/package.py#L233

-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [spdx-tech] standardLicenseHeader for EPL-1.0

[Philippe Ombredanne]

Hi Thanh,

On Thu, Dec 28, 2017 at 2:18 AM, Thanh Ha <thanh...@linuxfoundation.org> wrote:
> I am developing a license header scanner in order to quickly scan local
> files for license headers at the top of code files.

You may want to check out ScanCode [1]. Since I use it with top Linux
maintainers to clarify the kernel licensing and set SPDX ids, it must
not be too shabby as a license detection engine.  It detects headers
alright and much more, including EPL headers.

PS: ScanCode is written in Python, not Go and I am the maintainer.

[1] https://github.com/nexB/scancode-toolkit
-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [spdx-tech] [PATCH] USB: add SPDX identifiers to all files in drivers/usb/

[Philippe Ombredanne]

On Fri, Oct 20, 2017 at 9:20 AM, Fendt, Oliver <oliver.fe...@siemens.com> wrote:
> great to see this direction of development.
> This will are least clarify all the files which carry nothing expect the Marko
> MODUL_LICENSE("GPL");
> Because one of the interesting questions is "is this a legally binding 
> expression
> of licensing?"

The MODULE_LICENSE macro used in the kernel is a clear license statement.
And better than a terse "Copyright (c) John Doe, GPL" that is seen in
the kernel
since there is a clear documentation of its meaning in the kernel's
module.h [0] :

 * The following license idents are currently accepted as indicating free
 * software modules
 *
 * "GPL" [GNU Public License v2 or later]
 * "GPL v2" [GNU Public License v2]
 * "GPL and additional rights" [GNU Public License v2 rights and more]
 * "Dual BSD/GPL" [GNU Public License v2
 * or BSD license choice]
 * "Dual MIT/GPL" [GNU Public License v2
 * or MIT license choice]
 * "Dual MPL/GPL" [GNU Public License v2
 * or Mozilla license choice]
 *
 * The following other idents are available
 *
 * "Proprietary" [Non free products]
[...]

So MODULE_LICENSE("GPL") means clearly "GNU Public License v2 or later"
and nothing else. I cannot comment on whether such a license statement would
be legally binding or not, but at least there is no ambiguity about
what this means.
And IMHO this is as good as an SPDX license identifier and as good as it gets
short of any other licensing indications.

Since the MODULE_LICENSE is only for kernel modules, there was a need
for something that could be applied elsewhere, hence the use of SPDX
identifiers. Note that there were talks to use a macro instead of a comment.
It may come back in the future as it would have the added benefit to inject
license ids in the built binaries (the same way a MODULE_LICENSE ends
up in a built LKM)

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h?id=refs/tags/v4.10#n172

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

[spdx-tech] Fwd: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/

[Philippe Ombredanne]

FYI:
In case you missed it: SPDX identifiers have landed in kernel land...
Read the whole thread at https://patchwork.kernel.org/patch/10016189/
And as a side effect, some new patches elsewhere are coming in with
SPDX identifiers right in!
-- 
Cordially
Philippe Ombredanne

-- Forwarded message --
From: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Date: Thu, Oct 19, 2017 at 10:38 AM
Subject: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/
To: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org, Thomas Gleixner
<t...@linutronix.de>, Kate Stewart <kstew...@linuxfoundation.org>,
Philippe Ombredanne <pombreda...@nexb.com>

It's good to have SPDX identifiers in all files to make it easier to
audit the kernel tree for correct licenses.  This patch adds these
identifiers to all files in drivers/usb/ based on a script and data from
Thomas Gleixner, Philippe Ombredanne, and Kate Stewart.

Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Kate Stewart <kstew...@linuxfoundation.org>
Cc: Philippe Ombredanne <pombreda...@nexb.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
Unless someone really complains, I'm going to add this to my tree for
4.15-rc1.


diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 9650b351c26c..cb8d902b801d 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -1,6 +1,7 @@
 #
 # Makefile for the kernel USB device drivers.
 #
+# SPDX-License-Identifier: GPL-2.0

 # Object files in subdirectories

[] long diff of 600 files removed for brevity...
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [spdx-tech] Online Validation Tools GSOC 2017

[Philippe Ombredanne]

On Thu, Mar 16, 2017 at 10:24 PM, Rohit Lodha <rohit.lodha...@gmail.com> wrote:
> Hi I am Rohit.
> As I mentioned in my last email, I would like to contribute to SPDX by
> working on the Online Validation Tool during the summer.
> I have already submitted some patches to tools-python repository.

Thank you for this. Can you check the comments I made there?
There are quite a few adjustments that are needed if you want to prove
me that you can handle the basics of git and Python.

> I would like you to help me write my project proposal by suggesting more
> features that can be implemented in the system.
> After going through the spdx specification, I suggest we build a Web Server
> using Django,Python with the following features :
>
> A portal where user can upload,parse and validate SPDX documents.
> Using a Python-Java bridge ( probably JPype and Py4j ) for integrating Java
> library which is up to date with the current version of spdx.
> We can use some features/codes from the tools-python repo. for some
> implementation.
> The portal will also provide the feature for Online License Expression
> Validator
> Online License Search
> Online License Comparator
>
> This is just a basic blueprint of the system. I would like you to suggest
> some more features which I may have missed.

This is a good start. At this stage this is not about piling more features.

Instead what I would like to see in a proposal is:
- the details of which data structures and models you plan to create.
And why?
- a description of the processing flow(s): which would be the key parts
and how the data would flow between these?
- how do you see users using the tool(s)?
- what would they gain from it?
- which UI/UX do you have in mind?
- what is your plan to package and make these installable?

And this for each feature and/or tool you are considering.
And I am not interested in boilerplate parts, but what is
specific to your apps.

As a side note, please try to avoid posting HTML or Rich text on this list.
Plain text is better.

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [spdx-tech] Online Validation Tools GSOC 2017

[Philippe Ombredanne]

On Fri, Mar 3, 2017 at 7:08 AM, Rohit Lodha <rohit.lodha...@gmail.com> wrote:
> As suggested by Gary, I had a look on both python-tools and how to use Java 
> api/application from python/django. It turns out it's not so hard. We can use 
> any of the packages available like JPy, Py4J, JPype, javabridge, Jython and 
> JCC. After reading their documentations, I would suggest we use JPype and 
> Py4j.
>
> Apart from that, I have forked and compiled both the java tools and 
> python-tools on my localhost. I have got the hang of python tools and tested 
> it out extensively. I am not able to run java tools untill now but will look 
> into its problems soon.
>
> I also had a look at specification from spdx.org, I didn't read it thoroughly 
> but I understood some of the main purposes and their meta data.
>
> After going through all this, I would suggest we build a Django server for 
> uploading, parsing and validating SPDX since Django not only provides 
> security but also provides a great platform with easily integrable modules to 
> efficiently work with. We can use already build Java library with some good 
> python-java bridge(as suggested above) and add document format conversion 
> with python
> as it provides almost all conversion support.
> We could also use code from python-tools for some implementations.

This makes perfect sense to me and I would be willing to mentor this
with a well crafted proposal. You are on the right track.

Note that this should also expose an API in addition to the web UI.
But do you think this would be enough work for a three month full time project?

If not you could also add in the mix a few other features such as any of these:
- an online license expression validator
- an online license search and comparator (such that it is easy
 for anyone to search and compare existing licenses with another license
 or another text... this would be useful for the legal team in particular.


> I will also start working on the issues and pull requests on both 
> python-tools and java tools once my exams get over.

Thanks! The goal there is that we can ensure that you can show minimal skills
for doing PR and handling tickets. and that we can see if you have basic code
writing skills.

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [spdx-tech] Retrieving standard license headers

[Philippe Ombredanne]

On Fri, Mar 3, 2017 at 10:58 AM, Didier Verna <did...@didierverna.net> wrote:
>   Hello,
> I'm the author of an automatic documentation system for libraries
> written in the Common Lisp programming language.

Welcome!
https://github.com/didierverna/declt looks neat!

> Lisp has a couple of
> de-facto standard tools for describing and managing packages, and I'm
> trying to push those to using SPDX format where relevant.

This is great. Thank you for trying to make the world a better place wrt
license clarity. Be assured that will help in any way we can!

> I see that SPDX makes license texts accessible on github, but what about
> standard license headers ? I couldn't find those anywhere, although I know
> you've got them somewhere (they are provided in the HTML pages).
>
> It would be convenient for me to have programmatic access to the
> standard license headers, because then, given an SPDX license
> identifier, I could then retrieve those and incorporate them directly in
> the generated documentation files.

A couple things:

You could use the structured data available (such as JSON) available
 in https://github.com/spdx/license-list-data/tree/master/json

When available the standard header would be in the
standardLicenseHeader attribute for a license.

See this for example:

https://gist.github.com/pombredanne/50b04d5d4f37070cca9921bc5cbb9018#file-gpl-1-0-json-L9

You will find that these "standardLicenseHeader" texts when present have
a few issues, but nothing too bad:

 - they contain a copyright template of sorts which is entirely not
needed and make these useless for re-using in any clean documentation
or attribution notice.

You could remove these types of string:
"<<var;name=copyright;original=19xx name of author;match=.+>>"
or use that somehow and replace it with a copyright but the results are
likely to be rather ugly in many case. They also assume that you
have captured a clean and structured copyright statement beforehand.

- headers may not be available at all. Since the "+" "or later" ids have
been deprecated, there is no way that I know of where to get a clean
"GPL 2.0 or later notice" for instance. Some license may  not be up
to date too, but this is minor and easy to fix over time.

- in several cases, using a standard template may be grossly incorrect
and the actual exact notice that was in the original package should be
what is reused if you want crisp and clear documentation and
compliance. For this you would need to actually capture these real notices
and copyright from the code proper.

You could try my scancode-toolkit for this with the --license-text option
though that part while stable and decent is not 100% there to
reassemble a *perfect* notice capture. We are working on it though.
In any case you would get from this a JSON with copyrights and licenses
texts and notices alright.
I confess that scancode-toolkit was mistakenly written in Python and
not Lisp as it should have. We are working slowly to implement a
messy, incomplete subset of an imperfect Lisp engine as all serious
software projects tend to do eventually.

> Lisp, Jazz, Aïkido: http://www.didierverna.info

A definitely eclectic mix!
And I like the order of your priorities: Think, sing, dance.

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [spdx-tech] [GSOC'17] Getting Started

[Philippe Ombredanne]

On Thu, Mar 2, 2017 at 8:30 PM, VAIBHAV GUPTA
<guptavaibhav18...@gmail.com> wrote:
> Hello SPDX Community,
> I am Vaibhav Gupta, student at IIIT, Hyderabad, India. I am interested in
> 'Online Validation Tools' project for GSOC'17. As I am new to open source, I
> will be needing some guidance to initiate the work. Please help me getting
> started.

Welcome Vaibhav and thank you for considering SPDX for the GSOC 2017!

Here is a gist of what this validation tool could be:

1. input would be either one of a full SPDX document as tag/values or
RDF or a simple license expression
2. the output would be a list of SPDX errors, warnings, info and
recommendation and where they occurred exactly in the document or
license expression in a visually easy way to support review.

Tech-wise, I think we are open: I would personally favor using the
Python libraries.
UX-wise this should be available as a web UI and a REST API.

I hope this helps.

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: spdx-tech Online Validation Tools GSOC 2017

[Philippe Ombredanne]

On Thu, Mar 2, 2017 at 10:49 AM, Schuberth, Sebastian
<sebastian.schube...@here.com> wrote:
>>> So, instead of the hash processing a file with this text
>>>
>>>   $Id: foo.c 123456 2015-01-31 12:34:56 mdb $
>>>
>>> as is found in a file, it would instead process the above text as if
>>> it were written $Id$
>>>
>>> This would allow two files that are identical other than RCS Keyword
>>> values to have the same 'hash' for an SPDX report.
>>
>>Mark:
>>this is eventually a problem with no simple answer. Luckily this is going 
>>away eventually in the future as as far as I know git does not support 
>>>keyword expansions (IMHO for the better).
>
> While Git does not support keyword expansion directly, it can be achieved 
> using the more general clean / smudge filter approach.

Great! this makes it hard then and I like it this way!


>>That said, there are various ways I have handled this practically:
> Note that the standard currently requires plain "SHA1" to be present. 
> Omitting that in favor of any other / custom hash would render your file 
> non-spec-compliant :-(


Agreed. But this is a part of the spec that should be flexible IMHO.
Especially with a shattered SHA1 [3]
And IMHO such LSH checksum should be readily addable to an SPDX document.


>>3. You use a non-crypto, "locality sensitive" checksum hash that you use for 
>>approximate file comparison.
> That option is very useful in general to have an indication about similarity 
> of files.
> 4. option, you simply use the hash of how the file is stored internally to 
> the VCS. In a way that is similar to Philippe's option 2 as it refers to the 
> file before keyword expansion. But instead of actually checking out the file 
> without doing keyword expansion, you simply query the VCS for its internal 
> hash of the file. At the example of Git and the AUTHORS.rst file of ScanCode 
> [1] that would work like:
>
> $ ARRAY=( $(git ls-tree HEAD AUTHORS.rst) ) ; echo ${ARRAY[2]}
> d89c7ba9918d7fe249875ac44b8c61cb11cac4ac
>
> So, this way you not only get the hash before keyword expansion is done, you 
> also get the hash for free since it's already known by the VCS.
>
> The downside is that this internal hash is specific to the VCS, so it only 
> helps to identify the same file in other repos of the same VCS. But for other 
> VCS you could go with Philippe's option 2 and calculate the file hash like 
> Git does internally [2].


This is an interesting and intriguing approach :)
As far as I know this is also more or less the approach taken by
Stefano "zack" Zacchiroli and team for software heritage... [4] [5]
But this is practical only for Git and Hg OR if you import in Git or Hg, right?


> [1] 
> https://github.com/nexB/scancode-toolkit/blob/bd424eae1dcdbb3f873169bbc01d252e4e20e4f4/AUTHORS.rst
> [2] https://github.com/sschuberth/dev-scripts/blob/master/git/git-hash-blob.sh


[3] https://shattered.it/
[4] https://www.softwareheritage.org/
[5] 
https://fosdem.org/2017/schedule/event/software_heritage/attachments/slides/1537/export/events/attachments/software_heritage/slides/1537/fosdem17_software_heritage.pdf

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: spdx-tech Online Validation Tools GSOC 2017

[Philippe Ombredanne]

On Thu, Mar 2, 2017 at 6:31 AM, Mark D. Baushke <m...@juniper.net> wrote:
> Hi Folks,
>
> A question for SPDX-Tech folks concerning file equivalences.
>
> If I have a file with a RCS Keywords such as is available in RCS, CVS,
> SVN, git (svn:keywords) or changeset ID (Mercurial), is it desirable to
> be able to define a different FileChecksum attribute that explicitly
> canonicalizes these values so that equivalent implementations will show
> as being the same, even if they had been checked into another SCM system
> and had the hash overwritten locally?
>
> So, instead of the hash processing a file with this text
>
>   $Id: foo.c 123456 2015-01-31 12:34:56 mdb $
>
> as is found in a file, it would instead process the above text as if it
> were written $Id$
>
> This would allow two files that are identical other than RCS Keyword
> vaues to have the same 'hash' for an SPDX report.
>
> So if the only diference between two files was
>
> 2c2
> <  * $Id: foo.c 123456 2015-01-31 12:34:56 mdb $
> ---
>>  * $Id: foo.c 1.22 2010-02-20 11:56:00 jon $
>
> the 'RCSkeywordlessFileChecksum: SHA1: '
> would be identical for the two files (or whatever attribute id you want
> to use).
>
> (Note: Where I see this differnce most often is in different branches of
> the same software.)

Mark:
this is eventually a problem with no simple answer. Luckily this is
going away eventually in the future as as far as I know git does not
support keyword expansions (IMHO for the better).

That said, there are various ways I have handled this practically:

1. you preprocess the source code and remove any keyword. I was not
really happy with this and this led to this (ugly) python snippet:
---

# see 
http://cvs-nserver.sourceforge.net/doc/unstable/manual/html_chapter/cvs_12.html#SEC101
# for a list of the keyword and for the substitution rules
vcs_replacement_regex =
re.compile('\$(Author|Date|Header|Id|Name|Locker|Log|RCSfile|Revision|Source|State)(?:\:[^\$\n]*)?\$',
re.MULTILINE | re.UNICODE | re.DOTALL)

Once you have preprocessed your code with this you could use any
checksum alright as you suggested above.
I would never warrant a new SPDX tag IMHO, but rather you can name the
checksum algo with something new, such as

FileChecksum: SHA1NOCVS:21ada346713283327

or anything that would be not too ugly and then you can document for
your SPDX doc recipients.


2. You do not expand keyword at all, if you control the checkout. This
may not be always practical.
---

3. You use a non-crypto, "locality sensitive" checksum hash that you
use for approximate file comparison.
---

You can then name this and use this instead of or in addition to a SHA1.
For instance you could use "ssdeep" or tlsh. Say you use tlsh and name
this as "TLSH" for an algo identifier:
You could then use this SPDX Tag/value snippet:

FileChecksum: TSLH:21ada346713283327


To illustrate this consider these two files where the only difference is
>
> 2c2
> <  * $Id: foo.c 123456 2015-01-31 12:34:56 mdb $
> ---
>>  * $Id: foo.c 1.22 2010-02-20 11:56:00 jon $
>


I have attached these to this gist:
https://gist.github.com/pombredanne/4f767acb1ab480ad3b93287f6cdb1de9

If I compute a tlsh for these using the head of
https://github.com/trendmicro/tlsh, I can see right away that
the checksums are very similar, like the files are

$ bin/tlsh -r foo
0051625E224447B306E647A6691BA8CCA00DD01D3767AE05240FB16C4E2B27EC6FFC94
foo/foo1.c
7251725E224457B306E647A66A1FA8CC600DD01D37A7AE04240FB16C4E2B37EC6FFC94
foo/foo2.c

They are still not exactly the same but you see how the LSH approach
differs from a crypto checksum.

And the tlsh "distance" between the two files is very small (e.g. 9)
which is the property you want to
exploit to determine that two files are essentially the same except
for very minor changes:

$ bin/tlsh -f foo/foo1.c -c foo/foo2.c
   9 foo/foo1.c



As a side note, I have built several alternative lsh fingerprints and
I will push them as FOSS in
a https://github.com/nexB/ repo sometimes.


I hope this helps!
-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

[ANNOUNCE] SPDX has been accepted as a mentoring organization for the Google Summer of Code 2017

[Philippe Ombredanne]

A good news came in yesterday: SPDX has been accepted as a mentoring
organization for the Google Summer of Code 2017 thanks to Gary's hard
work. I look forward to contribute as an admin and mentor!

See https://summerofcode.withgoogle.com/organizations/6438746388955136/

Practically we should expect to have a couple or a few students
allocated to work and contribute to SPDX tools and technologies and
this is a great validation and recognition of the project and the
community efforts.

The next important date for the GSOC is March 20, 2017 when students
can start applying and submit their project proposals.

You can see all the accepted orgs here:
https://summerofcode.withgoogle.com/organizations/
The Linux foundation open printing project is also an accepted organization.

As a side note, http://aboutcode.org which is nexB's FOSS master
project has also been accepted as a mentoring organization and we have
several SPDX-related projects ideas there too:
https://github.com/nexB/aboutcode/wiki/GSOC-2017

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Getting started...

[Philippe Ombredanne]

On Sat, Feb 18, 2017 at 5:58 PM, Paul Sherwood
<paul.sherw...@codethink.co.uk> wrote:
> On 2017-02-18 04:54, Gisi, Mark wrote:
>>>> At Kate's talk [1] (can't find the slides online, btw) she showed a Wind
>>>> River dashboard
>>>> which mentioned that the WR scanner (proprietary?) identified keyring as
>>>> having no license info.
>>
>>
>> Wind River has provided a free SPDX creation service for more than
>> three years including the dashboard view:
>>  http://spdx.windriver.com/pkg_upload.aspx
>>
>> We did this to allow one to obtain instance access to the SPDX
>> creation process to promote the adoption of SPDX.  All you need is a
>> software package and an email address (actually you only need an email
>> since we provide sample packages as well). We make it so easy that
>> even your grandmother can create an SPDX file - provide she has an
>> email account (at least that was a core design principle  that guided
>> us).
>
>
> Given that the service you're mentioning is proprietary, I'm not sure
> whether the algorithm is the same as what led to Kate's slide or not. But in
> any case the keyring upstream maintainer points out that his licensing is
> detected at https://pypi.org/project/keyring/ and it seems that the service
> Kate used did not detect it.

Paul, Kate:
keyring is actually using the standard Pypi metadata to document its license
in its setup.py file [1] and this contains proper identification.

Note that per keyring metadata the correct license is "MIT and Python-2.0"
and not just MIT.

Mark' scanner may be constrained by its underlying license detection engine
and not catch this alright. I would guess this engine to be fossology.
Mark: is this a correct guess?

Now, the latest ScanCode toolkit [2] detects keyring's two licenses correctly.

ScanCode [2] is open source software and now has emerging support for
SPDX contributed by Sebastian Schuberth.

See also several related comments in this issue Paul entered on keyring [3]

[1] https://pypi.python.org/pypi?:action=list_classifiers
[2] https://github.com/nexB/scancode-toolkit/
[3] https://github.com/jaraco/keyring/issues/263#issuecomment-281035598

-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode : What's in your code?! at http://www.dejacode.com
nexB Inc. at http://www.nexb.com
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Weekly Tech Call Schedule

[Philippe Ombredanne]

On Wed, Dec 14, 2016 at 10:01 PM, <g...@sourceauditor.com> wrote:
> We would also like to take a poll from the mailing list if we should move the 
> time earlier to allow for more participation in Europe.
>
> Please let us know if you feel we should start the call 2 hours earlier
> (8AM Pacific, 4PM GMT) or would prefer to keep the call at its current time
> (10AM Pacific, 6PM GMT).

+1 for moving it earlier with the added benefit that folks in Asia
could join too (though it would still be quite late and in the range
of 11:00PM to 1:00AM in some locales)

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Using github and not http://git.spdx.org as primary for SPDX python tools

[Philippe Ombredanne]

On Fri, Dec 2, 2016 at 6:17 PM,  <g...@sourceauditor.com> wrote:
> Hi Philippe,
>
> There are a few things we need to do to make the complete transition.  There
> are some repos which are on git.spdx.org that need to be moved to github.
> There are also some users who have commit access to git.spdx.org that do not
> have commit access on github.

The simplest is to ask their Github username on this list or a private
email and then send an invite.
If they do not reply then this might not be a big issue for them?

> I am also thinking we may want create some kind of README or pointer to
> github for those still looking at git.spdx.org.  Any ideas on what to do
> here would be appreciated.

This is easy: once the mirroring is removed, I can just push a commit
that explains that the repo has moved to Github in a file called
MOVED_TO_GITHUB_SPDX.txt and in that same commit delete all files (the
history would still have them for the posterity)  or just update the
README and leave everything else as-is.

> For Python, we have the original GSoC student Ahmed with commit access - do
> you think we need to reach out to him to get him access to the new repo
> (I'll need to dig up his email address)?

Ahmed has been quiet for a while so I would not bother.
If he shows up we can grant him access or his github user is ah450 so
you could send an invite too.
But since he not active it might be best to just do nothing until he wakes up.

> Kate and Philippe -
>
> We can probably move things incrementally - python and SPDX tools first
> since they are already setup with all committers on github with the possible
> exception of Ahmed.  Any reason to wait on these to repos?  Philippe or I
> should be able to disable the mirroring.  I would then remove all commit
> access on SPDX.org to prevent any accidental commits.

This works for me alright.

You should go head with the the Go tools too and grant me access on
Github as I mentored the initial contribution. There will be some
minor issues with Go import namespacing but they will be easy enough
to fix.

-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode : What's in your code?! at http://www.dejacode.com
nexB Inc. at http://www.nexb.com
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Using github and not http://git.spdx.org as primary for SPDX python tools

[Philippe Ombredanne]

I want to use Github as the primary repo for the Python tools and NOT
the current repo at git.spdx.org.

Why?
Contributors have been complaining and are not happy with current
setup as they should.

Today the repo https://github.com/spdx/tools-python/ is a mirror of
http://git.spdx.org/?p=spdx-tools-python.git
This means that all commit must be done pushed to git.spdx.org and
eventually they will be replicated to github.
Eventually is a big word. It takes forever (it took about three days
on a recent commit)
This lack of sync just makes a sane workflow impossible in particular
to review pull requests and foster collaboration.

Even if the sync was to take less than a minute, this mirroring is
just an impediment and inefficient when all the work is taking place
on Gihub including issues and PRs.

The mirroring (if needed) should be done the other way:
http://git.spdx.org should be synced from the github repo for
reference.

This should be rather simple IMHO: just remove any mirroring hooks or
settings from repo @ spdx
(and if needed setup a cron job to pull from github instead.)

Who can make this happen? Kate? Gary?
I would rather have this ASAP.

-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode : What's in your code?! at http://www.dejacode.com
nexB Inc. at http://www.nexb.com
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: implementing SPDX License List

[Philippe Ombredanne]

On Wed, Jun 22, 2016 at 12:20 AM, J Lovejoy <opensou...@jilayne.com> wrote:
> Hi SPDX tech and legal team folks,
>
> We are wanting to implement the ability to choose a license/create an SPDX 
> license expression in an internal tracking tool. I was wondering if anyone 
> had done that already or knew of anyone who had or any other such info.  It 
> seems like it might be something someone has already done, so I was hoping to 
> see if that was the case, maybe I could get some info as to how they 
> implemented it, programming tips, etc.

Jilayne:
We have a license expression builder in DejaCode, but this not open source.
There are two parts to it: a front end in JavaScript and a back end
that validates expressions and provides the licenses lists.
The front end is implemented with Awesomeplete.
The back end is dependent on the DejaCode models of course, but the
validation of expression is something that will be released soon as
open source in ScanCode.
It is a parser that can interpret the logic of expressions and can
normalize and convert expressions to their canonical forms, can
minimize or reduce expressions and compare eventually very different
but equivalent expressions for equality or containment.
-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode : What's in your code?! at http://www.dejacode.com
nexB Inc. at http://www.nexb.com
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Proposal: Add "(IF THEN [ELSE ])" to License expressions

[Philippe Ombredanne]

On Wed, May 11, 2016 at 11:56 PM, Wheeler, David A <dwhee...@ida.org> wrote:
> In the Linux Foundation CII “best practices” badge effort I’m noticing an
> interesting problem.  Some projects have *different* license situations for
> their source code and documentation, but there’s no simple way to express
> that using SPDX License expressions.

Furthermore, there is common pattern to have CLI tools under the GPL,
a library under the LGPL (and somtimes examples in the public domain
or BSD-licensed. )

> Examples of projects where the license
> isn’t easily expressed with SPDX expressions are:
>
> https://bestpractices.coreinfrastructure.org/projects/1
>
> https://bestpractices.coreinfrastructure.org/projects/137
>
>
>
> I propose adding a new construct:
>
> "(IF  THEN  [ELSE ])" to
> License expressions.
>
> For starters,  can be:
>
> DOCUMENTATION = True if & only if (iff) documentation
>
> SOURCE = True if & only if (iff) source code
>
>
>
> So “Source code under MIT, everything else under CC-BY-3.0 or later” becomes
> this license expression:
>
> "(IF SOURCE THEN MIT ELSE CC-BY-3.0+)".
>
>
>
> If there’s no “else” and the condition is false, it’d be interpreted as the
> empty set of rights (“no rights”), so these would mean the same thing:
>
> "MIT OR (IF DOCUMENTATION THEN CC-BY-3.0+)"
>
> "(IF DOCUMENTATION THEN (MIT OR CC-BY-3.0+) ELSE MIT)"
>
> I imagine Condition could be beefed up to allow AND/OR/NOT, file matching,
> jurisdiction matching, and comparisons with the current date (for timed
> releases in the future).  But that’s for a later discussion.

Could this be simplified?

I can see two use cases:
1. at the file or directory level, this is unlikely needed: just
provide the expression that applies there only e.g. to a doc or source
directory in an SPDX doc or a simple expression.

2. for a top level package, would a notion of "licensing scope" be
simpler than a full conditional construct?
e.g. something like:

scope:doc GFDL and MIT
scope:tools GPL-2.0+
scope:library LGPL-2.1+

And if no scope is defined it defaults to global and is overridden if
a scope is defined?
So IMHO this would not be a single expression but an array of expressions.
And we might not need a full if then else to express this.
-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Using markdown for the SPDX Specs

[Philippe Ombredanne]

On Tue, Dec 15, 2015 at 9:27 PM, Manbeck, Jack <j-manbe...@ti.com> wrote:
> Kate,
> We have been kicking around how to do a web version of the specification.
> Using markdown may be the answer. We could convert that to HTML or even PDF,
> etc. for the website.  I’ve copied the list as well as others may have some
> thoughts. We’ve been using it internally here at TI to generate documents
> and like it but maybe nothing as large as the spec itself. That might take a
> bit of discipline on our part. The link below is an overview of markdown
> see what you think.
>
> https://daringfireball.net/projects/markdown/

Big +1 for markdown or reStructuredText.  reStructuredText may be more
adapted to complex spec documents. In any case one or the other would
much better than the current approach. And pandoc and a legion of
tools can easily convert to any format.


[1] https://en.wikipedia.org/wiki/ReStructuredText
-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Machine-readable form of license list?

[Philippe Ombredanne]

On Nov 20, 2015 Eric S. Raymond <e...@snark.thyrsus.com> wrote:
> I'm thinking about writing a codewalker that would scan a source tree
> for license inclusions and replace them with SPDX tags.
>
> The hard part of this wouldn't be the code, it would be scraping
> copies of all the canonical license texts and SPDX names.
>
> For this, and other related reasons, I request that you make the
> license list available in a machine-parseable form. What I'd like to
> be able to do is write a code generator that massages that form into
> Python structures that then drive the source transformation.

Eric:
I maintain such a list in scancode [1] for SPDX and many other licenses.
The format is one yaml file for each licenses metadata and a .LICENSE
file for the license text and a .SPDX file for the SPDX reference
license text.
There were request to have that in a separate repo,if that can help I
can pull it out.
There is also Python code to read it [2]

[1] 
https://github.com/nexB/scancode-toolkit/tree/develop/src/licensedcode/data/licenses
[2] 
https://github.com/nexB/scancode-toolkit/blob/c1e70994abe8ceb18bc99aa6f81ebc40d832fb7f/src/licensedcode/models.py#L62
-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Prototype spdxify codewalker

[Philippe Ombredanne]

On Sat, Nov 21, 2015 at 11:11 PM, Eric S. Raymond <e...@thyrsus.com> wrote:
> I've enclosed a copy of a proof-of-concept program in Python that walks a
> code tree replacing inline license headers with SPDX tags.  It can be
> tested as a filter - feed a source file to its stdin, get back the
> SPDXified version on stdout.

Erirc:
I think the code is  not enclosed

> Can we cooperate on making this a production-quality tool?

I am game. FWIW, I maintain the scancode-toolkit that does scan and
detects licenses in code and that could be useful.
And it is also coded in Python ;)

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Is "+" a valid character of a LicenseRef idstring?

[Philippe Ombredanne]

On Tue, Nov 3, 2015 at 3:45 AM, Wheeler, David A <dwhee...@ida.org> wrote:
> Philippe Ombredanne wrote:
[...]
>> You say:
>> GPL-2.0 ==> implies  GPL 2.0 only
>> GPL-2.0+ ==> implies  GPL 2.0 or later
> That's not just what I say.  That's what the spec says, and has
> clearly stated since circa 2010.
> This would have been a useful argument to raise in 2010 (when SPDX was
> drafted).  But this group doesn't exist to create a new spec where
> none has existed. For more than 5 years SPDX has consistently stated
> that "GPL-2.0" means ONLY GPL-2.0 and nothing else.  This builds on
> previous history of Fedora and Debian, who also use "+" this way,
> e.g., see: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing

David:
I know this as I was part of it and that does not make it more right ...
FWIW, I have been around SPDX for quite a while ;).
See "A Short History of SPDX":  https://spdx.org/about-spdx/what-is-spdx

> While I know you're focusing on the GPL, there are many other
> licenses, and most licenses do NOT have a "this or later version"
> clause;

The focus is not only on the GPL:
well over 25% of the SPDX licenses DO HAVE a "this or later version"
clause. Here are some examples:

- Most of the FSF licenses: The GPL and LGPL and all their versions.
  But also the AGPL, the GFDL, etc.
- all the Mozilla-like license: NPLs, MPLs and all the MPL derivatives
  such as SPL, CPAL, Erlang, RPL, APSL, Gsoap, ZIMBRA, SISL, etc.
- most of the Creative Common licenses,
- The Eclipse licenses and the CPLs,
- the CDDLs,
- the PHP license,
- OpenLDAP, Latex/LPPL, LPL, Condor, CATOSL, RPSL, CECILL, etc.

For all SPDX licenses allowing other versions, the bare identifier means
"or later version", except for the L/GPL where this means "only the
current version" unless you create an expression with a "+".

So the decision procedure to use a plus or not is roughly like this:

If licensing allows to use "other license versions":
 - If and only if GPL or LGPL, add a + to the license identifier.
   "other license versions" is NOT implied.

 - Otherwise, if this not GPL or LGPL, do NOT add a +.
   "other license versions" is implied if the license allows such thing.
   Do this ONLY for any versions of these two licenses. Do not apply
   this approach to other FSF licenses such AGPL, GFDL and others.

 - Except if you are a Linux packager for Debian or Fedora and their
   derivatives, because then you may use the + for other FSF
   licenses beyond the L/GPL. The + is already used with GFDL,
   AGPL, etc. Do not use a plus for non-FSF licenses that
   have an "or later" clause.

If licensing does NOT allow to use "other license versions":
 - If and only if LGPL or LGPL, use the bare license identifier.
   "no other license version" is implied by a bare id.

 - Except if you are a Linux packager because you apply
   the same approach for other FSF licenses.

 - If this is another license, then?
   "other license version" IS implied in a bare id here.
   SPDX does not help you there, and you could create an
   exception.This is a rare case anyway.

> having the default be what's common in MOST licenses is
> actually sensible.

This is exactly my point. The common sense and default usage for L/GPL
is ". And Linux distros and SPDX have made the default "or later"
exceptional and the less common "only" exception the default.

So how to resolve this situation?

In the grand scheme of things, "only" and "or later" are minute
technicalities that the large majority of software users do not care
for. The licenses requirements are essentially the same and
"later or not later" is not the question.
Only a few licensing mavens care about this and they know how to deal
with it.

But SPDX is likely stuck with this inconsistent legacy and yes this is
hard to escape without creating more mess. It does not mean that we
cannot try to clarify and improve things.

First we need to distinguish two types of licenses allowing
"other versions":

a. FSF licenses such as the A/L/GPL. These are the only licenses were a
plus + convention has been used by Linux distros and SPDX with some
consistency.

b. Non-FSF licenses. I cannot find cases where the plus + convention
has been used in the wild or with SPDX for these.


Some ways out could include:

Option 1. Do mostly nothing.
-
Keep the status quo and clarify the current ambiguities:
We document the procedure I described above and move on.
We accept this is a mess and make it a documented mess.
This is an OK option. And requires little or no work.


Option 2. Change the meaning of every bare license id that allow
"or later" to mean "this version only". FSF or not FSF.

No change of

Re: Is "+" a valid character of a LicenseRef idstring?

[Philippe Ombredanne]

>> On Wed, Oct 28, 2015 at 10:28 AM, Schuberth, Sebastian wrote:
>>> when debugging an issue in the spdx-tools verifier, I noticed the
>>> SPDX 2.0 specs seem to be inconsistent on whether "+" is a
>>> valid character in a LicenseRef's idstring, like in LicenseRef-[idstring].

> I wrote:
>> I not see any reason why a + would not be allowed in a reference, and
>> there is no ambiguity since the + always something attached to an id or
>> ref string, not some free standing symbol.

On Mon, Nov 2, 2015 at 7:02 PM, Gary O'Neall <g...@sourceauditor.com> wrote:
> In the 2.0 spec, the + is a unary operator with a specific meaning
> (see Appendix IV of the 2.0 spec "Simple License Expressions" subsection
> page 82).  If we are to use it as an operator with License Ref's, it would
> be difficult for a parser to determine when it is part of a reference string
> and when it is intended as an operator.

This + is a suffix and not a freestanding character, right?
So "GPL-2.0+" is valid but "GPL-2.0+" would not be valid?
In this case there would be no issue to have a plus as part of a licenseref:
there is no possible ambiguity.

Then again we would be better off to get rid of the plus entirely!

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Is "+" a valid character of a LicenseRef idstring?

[Philippe Ombredanne]

On Mon, Nov 2, 2015 at 9:12 PM, Wheeler, David A <dwhee...@ida.org> wrote:
> Philippe Ombredanne:
>> This + is a suffix and not a freestanding character, right?
>> Then again we would be better off to get rid of the plus entirely!

> You may be confusing a SPDX "license identifier" and a SPDX "license
> expression".  It's a subtle point.

I am not confusing these at all. The gist of what I am saying is that
the plus is a legacy that should not be there. It does not make sense to
add to the large majority of GPL in the wild a + just to deal with a few
exceptions that do not allow other versions. Exceptions should be dealt
with an exception not with an extra + in an expression.

> The purpose of a "license identifier" is to identify a specific text
> of a specific license text, using a short name. In SPDX 2.0 there is
> no "+" in a standard license identifier.  In particular, "GPL-2.0" is
> a license identifier, and "GPL-2.0+" is *NOT*.  If all you want to do
> is identify a particular license text, use a license identifier. No
> "+"exists at the end of a license identifier.
>
> However, a "license identifier" is often inadequate for describing
> the licensing requirements imposed on users and later developers.
> Many packages have different subcomponents with different licenses.
> Many packages include the text of some license (such as the GPL
> version 2.0), but there are often two possible cases:
> - You must use this particular version of the license.
> - You may use this or any later version of the license.
> Thus, SPDX 2.0 defines a "license expression" for describing how
> license texts apply to software packages,.  A license expression is
> built out of license identifiers but adds ways to describe how the
> license texts are used. A "+" appended after the name of a license
> identifier means "or any later version may also be used".  E.G., the
> license expressions "(GPL-2.0+ WITH Classpath-Exception-2.0)" and
> "(MIT AND BSD-3-CLAUSE)" express how the license text requirements
> are imposed on recipients (users and developers).  License expressions
> use the long-standing convention is that if software is licensed
> using "this or any later version" you add a "+" to the name of the
> license. You can argue that the "+" should be the default,
> but standards typically work best if they build on pre-existing
> conventions, and that was certainly the case here.

David:
What you saying in substance is that every time I want state
that code is licensed under the GPL 2.0 or any other version
(which is the default), you want me to craft a special license
expression with a plus. And If do not craft that expression,
then the SPDX meaning is that only the current version applies
and not any later version.

I am saying this instead: Since the default for the GPL is to allow
later versions, we should by default state the opposite:
The few times that "only the current version" should be used, state
this explicitly with an exception.


You say:
GPL-2.0 ==> implies  GPL 2.0 only
GPL-2.0+ ==> implies  GPL 2.0 or later

I say:
GPL-2.0 ==> implies  GPL 2.0 with its defaults (including later versions)
GPL-2.0 with no-other-version  ==> implies GPL 2.0 and no other version

Explicit is better than implicit.


My rationale:
Practically the use of a GPL version "only" is much less frequent
than the default "or later" and therefore forcing me to add a plus
is a source of confusion.

The most common use case should be the default and should not
require a special addition of a character in an expression.

"only" should be an exception and not the default, because it is
not the default, nor the prevalent usage of the GPL: it is exceptional.

The fact that the + convention has been used by Linux distros
package maintainers and neither always strictly nor consistently
does not make this right and something that should be endorsed blindly.

So to recap:
I am NOT arguing about the syntax to express this.

I am arguing about the essence of the meaning of the plain GPL-2.0
license key in a simple expression.

The mere use of a GPL-2.0 identifier should convey that the license
is GPL-2.0 or any other version.

We should have an exception to convey the rarer cases when only
the stated version applies.

The benefits are:
1. no ambiguity about the meaning of widely used licenses such as
the GPL.
2. simpler spec
2. simpler expressions in most cases, more verbose and more explicit
expressions when needed in some rarer cases.

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Is "+" a valid character of a LicenseRef idstring?

[Philippe Ombredanne]

On Mon, Nov 2, 2015 at 8:17 PM, Tom Incorvia
<tom.incor...@microfocus.com> wrote:

> So we're all on the same page in this discussion: are you are
> referring to this section of the GPL-2.0 license:
>
> ==
> Each version is given a distinguishing version number. If the Program
> specifies a version number of this License which applies to it and
> "any later version", you have the option of following the terms and
> conditions either of that version or of any later version published
> by the Free Software Foundation. If the Program does not specify a
> version number of this License, you may choose any version ever
> published by the Free Software Foundation.
> ==

Yes, exactly that, and the related text found in the proposed
notice text found at the end of the GPL text:


This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published
by the Free Software Foundation; either version 2 of the License,
or (at your option) any later version.


... which is the default notice I see in most cases (except for
the not-so-uncommon case of the Kernel).

My take is that the large majority of programmers applying the
GPL to their work just take the default notice and only a very
few make an exception and restrict this to an exact version.

I even have pseudo scientific evidence to support this claim ;)
http://www.googlefight.com/free+software+foundation+and+no+other+version-vs-free+software+foundation%3B+either+version+2.php

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Is "+" a valid character of a LicenseRef idstring?

[Philippe Ombredanne]

On Mon, Nov 2, 2015 at 10:36 PM, Gary O'Neall <g...@sourceauditor.com> wrote:
>> This + is a suffix and not a freestanding character, right?
>> So "GPL-2.0+" is valid but "GPL-2.0+" would not be valid?

> My interpretation of the spec "GPL-2.0+" and "GPL-2.0+" are both 
> syntactically
> valid (as well as MIT+, LicenseRef-21+ and any other listed license ID or
> licenseRef).  This is not any statement on the interpretation, just the 
> license
> expression syntax (I'll leave the interpretation discussions to a separate 
> thread).
> In general, I would prefer any operator character(s) to be excluded from the
> allowed characters for a license reference to keep the parsing clear and
> easier to implement.

Gary, I cannot envision a simpler implementation than splitting on spaces.

A plus sign specified as a suffix that is not attached to a license key would
no longer be a suffix to me, but something entirely different.

My interpretation of the spec is that the + sign must be attached to the license
key and all examples provided in the spec support this interpretation.
If that part is not clear, let's fix the spec. This is not something frozen.

Now that said, I do not like the plus at all and we should remove entirely from
the spec.

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: SPDX Legal call this Thursday

[Philippe Ombredanne]

On Wed, Sep 16, 2015 at 2:33 AM, J Lovejoy <opensou...@jilayne.com> wrote:
> 3) License matching templates/markup:
> We have a task to add markup to some of the standard headers and have also
> had input to add/edit markup on existing licenses.  As a result of the
> latter, it has been raised that perhaps the markup could be improved. Before
> adding more markup (to standard headers, license text or both), it seemed
> prudent to start a discussion as to whether the existing markup is
> effective.  Please ponder the following questions:

> a) have you used the existing markup for matching purposes?

Yes and No:  ScanCode uses an SPDX-inspired/derived markup, but
instead of reusing the markup directly from the main license texts,
markup is transformed in a simpler {{mustache-like}} syntax added to
copies of these texts used only for detection purpose.

> i) if no, why not?

Because:
- adding more markup to a reference license text makes this eventually
no longer usable as a reference text and harder to read by humans
- the many variations found in the wild make it hard to put all in a
single template.
- the markup syntax implies eventually an implementation using regular
expressions. ScanCode does not use regex, but inverted indexes and
string alignments.

> ii) if yes, has it been helpful/effective?  Could it be improved, and if so,
> how? (this will likely involve putting forward a proposal for review)

I think a simple markup is a very effective way to detect licenses
with minor text variations and still call this an exact match.
It is also a very effective way to indicate variations for humans.
I find it hard personally to mix the human readability and technical
detection concerns in the same file without compromises.

As food for thought, here are some examples of markup as used in ScanCode:

https://github.com/nexB/scancode-toolkit/blob/b37be4de78152fbd3ed54761627c960010ce26a3/src/licensedcode/data/rules/apache-1.1_38.RULE#L17
https://github.com/nexB/scancode-toolkit/blob/b37be4de78152fbd3ed54761627c960010ce26a3/src/licensedcode/data/rules/bzip2-libbzip-1.0.5_1.RULE#L1

The syntax is using double curly braces to enclose variable parts.
There is no regex involved.
Optionally a number can be used after the opening braces to indicate
the number of variable words, defaulting to 5 words.
For instance {{ Copyright (c) 2015 Myco }} would match up to 5 words
and {{ 10 Copyright (c) 2015 Myco inc.}} would match up to 10 words.

I hope this helps even though this is a slightly different take.
-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Follow-up on RDF byte range

[Philippe Ombredanne]

On Fri, Jul 10, 2015 at 5:41 AM, Gary O'Neall g...@sourceauditor.com wrote:
 Hi Yev,
 Thanks for the pointer to the pointer vocabulary.
 Below are some of my thoughts - feel free to propose alternatives or provide 
 more specific examples on how we may use the pointer class for Snippets.
 - I do think  using the pointer classes would work for our purposes and would 
 have the advantage of using an already defined vocabulary.  It is a bit more 
 complex, but manageable.
 - I noticed that the pointers RDF vocabulary defines byte offsets based on 1 
 for the first byte in the document (not zero).  If we want to re-use these 
 terms, we would need to define the byte ranges relative to 1 for both RDF and 
 Tag/Value for compatibility.
 - Pointers include a required property to reference the document the byte 
 range applies to.  We could use the URI for the SPDX file as the value for 
 this property.  This would somewhat redundant with the SPDX File property.  
 Not sure if we should retain both of these properties or not.  I'm currently 
 leaning toward retaining both properties.
 - There are a few choices on how to represent the byte range.  After looking 
 through the doc, the ByteOffsetCompondPointer uses an offset relative to the 
 startPointer (the pointer to the beginning of the range).  Based the 
 tag/value definition where the start byte and end bytes are relative to the 
 beginning of the file,  a StartEndPointer may be a better fit.  The 
 startPointer and endPointer would be a ByteOffsetPointer class to represent a 
 byte offset.
 - If we want to include optional line number offset, we could use the 
 LineCharPointer class.
 Below is an example based on my understanding of the pointer vocabulary:
[]

I think using bytes is impractical.
For instance, files from a simple git or svn checkout may be different
byte for byte on different machines and different settings
(end-of-line replacement, keyword substitution, etc) .

We are talking about line-oriented text source code.
Why not use the simpler, natural and human-understandable start and end line?
The compounded complexity of RDF and bytes is unlikely warranted here.

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: license expression syntax for exceptions [was: Re: Network connection dropping....]

[Philippe Ombredanne]

On Tue, Apr 21, 2015 at 7:12 PM,  kate.stew...@att.net wrote:
 Here is the revised syntax for ABNF,  please let us know
 if there are any concerns.

 license-id= short form license identifier in Appendix I.1
 license-exception-id  = short form license exception identifier in Appendix
 I.2
 license-ref   = LicenseRef-1*(ALPHA / DIGIT / - / . )
 simple-expression = license-id / license-id+ / license-ref
 compound-expression =  1*(simple-expression /
 simple-expression WITH license-exception-id /
 compound-expression AND compound-expression /
 compound-expression OR compound-expression ) /
 ( compound-expression ) )

 license-expression =  1*1(simple-expression / compound-expression)

May I suggest this alternative and slightly different grammar:

expression  = license / and-expression / or-expression /
( expression )
and-expression  = expression AND expression
or-expression   = expression OR expression

license = license-id / license-ref / license-with-exception
license-id  = identifier[+]  ; short form SPDX license
identifier with optional + for or later
license-ref = LicenseRef-identifier
exception-id= identifier  ; short form SPDX license
exception identifier
license-with-exception  = (license-id / license-ref) WITH exception-id

identifier  = alphanum[*(aphanum / punct)]
alphanum= ALPHA / DIGIT
punct   = - / .

The difference is that an identifier is defined as starting with a
letter or digit and this is specified for refs, id and an exception
ids.

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

license expression syntax for exceptions [was: Re: Network connection dropping....]

[Philippe Ombredanne]

On Tue, Apr 14, 2015 at 7:20 PM,  kate.stew...@att.net wrote:
 Problem point is

 WITH

 I don't think we want to force (GPL-2.0+ with bison-exception)
 but rather GPL-2.0+ with bison exception

Sorry if I jump the gun before you posted anything more detailed

Did you mean making the parenthesis optional: I would say yes for
sure, any expression that is not ambiguous should not require
parenthesis.

Or did you mean that we should add the word exception as a qualifier
 as in license-id with license-exception-id exception
If so I am not sure this would be warranted. The id for an exception
could be anything, but we could have the convention for SPDX-provided
exceptions IDs to suffix them with
-exception for clarity, though that would not be needed just a nice to
have. IMHO adding the keyword exception would be redundant with the
with keyword.


-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Tools Gathering at Collab Summit

[Philippe Ombredanne]

On Mon, Feb 2, 2015 at 8:40 PM, Gary O'Neall g...@sourceauditor.com wrote:
 Greetings all,

 I wanted to invite all interested in SPDX tools who are attending Linux
 Collab Summit to the BoF session on Thursday, Feb. 19 at 3:30 PM:

 This is an implementers BoF for the 2.0 Specification. Let's all compare
 notes on generating and/or consuming SPDX documents using the 2.0
 specification. Bring your example Use Cases and SPDX 2.0 Documents. Note
 that hand generated use cases are welcome and encouraged as well.

 If you don't plan to attend the collab summit but would like to provide
 input on implementing the SPDX 2.0 Spec, feel free to email me your thoughts
 and I'll bring it into the meeting.

 For the 1.1 spec, we had a very successful similar session where we
 generated SPDX documents from various tools and compared the output.  Based
 on what we learned, we were able to make a lot of improvements to the spec.
 The results from the 2013 meeting is still online at
 https://drive.google.com/folderview?ddrp=1id=0BxKdX878M2HCTlZIbkZSMXN6SGc#

 If you would like to participate in a similar activity, we could compare
 output on the following very made up scenario:

 Time version 1.7
 (http://pkgs.fedoraproject.org/repo/pkgs/time/time-1.7.tar.gz/e38d2b8b34b1ca259cf7b053caac32b3/)
 embeds a package ascii version 3.8
 (http://pkgs.fedoraproject.org/repo/pkgs/ascii/ascii-3.8.tar.gz/8fb7540bf2a7a8e1fa0086708ed9b881/).

 The Time package is exactly the same package we used for one of the
 comparisons in 2013 and  ascii is very small (one source file), so it should
 be easy to create an SPDX document even by hand.

 I setup google docs folder to share the results at:
 https://drive.google.com/folderview?id=0B-cBgwWx0N27THR1bXhBaWJQZnMusp

 Let me know if you have any questions or additional thoughts on the tools
 session.

I look forward to the face to face!

-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode : What's in your code?! at http://www.dejacode.com
nexB Inc. at http://www.nexb.com
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [GSOC] Go Parser Library status report

[Philippe Ombredanne]

On Mon, Jun 16, 2014 at 8:17 PM, Vlad Velici vlad.vel...@gmail.com wrote:
 I probably should have written a few status reports by now and I apologise 
 for that.
 My progress can be easily tracked on both the git.spdx.org repository[1] and,
 with a bit more details, on the issue tracker of the mirror repository on 
 GitHub [2].

Thanks for the update, I have been stalking what you have been up to there ;)

 What is done:
 - An abstract representation for SPDX documents (spdx.Document, spdx.Package, 
 etc.). Appropriate for SPDX 1.2 for the moment.
 - Tag format lexer and parser (with unit tests)
 - Tag format Writer / pretty-printer (both directly from a lexer or from a 
 spdx.Document object)
 - Skeleton of CLI tool
 Currently working on a validator for SPDX Documents in abstract format. I'm 
 making good progress on this. I estimate to finish it by the end of this week.

This looks good: do you think you could do a short demo presentation
of what you have so far some times?

 Some of the next steps:
 - Implement validation in the CLI tool
 - Decide on RDF Library to use (I'd appreciate suggestions - I've only seen 
 some bindings for raptor so far)

What are the good and bad about about goraptor? raptor is a rather
decent lib afaik.

 I hope everything is OK.

It is for me!

--
Cordially
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: current status of the java binding, and GSoC

[Philippe Ombredanne]

On Sun, Jun 8, 2014 at 10:46 PM, Hin-Tak Leung
ht...@users.sourceforge.net wrote:
 Others: I got the impression that the current java binding is unmaintained
 and unmaintainable - please correct me if I am wrong.

Which facts are the base of this rather harsh impression?
I am rather puzzled by this comment (that you happen to have mixed
with some unrelated student feedback) and your other comments below.

 That said, there are
 possibly lessons to be learned from what not to do, so I think it would
 be useful to open the floor for discussion about the current status
 of the java binding, what is good about it, what are the tools/functionalities
 available, and what are the unfixable problems, etc.

Again, which facts do you base these comments on?
For one thing did you actually install and used this java library?
What issues did you encounter if any?
Did you happen to report them on this list or as bugs?

 I also got the impression that some assume a re-write (or an alternative
 implementation) would be better. My sentiments are probably summarised in
 somebody else's writing  (http://www.jwz.org/doc/cadt.html); or that 
 something adopted
 in GSoC would automatically get done, and get done well by a lot of
 experienced people. Neither are the cases.

What is your impression based on? What are you trying to say exactly?

 Realistically, we should get 3-months x 2 of work from two smart students,
 by the end of the summer, that would be 2 additional language bindings; how 
 much
 that would engage contributions from the non-students, or other parties,
 we'll have to see. The best case scenario would be some useable work
 to base further work on by the end of the summer. It is unlikely
 to replace existing work/usage wholesale after 6-student-man-months, however.

Yes, so what?

 Based on past experience, it is unrealistic to expect the student to
 continue much beyond the summer - school work, or getting a real job, etc
 tend to come in. I have had one student who stated such honestly
 ('cannot see himself spending much time beyond'), and came back
 about 5 years later asking for another GSoC job - some countries have
 very long student lives - but that's rare. So 3-month is 3-month,
 please don't wishful-think that it will be a life-long dedicated commitment. 
 It isn't.

Again, so what? has anybody expressed any such wishful-think here ?

 Also, the failure rate of GSoC is about 10-15% overall, and quite
 similiar in the linux foundation unbrella. About 1 in about 8 projects
 does not pass mid-way evaluation, or the final evaluation.
 Sometimes it is just no show, student disappearing after
 the first payment, sometimes it is just excuses after excuses,
 or a lot of grand planning/design mission statements, without
 a single line of code to show; sometimes it is getting bog
 down to other things - e.g. a fictious scenario where the
 student spending a few weeks playing with git server
 configurations not essential to the work and/or could be
 solved in a few hours just by asking the right
 person/mailing-list, etc. To be honest, there are probably
 far more unsatisfactory projects than that 10-15%,
 mostly because mentors are reluctant to stop a free
 student from possibly contributing, even if all the signs
 are not good. So we may not necessarily have 2 useable new
 bindings by the end of the summer.

Do we have any sign of such issues *here* and not in general? Not that
I know of.

I am rather puzzled by the purpose -if any- of your comments and your
lack of enthusiasm.

I am a long time GSOC veteran mentor and my multiple experiences
seem quite different from your negative ones.

--
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [GSOC] Go Library SPDX version support

[Philippe Ombredanne]

On Sun, May 25, 2014 at 9:14 PM, Vlad Velici vlad.vel...@gmail.com wrote:
 1. Is it worth trying to create an (abstract) model (Go struct) to store Spdx 
 Documents regarding of their version and have different mechanisms for each 
 version to parse, write and validate?

IMHO, not worth.  Start with 1.2 with an eye towards what you noticed
as new things in 2.0 (such as multiple packages) but do not worry too
much about 2.0 for now

 2. I see that the describesPackage property of SpdxDocument class disappears 
 in version 2.0. In version 1.2 it was the way it added a package to a 
 SpdxDocument but now this seems to be achieved by using the relationship 
 property. Now, in 1.2 this limited a SpdxDocument to always have one package 
 (and not more) but this limit is not implied by the spec for version 2. Does 
 this mean that in version 2 a SpdxDocument can have none or more packages?

One or more, yes. This is a major change in 2.0

--
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

SPDX Perl parser [was: Re: [GSOC] SPDX Parser libraries project]

[Philippe Ombredanne]

On Sun, Mar 9, 2014 at 9:29 PM, Jeremiah Foster
jeremiah.fos...@pelagicore.com wrote:
 I'm writing one in perl because perl is widely used in Debian. I want to
 write a DEP5 to SPDX converter. This way I can generate a complete software
 BoM from an Debian or Debian-derived machine and put it into a tool like
 FOSSology. I'd also like to be able to do the reverse; use SPDX data to
 enable the generation of DEP5 files, though the use case here is a bit
 contrived.

Perl is awesome !
As for SPDX to DEP5 conversion, there are probably several
difficulties ahead, one of them being the files: full paths in SPDX
vs. patterns in DEP5.
Which would create likely bloated DEP5 files.
-- 
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: SPDX Perl parser [was: Re: [GSOC] SPDX Parser libraries project]

[Philippe Ombredanne]

On Mon, Mar 10, 2014 at 7:22 PM, Jeremiah Foster
jeremiah.fos...@pelagicore.com wrote:
 On Mon, Mar 10, 2014 at 4:02 PM, Philippe Ombredanne pombreda...@nexb.com
 wrote:
 As for SPDX to DEP5 conversion, there are probably several
 difficulties ahead, one of them being the files: full paths in SPDX
 vs. patterns in DEP5.


 Hmm. I guess I'll have to look at the spec. What I can see from a cursory
 bit of research is the DEP 5 format specified here:
 https://www.debian.org/doc/packaging-manuals/copyright-format/1.0//#file-syntax
 Is there a similar document for SPDX? I've looked on the wikipedia site, the
 Linux Foundation site, etc. and I cannot seem to find something similar.

This would the PDF at: http://spdx.org/sites/spdx/files/spdx-1%202.pdf

6 File Information
One instance of the File Information is required for each file in the
software package. It provides important meta
information about a given file including licenses and copyright. Each
instance should include the following fields.
6.1 File Name
6.1.1
Purpose: Identify the full path and filename that corresponds to the
file information in this
section.

The key point in SPDX being full path, whereas DEP5
http://dep.debian.net/deps/dep5/#files-field talks about more compact
patterns.
I shall say that the Debian approach makes a lot of sense to me.

--
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: [GSOC] SPDX Parser libraries project

[Philippe Ombredanne]

On Sun, Mar 9, 2014 at 4:23 AM, ahi ahm3d.his...@gmail.com wrote:
 Hello,
 First allow me to introduce myself, My name is Ahmed Hisham I am
 currently a  CS student at the German University in Cairo. I hope to
 spend the summer working on the SPDX parser libraries project list on
 the idea page at
 http://www.linuxfoundation.org/collaborate/workgroups/gsoc/gsoc-2014-spdx-projects.

Hello Ahmed!
Thank you for your interest in SPDX.
What else can you tell us about you?

 I have a couple of questions about the project, regarding what version
 of the spec is it expected to support.
 Should it support older version than the current spec ?

I do not think that would very be valuable to support 1.0 and 1.1.
Best would be to support the newest (1.2) and next version (2.0) IMHO.

 Should it partially support the upcoming spec 2.0 ? If so is there a
 publicly available working draft?
 I say partially as the spec is expected to be release in august and by
 then the summer of code will be at its end.

Yes that would work best.

Now which language would you have in mind?
Hint: Java is already covered.
My choices would be Python, Go, JavaScript and Ruby in this order.

Cordially

-- 
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Fwd: [GSoC Mentors Announce] Re: Now Accepting Applications for Mentoring Organizations for GSoC 2014

[Philippe Ombredanne]

FYI


-- Forwarded message --
From: Carol Smith car...@google.com
Date: Thu, Feb 13, 2014 at 4:47 PM
Subject: [GSoC Mentors Announce] Re: Now Accepting Applications for
Mentoring Organizations for GSoC 2014
To: GSoC Mentors Announce gsoc-mentors-annou...@googlegroups.com


Hi everyone,

Just a friendly reminder that applications for mentoring organizations
close in about 24 hours. Please get your applications in soon, we will
not accept late applications for any reason!

Thanks,
Carol

On Mon, Feb 3, 2014 at 11:01 AM, Carol Smith car...@google.com wrote:
 Hi all,

 We're pleased to announce that applications for mentoring organizations for
 Google Summer of Code 2014 are now being accepted [1]. If you'd like to
 apply to be a mentoring organization you can do so now via Melange [2]. If
 you have questions about how to use Melange, please see our User's Guide
 [3]. Please note that the application process has changed a bit from
 previous years: to apply you must now create your individual profile and
 then an organization profile before submitting your application.

 Please note that the application period [4] closes on 14 February at 19:00
 UTC [5]. We will not accept any late applications for any reason.

 [1] -
 http://google-opensource.blogspot.com/2014/02/mentoring-organization-applications-now.html
 [2] - http://www.google-melange.com
 [3] - http://en.flossmanuals.net/melange/
 [4] - http://www.google-melange.com/gsoc/events/google/gsoc2014
 [5] - http://goo.gl/bYYgV3

 Cheers,
 Carol

--
You received this message because you are subscribed to the Google
Groups Google Summer of Code Mentors Announce List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to gsoc-mentors-announce+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/gsoc-mentors-announce.
For more options, visit https://groups.google.com/groups/opt_out.


-- 
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Revisiting the SPDX license representation syntax

[Philippe Ombredanne]

On Tue, Oct 29, 2013 at 7:26 AM, Wolfgang Denk w...@denx.de wrote:
 In message 
 caofm3uedjbvgywltsp0xmxe1vrefomaapenzkhekdx6+-xv...@mail.gmail.com you 
 wrote:
 Here are the basic examples updated to SPDX:
 Thanks - I mostly like this, but I would like to suggest a few minor
 changes to make life easier especially to developers who are used to
 standard operators in programming languages:

Guten Tag Wolfgang!
and thanks for your feedback.

 * mit ? gpl-2.0 : a disjunctive license choice of mit or gpl-2.0.
 A choice must be made. (CHOICE, EXCLUSIVE OR, DISJUNCTION)

 In C and some other programming languages, the EXCLUSIVE OR operator
 is '^', so please make this mit ^ gpl-2.0.

 * gpl-2.0 ^ classpath : a license exception or supplemental terms:
 here, the classpath exception to the gpl-2.0. nb: here we have a
 slight change with the SPDX license list, where the exception would be
 just the exception and not the whole gpl-and-classpath taken together
 as one license.(EXTRA TERMS, EXCEPTION)

 Please use a different operator t mark an exception, as '^' is kind of
 reserved for XOR.

You are absolutely right there and being a programmer I had hesitated
a little about the implications then,
and thought that it would be OK to forego programming conventions.
Expressing disjunctions with a  caret ^ makes perfect sense.
In this case, and this would be a good simplification the explicit
ampersand  or the implicit space AND separator could be used for a
license exception or supplemental terms which is really all that is
needed.
For instance:
gpl-2.0 +  classpath: I am licensed under the GPL 2.0 or any later
version with the Classpath expection
which could rephrased also as something more or less equivalent for
such as this, because the classpath exception states that it can be
removed:
(gpl-2.0 +  classpath) ^ gpl-2.0 + : you must select the GPL 2.0 or
3.0 with or without the Classpath exception

Note that FWIW this little language of mine was buried in notes I
wrote down four years ago, and has never been in use practically
I just adapted it in this email thread to use SPDX license keys.

-- 
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode Enterprise at http://www.dejacode.com
nexB Inc. at http://www.nexb.com
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Revisiting the SPDX license representation syntax

[Philippe Ombredanne]

On Mon, Oct 28, 2013 at 10:57 PM, Gisi, Mark mark.g...@windriver.com wrote:
 One basic observation - We need to consider how far one can go in 
 constructing an expression that implies some level of legal interpretation. 
 For instance, in one of your examples you noted:

   * gpl-2.0  mit: I think that the license that applies here is gpl-2.0, 
 despite
 being asserted originally as MIT-licensed (possibly because of linking, 
 dependencies, code reuse or else).

 One objective might be: To support the construction of license expressions 
 that
 represent licensing terms of the pieces that go into building a distributable
 component (e.g., program) yet allow different organizations the ability to
 apply their legal interpretation. I do realize this is easier said than done.

Exactly!
The intent when I wrote down an example starting with I think is to
show where such a syntax could capture eventual interpretations that a
user/adopter of SDPX would want to express.
I am NOT saying that SPDX should provide such interpretation, but that
the system should not prohibit someone else to make these
interpretations and should support capturing these in  a
straightforward way.

 I see a fair amount of differences among organization in their interpretation
 of licensing, especially when multiple licenses are present (as you have 
 illustrated below).

Same, and leaving aside whacko interpretations such as GPL cannot be
used commercially, there are many grey areas where different
organizations and different counsels may look at things slightly
differently and come to different conclusions based on the same
original materials.

 I hope we can encourage others to present situations they believe the current 
 SPDX licensing mechanism does not easily support.

+1!

-- 
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode Enterprise at http://www.dejacode.com
nexB Inc. at http://www.nexb.com

CONFIDENTIALITY NOTICE:  This e-mail (including attachments) may
contain information that is proprietary or confidential. If you are
not the intended recipient or a person responsible for its delivery to
the intended recipient, do not copy or distribute it. Please
permanently delete the e-mail and any attachments, and notify us
immediately at (650) 799 0949.
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Revisiting the SPDX license representation syntax (Package vs. Program license)

[Philippe Ombredanne]

On Tue, Oct 29, 2013 at 5:39 PM, RUFFIN, MICHEL (MICHEL)
michel.ruf...@alcatel-lucent.com wrote:
 I just want to point out that we are mostly dealing with package level system
 If I take the example of JBoss in our FOSS DB you get the following (see 
 below)
 So the concluded license is just LGPL-2.1 AND(+) a lot of dependencies

Michel:
My 2 cents, I would possibly express this either:
  * as lplg-2.1+ {mit bsd-3-clause and a long list of licenses  }
using my 'little language'

OR

  * I would create a new license internally which I would call the
something like the JBossAS-4.2.1 license. This would be a 'composite'
of all the licenses contained in this large component, abstracting the
details. AFAIK, there is nothing in SPDX that would prohibit you from
creating your own licenses for this purpose.
You could even provide both the long list of SPDX ids AND the composite text.

 On lundi 28 octobre 2013 23:23 Gisi, Mark [mailto:mark.g...@windriver.com] 
 wrote:
 All in all, Boolean expressions provide an effective way to describe 
 licensing of
 programs, libraries and source files (linkable distributable components).
 Package licensing is an ill defined concept. Often a package can be viewed
 as a box containing a collection of components each *potentially* subject to
 different licensing terms. We will need to address these differences in the
 upcoming licensing breakout session.

Mark and Michel:
IMHO, you guys are coming from two different points of view but are
talking the same language.

As a Linux distro vendor (or a JBoss distro provider) I may want to
express the obligations of the packages I distribute (be they mine or
from upstream) at a finer level of granularity, which would be
possible unit of discrete consumption. This would then be helpful to
downstream consumers such they could make informed decisions when they
consume, use, build or link with components I provide in my distro.

As a component consumer, I may want to treat these upstream
obligations at a more coarse level, and treat larger things possibly
as big as a Linux distro or a JBoss as one aggregate component, and
may or may not care about finer-grained details passed to me from
upstream.

Because in the end, somehow, your product (that you may see as several
fine-grained components) may be one of the many components for my own
product or application and I may see as just one single component.

I think that SPDX does and should in spirit and letter support both approaches.

-- 
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode Enterprise at http://www.dejacode.com
nexB Inc. at http://www.nexb.com
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: none

[Philippe Ombredanne]

On Sun, Jun 16, 2013 at 7:47 PM, D M German d...@uvic.ca wrote:
 * Double braces {{}}
 One problem I have run into is that {{}} are widely used by wikis and
 other HTML systems to escape a template of some sort. Try for example
 editing the following page and changing {{}} to {{ and }}
 http://wiki.spdx.org/view/Technical_Team/Proposals/2013-6-13/License_Template
 I have added the example at the bottom of the page. You will see how it
 is rendered because the wiki software has special interpretation for
 these fields.
 I ran into the same problem at github and even my own website software.
 This will make our editing of the rules in the wiki more difficult that
 they need to be. My suggestion is to replace the double braces with
 double angle brackets 
 Again, this is simply stylistic and does not change anything.

Daniel:
I think the main reason why curly braces were selected is because they
are a de-facto convention for text template engines, which of course
includes things like wiki and several HTML and text templating systems
and libraries.
This is actually part of their appeal, not a drawback IMHO.
And yes this may mean that in cases we will have to escape the curly
braces properly or mark them such that they are not  recognized by a
template engine. And angle brackets would likely have the same issues
wrt to HTML/XML.

-- 
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech