Coarse level compliance is an interesting term. It suggests a level of compliance quality where one chooses to comply with some applicable licenses but not others. For example, saying the Android

<michel.ruffin@...> wrote: 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

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

Mark, I do not criticize the boolean system 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

Guten Tag Wolfgang! and thanks for your feedback. 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

Dear Philippe Ombredanne, In message <CAOFm3uEDjBvgyWLTsp0xMXe1vRefoMaAPEnzKhekdx6+-xVohg@...> you wrote: Thanks - I mostly like this, but I would like to suggest a few inor changes to

Michel, You make some good points which I would like to build upon for the upcoming discussion. >>> Note that it is quite frequent to find SW which is (GPL and LGPL): the standalone code is

Hi Philippe, This is the main thesis that is driving this breakout discussion. Thank you for the extensive list of examples and proposals. They represent the types of scenarios we need to test the

Thank you to everyone who participated in the review of the below-referenced licenses on the SPDX Legal call this week. 7 licenses were approved for inclusion in the SPDX List and one was deferred for

Looking over http://spdx.org/licenses/, we see Artistic-1.0-cl8 and Artistic-1.0-Perl. The cl8 points to http://opensource.org/licenses/Artistic-1.0 and makes sense. However,

Legal Team, Sorry this (and I) missed yesterday's meeting. Could someone raise their hand to look at this? Thanks from LinuxCon Europe, Phil

I agree that license decomposition is a hard topic but as a first step perhaps a full decomposition in 70 attributes as Tom suggestion is perhaps too much effort. If you look at the OSI licenses there

Let me bring my 2 cents to the discussion. A while back I wrote down this little language to compose licenses. The point was to : - make this easy enough for humans and machines to read, write and

Reminder: SPDX Legal call tomorrow at 10am PT / 1pm ET Dial in 1-415-363-0849 Access Code: 336247 Alternative Numbers: http://www.yuuguu.com/audio Agenda 1. License Matching

Hi Michel, Thanks for sharing your experiences. I agree these are worthy topics. I have had a number of similar conversations with Wind River customers through the years. Although these topics

Hi Michael, I am an early contributor to SPDX, but have been quiet lately. I would recommend that we delay moving into rights and obligations until our foundation in the descriptions is more

Mark, I think that we should go further (moving from syntax to semantic). We should decomposed FOSS license in terms of right and obligations (Blackduck call that attributes in its protex tool).

Dear all, The OMG (Object Management group) is organizing a workshop on standardizing open source governance practices on December 11 in Santa Clara (CA)

In the last SPDX Legal meeting we discussed whether the current SPDX license representation syntax is sufficient to represent the licensing terms of most files (e.g., source, library and binary

SPDX Legal Team, We have 8 licenses from the Fedora License List that are current candidates for inclusion in the SPDX License List. Prior to Thursday's call, please review the Fedora Good List