|
Per discussion late meeting, agendas will be going out in bodies of emails and minutes will go out as links to archive at spdx.org. I'll strive to get minutes out a week in advance, though I'm behind this time. Here's where they are posted (note that Kate is still editing, so they won't be final until tonight) http://www.spdx.org/wiki/minutes-26aug2010
Meeting Time: Sept 9, 8am PDT / 10 am CDT / 11am EDT / 16:00 GMT
Conf call dial-in:
NOTE: THIS NUMBER IS DIFFERENT FROM PAST NUMBERS AND WILL BE CHANGING IN THE FUTURE.
Conference code: 7812589502
Toll-free dial-in number (U.S. and Canada): (877) 435-0230
International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of toll free numbers can be found: https://www.intercallonline.com/portlets/scheduling/viewNumbers/viewNumber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF
Web:
Note, we will be using a different URL for each meeting for purposes of taking attendance. When you login please include your full name and company name, so I can just copy/pate into minutes. THX. Common Messaging/Presentation – PhilO
Roll Out Plans - KimW/JohnE
• PhilO/Martin - Update on participation page where to join (suggestion was to put link in text, not just at top, consider "I want to use the spec, vs. I want to contribute to the spec" in navigation section. • Kate- Transfer document (.pdf) back to WIKI. • PhilO- Update standard presentation with LinuxCon2010 input • Kate- Clean up the sharing analysis to what is accurate. • Kate- Publish the current version number of the specification in brackets behind reference • Kim/PhilO- Add and element of 'What's in this for me?" to presentation • JeffL (w/Bill/Gary- Update zlib based on new specification • All- Look for new examples to add to site. • PhilK- Explore possibility of LF hosting source for SPDX tools. • Gary- Explore other possible hosting options • PhilO- Start making minutes available via link. • BillS- Start up RDF sub-group. Solicite members.
SPEC - current status and open areas - Kate
RDF focus group - current status - Bill
Tools - update from Gary, and others.
L. Philip Odence Vice President of Business Development Black Duck Software, inc. 265 Winter Street, Waltham, MA 02451 Phone: 781.810.1819, Mobile: 781.258.9502
|
|
|
From the minutes: Our implicit path had tied a fixed license list of licenses to the spec rev, but JohnE put forth an impassioned argument as to why they should be decouples... I throw my support behind JohnE proposal. It addresses many of the issues I have discussed before. --dmg (hopefully I can make wake up in time for the meeting, but it is tough to only have 5 hrs of sleep :) On Wed, Sep 8, 2010 at 11:24 AM, Philip Odence <podence@...> wrote: Per discussion late meeting, agendas will be going out in bodies of emails
and minutes will go out as links to archive at spdx.org.
I'll strive to get minutes out a week in advance, though I'm behind this
time. Here's where they are posted (note that Kate is still editing, so they
won't be final until tonight) http://www.spdx.org/wiki/minutes-26aug2010
Meeting Time: Sept 9, 8am PDT / 10 am CDT / 11am EDT / 16:00 GMT
Conf call dial-in:
NOTE: THIS NUMBER IS DIFFERENT FROM PAST NUMBERS AND WILL BE CHANGING IN THE
FUTURE.
Conference code: 7812589502
Toll-free dial-in number (U.S. and Canada): (877) 435-0230
International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of toll free numbers can be
found: https://www.intercallonline.com/portlets/scheduling/viewNumbers/viewNumber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF
Web:
Note, we will be using a different URL for each meeting for purposes of
taking attendance. When you login please include your full name and company
name, so I can just copy/pate into minutes. THX.
http://blackducksoftware.na6.acrobat.com/spdx9sept10/
Administrative Agenda
Attendance
Approval of minutes
Outreach and evangelism:
Common Messaging/Presentation – PhilO
Industry Venues – PhilR
Website – PhilO/Martin
Roll Out Plans - KimW/JohnE
Action Items
Note: Drafting related action items are embedded in
the Wiki. http://www.spdx.org/wiki/spdx/specification
• PhilO/Martin - Update on participation page where to join (suggestion was
to put link in text, not just at top, consider "I want to use the spec, vs.
I want to contribute to the spec" in navigation section.
• Kate- Transfer document (.pdf) back to WIKI.
• PhilO- Update standard presentation with LinuxCon2010 input
• Kate- Clean up the sharing analysis to what is accurate.
• Kate- Publish the current version number of the specification in brackets
behind reference
• Kim/PhilO- Add and element of 'What's in this for me?" to presentation
• JeffL (w/Bill/Gary- Update zlib based on new specification
• All- Look for new examples to add to site.
• PhilK- Explore possibility of LF hosting source for SPDX tools.
• Gary- Explore other possible hosting options
• PhilO- Start making minutes available via link.
• BillS- Start up RDF sub-group. Solicite members.
Technical Agenda
SPEC - current status and open areas - Kate
RDF focus group - current status - Bill
Tools - update from Gary, and others.
L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502
podence@...
http://www.blackducksoftware.com
http://twitter.com/podence
http://www.linkedin.com/in/podence
http://www.networkworld.com/community/odence (my blog)
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
-- --dmg --- Daniel M. German http://turingmachine.org
|
|
|
I also agree that we should decouple spec from licenses. We need a way to add licenses without having to rev the spec. Otherwise we will get lots of spec revisions or very few license updates. I know there has been some concern that if the list of licenses is not "fixed" with the spec version, you won't know what list of licenses you need to be able to "understand" when you get an SPDX file based on a particular version of the spec. I'd like to dig into this use case more, since it seems to me that any tooling or even manual review processes can be designed to just pull the latest and greatest version of licenses from the website. The only issue is that you may get an SPDX file that has something marked as an "Other" license that is now in the standard license repo. That shouldn't really be a problem, since all the "Other" licenses will have full license text in the SPDX file. Here's an example: Company A creates SPDX on 1/1/2011 using latest set of standard licenses at that point. They identify: File A has Standard License A File B has Standard License B File C has Other License C File D has Other License D On 2/1/2011, License C is added to standard license repo Company B reviews SPDX on 3/1/2011 All of the info is still valid -- since License C and D are in the SPDX file. Company B could choose to update the SPDX file as: File A has Standard License A File B has Standard License B File C now has STANDARD License C File D has Other License D Am I missing something here? Kim On Wed 9/8/10 12:48 PM, "dmg" <dmg@...> wrote: From the minutes:
Our implicit path had tied a fixed license list of licenses to the
spec rev, but JohnE put forth an impassioned argument as to why they
should be decouples...
I throw my support behind JohnE proposal. It addresses many of the
issues I have discussed before.
--dmg
(hopefully I can make wake up in time for the meeting, but it is tough
to only have 5 hrs of sleep :)
On Wed, Sep 8, 2010 at 11:24 AM, Philip Odence
<podence@...> wrote:
Per discussion late meeting, agendas will be going out in bodies of emails
and minutes will go out as links to archive at spdx.org.
I'll strive to get minutes out a week in advance, though I'm behind this
time. Here's where they are posted (note that Kate is still editing, so they
won't be final until tonight) http://www.spdx.org/wiki/minutes-26aug2010
Meeting Time: Sept 9, 8am PDT / 10 am CDT / 11am EDT / 16:00 GMT
Conf call dial-in:
NOTE: THIS NUMBER IS DIFFERENT FROM PAST NUMBERS AND WILL BE CHANGING IN THE
FUTURE.
Conference code: 7812589502
Toll-free dial-in number (U.S. and Canada): (877) 435-0230
International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of toll free numbers can be
found: https://www.intercallonline.com/portlets/scheduling/viewNumbers/viewNu
mber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF
Web:
Note, we will be using a different URL for each meeting for purposes of
taking attendance. When you login please include your full name and company
name, so I can just copy/pate into minutes. THX.
http://blackducksoftware.na6.acrobat.com/spdx9sept10/
Administrative Agenda
Attendance
Approval of minutes
Outreach and evangelism:
Common Messaging/Presentation PhilO
Industry Venues PhilR
Website PhilO/Martin
Roll Out Plans - KimW/JohnE
Action Items
Note: Drafting related action items are embedded in
the Wiki. http://www.spdx.org/wiki/spdx/specification
€ PhilO/Martin - Update on participation page where to join (suggestion was
to put link in text, not just at top, consider "I want to use the spec, vs.
I want to contribute to the spec" in navigation section.
€ Kate- Transfer document (.pdf) back to WIKI.
€ PhilO- Update standard presentation with LinuxCon2010 input
€ Kate- Clean up the sharing analysis to what is accurate.
€ Kate- Publish the current version number of the specification in brackets
behind reference
€ Kim/PhilO- Add and element of 'What's in this for me?" to presentation
€ JeffL (w/Bill/Gary- Update zlib based on new specification
€ All- Look for new examples to add to site.
€ PhilK- Explore possibility of LF hosting source for SPDX tools.
€ Gary- Explore other possible hosting options
€ PhilO- Start making minutes available via link.
€ BillS- Start up RDF sub-group. Solicite members.
Technical Agenda
SPEC - current status and open areas - Kate
RDF focus group - current status - Bill
Tools - update from Gary, and others.
L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502
podence@...
http://www.blackducksoftware.com
http://twitter.com/podence
http://www.linkedin.com/in/podence
http://www.networkworld.com/community/odence (my blog)
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
Kim Weins | Senior Vice President, Marketing kim.weins@... Follow me on Twitter @KimAtOpenLogic 650 279 0410 | cell www.openlogic.com Follow OpenLogic on Twitter @OpenLogic OpenLogic, Inc. Headquarters, Broomfield, Colorado
|
|
|
Bruno Cornec <Bruno.Cornec@...>
Kim Weins said on Wed, Sep 08, 2010 at 05:05:46PM -0600: The only issue is that you may get an SPDX file that has something marked as
an "Other" license that is now in the standard license repo. That
shouldn't really be a problem, since all the "Other" licenses will have full
license text in the SPDX file. Which in fact solves the point I had during the conf call this week. If the license is known to spdx, then we can point to a uri/url linked to spdx.org having it full text. If not, the full text is then embedded, as long as the license doesn't become official, in which case, it can be further offloaded from the SPDX file. Meaning we could have: File A has Std license: " http://www.spdx.org/license/GPLv2"File B has Other license embedded "this is the free beer license..." Thus keeping duplication to a minimum. Bruno. -- Open Source & Linux Profession Lead EMEA / http://opensource.hp.comHP/Intel/Red Hat Open Source Solutions Initiative / http://www.hpintelco.nethttp://www.HyPer-Linux.org http://mondorescue.org http://project-builder.orgLa musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
|
|
|
Hi Kim, Daniel,
Use case I'm worried about is how do we say what MUST be recognized when all the licenses are on the web. What happens when we don't have a stable base set of "must recognize" to conform.
If we make everything on the web, then the use case of including in the spdx file, the full text of ALL licenses discovered (even if they are ones that have a short form) - will conform to the specification.
Comparisons between analysis of the same package will become "interesting".
Consider package "1" has licenses A, B, C, D in it. A, B, are on the web site, C, D aren't. One analysis tool produces a file with short form of A & B in the spec, C & D included verbatim. Another analysis tool produces a file with A, B, C, & D included verbatim. Both can be said to be SPDX 1.0, but if you compare both to each other, you may not draw the conclusion that they are talking about the same package.
On the other hand, I do understand the concern over not rev'ing the spec too often to conform to license changes.
What do people think about the following for 1.0?
There is a base set of licenses, that MUST be recognized and included as short forms, to conform, and they are captured in Appendix I of the SPEC, as well as being on the web site. This gives the potential for creating a spec which is all inclusive - full text of licenses recognized as short forms, which others on the list have indicated a need for. We include language in the spec, saying these are the ones that MUST be recognized, but others on the website CAN be recognized as well. When there is critical mass of changes to rev the spec to 2.0; the set that is on the web site at that time, becomes the MUST be recognized, and additions after that are CAN be recognized. This avoids the point revision churn for licenses that John's afraid of, allows an enforcement of a minimum set, and give a path to add new licenses as they are nominated into the "active set".
Thoughts?
Kate
toggle quoted message
Show quoted text
--- On Wed, 9/8/10, Kim Weins <kim.weins@...> wrote: From: Kim Weins <kim.weins@...>
Subject: Re: SPDX Agenda/Minutes
To: "dmg" <dmg@...>, "Philip Odence" <podence@...>
Cc: "spdx@..." <spdx@...>
Date: Wednesday, September 8, 2010, 6:05 PM
I also agree that we should decouple
spec from licenses. We need a way to
add licenses without having to rev the spec.
Otherwise we will get lots of
spec revisions or very few license updates.
I know there has been some concern that if the list of
licenses is not
"fixed" with the spec version, you won't know what list of
licenses you need
to be able to "understand" when you get an SPDX file based
on a particular
version of the spec. I'd like to dig into this use case
more, since it seems
to me that any tooling or even manual review processes can
be designed to
just pull the latest and greatest version of licenses from
the website.
The only issue is that you may get an SPDX file that has
something marked as
an "Other" license that is now in the standard
license repo. That
shouldn't really be a problem, since all the "Other"
licenses will have full
license text in the SPDX file.
Here's an example:
Company A creates SPDX on 1/1/2011 using latest set of
standard licenses at
that point. They identify:
File A has Standard License A
File B has Standard License B
File C has Other License C
File D has Other License D
On 2/1/2011, License C is added to standard license repo
Company B reviews SPDX on 3/1/2011
All of the info is still valid -- since License C and D are
in the SPDX
file. Company B could choose to update the SPDX file
as:
File A has Standard License A
File B has Standard License B
File C now has STANDARD License C
File D has Other License D
Am I missing something here?
Kim
On Wed 9/8/10 12:48 PM, "dmg" <dmg@...>
wrote:
From the minutes:
Our implicit path had tied a fixed license list of licenses to the
spec rev, but JohnE put forth an impassioned argument as to why they
should be decouples...
I throw my support behind JohnE proposal. It addresses many of the
issues I have discussed before.
--dmg
(hopefully I can make wake up in time for the meeting, but it is tough
to only have 5 hrs of sleep :)
On Wed, Sep 8, 2010 at 11:24 AM, Philip Odence
<podence@...> wrote:
Per discussion late meeting, agendas will be going
out in bodies of emails
and minutes will go out as links to archive at
spdx.org.
I'll strive to get minutes out a week in advance,
though I'm behind this
time. Here's where they are posted (note that Kate
is still editing, so they
won't be final until tonight) http://www.spdx.org/wiki/minutes-26aug2010
Meeting Time: Sept 9, 8am PDT / 10 am CDT / 11am
EDT / 16:00 GMT
Conf call dial-in:
NOTE: THIS NUMBER IS DIFFERENT FROM PAST NUMBERS
AND WILL BE CHANGING IN THE
FUTURE.
Conference code: 7812589502
Toll-free dial-in number (U.S. and
Canada): (877) 435-0230
International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of
toll free numbers can be
found: https://www.intercallonline.com/portlets/scheduling/viewNumbers/viewNu
mber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF
Web:
Note, we will be using a different URL for each
meeting for purposes of
taking attendance. When you login please include
your full name and company
name, so I can just copy/pate into minutes. THX.
http://blackducksoftware.na6.acrobat.com/spdx9sept10/
Administrative Agenda
Attendance
Approval of minutes
Outreach and evangelism:
Common Messaging/Presentation PhilO
Industry Venues PhilR
Website PhilO/Martin
Roll Out Plans - KimW/JohnE
Action Items
Note: Drafting related action items are embedded
in
the Wiki. http://www.spdx.org/wiki/spdx/specification
€ PhilO/Martin - Update on participation page
where to join (suggestion was
to put link in text, not just at top, consider "I
want to use the spec, vs.
I want to contribute to the spec" in navigation
section.
€ Kate- Transfer document (.pdf) back to WIKI.
€ PhilO- Update standard presentation with
LinuxCon2010 input
€ Kate- Clean up the sharing analysis to what is
accurate.
€ Kate- Publish the current version number of
the specification in brackets
behind reference
€ Kim/PhilO- Add and element of 'What's in this
for me?" to presentation
€ JeffL (w/Bill/Gary- Update zlib based on new
specification
€ All- Look for new examples to add to site.
€ PhilK- Explore possibility of LF hosting
source for SPDX tools.
€ Gary- Explore other possible hosting options
€ PhilO- Start making minutes available via
link.
€ BillS- Start up RDF sub-group. Solicite
members.
Technical Agenda
SPEC - current status and open areas - Kate
RDF focus group - current status - Bill
Tools - update from Gary, and others.
L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502
podence@...
http://www.blackducksoftware.com
http://twitter.com/podence
http://www.linkedin.com/in/podence
http://www.networkworld.com/community/odence (my blog)
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
Kim Weins | Senior Vice President, Marketing
kim.weins@...
Follow me on Twitter @KimAtOpenLogic
650 279 0410 | cell
www.openlogic.com
Follow OpenLogic on Twitter @OpenLogic
OpenLogic, Inc.
Headquarters, Broomfield, Colorado
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
Dear All, By uncoupling licenses and standard, I see a high risk, that we end up in many different quasi-sub-standards of spdx. As in the example, what if several users of the license C and D give different license name tags to them, before they eventually get adopted by the license list? One Spdx file says 1. Standard | License A 2. Standard | License B 3. Custom | License C (attached license text x) 4. Custom | License D (attached license text y) Another one, describing the same package, says 1. Standard | License A 2. Standard | License B 3. Custom | License 3 (attached license text x) 4. Custom | License 4 (attached license text y) And another spdx file, describing a DIFFERENT package says 1. Standard | License A 2. Standard | License B 3. Custom | License C (attached license text z) 4. Custom | License D (attached whatever) Sure the files will work on their own. But if I eventually want to update them all to the newest standard, I will end up in either a lot of mismatches, or in a lot of manual work; i.e. the very two things spdx shall avoid (in my understanding). Therefore my opinion is to include in V.1.0 as many licenses as possible. Target should not be: include 80% of the licenses in Red-Hat; Target should rather be: include 100% of the licenses we know of. Why would it hurt us to include more licenses in the standard upfront? Once we have done this, there should not be so many revisions due to additional licenses. How many new FOSS licenses are established per year? I do not think it is too much nowadays. The only thing that may happen frequently is that someone adds a single special clause to a well known license. For these cases I would like to propose again to include a system to capture such slight variations by referring to the original version and describe the changes only. E.g. The newer ECos-License ( http://ecos.sourceware.org/license-overview.html) does not need to be an own license in the standard. The license describer could rather look like DeclaredLicense = GPLv2 LicenseVariation = yes VariationContents = ++ As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License. ++ However the source code for this file must still be made available in accordance with section (3) of the GNU General Public License. ++ This exception does not invalidate any other reasons why a work based on this file might be covered by the GNU General Public License. ... or something the like. Kind regards Soeren Rabenstein ____________________________________________________________ ASUSTeK COMPUTER INC. Soeren Rabenstein, LL.M. Legal Affairs Center - Legal Compliance Dept. 15, Li-Te Rd., Taipei 112, Taiwan Tel.: (+886) 2 2894 3447 Ext.2372 Fax.: (+886) 2 2890 7674 soeren_rabenstein@... ____________________________________________________________
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...]
On Behalf Of kate.stewart@...
Sent: Thursday, September 09, 2010 10:14 AM
To: dmg; Philip Odence; Kim Weins
Cc: spdx@...
Subject: Re: SPDX Agenda/Minutes
Hi Kim, Daniel,
Use case I'm worried about is how do we say what MUST be recognized
when all the licenses are on the web. What happens when we don't have
a stable base set of "must recognize" to conform.
If we make everything on the web, then the use case of including in
the spdx file, the full text of ALL licenses discovered (even if they
are ones that have a short form) - will conform to the specification.
Comparisons between analysis of the same package will become
"interesting".
Consider package "1" has licenses A, B, C, D in it. A, B, are on
the web site, C, D aren't. One analysis tool produces a file with
short form of A & B in the spec, C & D included verbatim. Another
analysis tool produces a file with A, B, C, & D included verbatim.
Both can be said to be SPDX 1.0, but if you compare both to each other,
you may not draw the conclusion that they are talking about the same
package.
On the other hand, I do understand the concern over not rev'ing the
spec too often to conform to license changes.
What do people think about the following for 1.0?
There is a base set of licenses, that MUST be recognized and
included as short forms, to conform, and they are captured in Appendix
I of the SPEC, as well as being on the web site. This gives the
potential for creating a spec which is all inclusive - full text of
licenses recognized as short forms, which others on the list have
indicated a need for. We include language in the spec, saying these
are the ones that MUST be recognized, but others on the website CAN be
recognized as well. When there is critical mass of changes to rev
the spec to 2.0; the set that is on the web site at that time, becomes
the MUST be recognized, and additions after that are CAN be recognized.
This avoids the point revision churn for licenses that John's afraid of,
allows an enforcement of a minimum set, and give a path to add new
licenses as they are nominated into the "active set".
Thoughts?
Kate
--- On Wed, 9/8/10, Kim Weins <kim.weins@...> wrote:
From: Kim Weins <kim.weins@...>
Subject: Re: SPDX Agenda/Minutes
To: "dmg" <dmg@...>, "Philip Odence" <podence@...>
Cc: "spdx@..." <spdx@...>
Date: Wednesday, September 8, 2010, 6:05 PM
I also agree that we should decouple
spec from licenses. We need a way to
add licenses without having to rev the spec.
Otherwise we will get lots of
spec revisions or very few license updates.
I know there has been some concern that if the list of
licenses is not
"fixed" with the spec version, you won't know what list of
licenses you need
to be able to "understand" when you get an SPDX file based
on a particular
version of the spec. I'd like to dig into this use case
more, since it seems
to me that any tooling or even manual review processes can
be designed to
just pull the latest and greatest version of licenses from
the website.
The only issue is that you may get an SPDX file that has
something marked as
an "Other" license that is now in the standard
license repo. That
shouldn't really be a problem, since all the "Other"
licenses will have full
license text in the SPDX file.
Here's an example:
Company A creates SPDX on 1/1/2011 using latest set of
standard licenses at
that point. They identify:
File A has Standard License A
File B has Standard License B
File C has Other License C
File D has Other License D
On 2/1/2011, License C is added to standard license repo
Company B reviews SPDX on 3/1/2011
All of the info is still valid -- since License C and D are
in the SPDX
file. Company B could choose to update the SPDX file
as:
File A has Standard License A
File B has Standard License B
File C now has STANDARD License C
File D has Other License D
Am I missing something here?
Kim
On Wed 9/8/10 12:48 PM, "dmg" <dmg@...>
wrote:
From the minutes:
Our implicit path had tied a fixed license list of licenses to the
spec rev, but JohnE put forth an impassioned argument as to why they
should be decouples...
I throw my support behind JohnE proposal. It addresses many of the
issues I have discussed before.
--dmg
(hopefully I can make wake up in time for the meeting, but it is tough
to only have 5 hrs of sleep :)
On Wed, Sep 8, 2010 at 11:24 AM, Philip Odence
<podence@...> wrote:
Per discussion late meeting, agendas will be going
out in bodies of emails
and minutes will go out as links to archive at
spdx.org.
I'll strive to get minutes out a week in advance,
though I'm behind this
time. Here's where they are posted (note that Kate
is still editing, so they
won't be final until tonight) http://www.spdx.org/wiki/minutes-
26aug2010
Meeting Time: Sept 9, 8am PDT / 10 am CDT / 11am
EDT / 16:00 GMT
Conf call dial-in:
NOTE: THIS NUMBER IS DIFFERENT FROM PAST NUMBERS
AND WILL BE CHANGING IN THE
FUTURE.
Conference code: 7812589502
Toll-free dial-in number (U.S. and
Canada): (877) 435-0230
International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of
toll free numbers can be
found: https://www.intercallonline.com/portlets/scheduling/viewNumbers/
viewNu
mber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF
Web:
Note, we will be using a different URL for each
meeting for purposes of
taking attendance. When you login please include
your full name and company
name, so I can just copy/pate into minutes. THX.
http://blackducksoftware.na6.acrobat.com/spdx9sept10/
Administrative Agenda
Attendance
Approval of minutes
Outreach and evangelism:
Common Messaging/Presentation PhilO
Industry Venues PhilR
Website PhilO/Martin
Roll Out Plans - KimW/JohnE
Action Items
Note: Drafting related action items are embedded
in
the Wiki. http://www.spdx.org/wiki/spdx/specification
€ PhilO/Martin - Update on participation page
where to join (suggestion was
to put link in text, not just at top, consider "I
want to use the spec, vs.
I want to contribute to the spec" in navigation
section.
€ Kate- Transfer document (.pdf) back to WIKI.
€ PhilO- Update standard presentation with
LinuxCon2010 input
€ Kate- Clean up the sharing analysis to what is
accurate.
€ Kate- Publish the current version number of
the specification in brackets
behind reference
€ Kim/PhilO- Add and element of 'What's in this
for me?" to presentation
€ JeffL (w/Bill/Gary- Update zlib based on new
specification
€ All- Look for new examples to add to site.
€ PhilK- Explore possibility of LF hosting
source for SPDX tools.
€ Gary- Explore other possible hosting options
€ PhilO- Start making minutes available via
link.
€ BillS- Start up RDF sub-group. Solicite
members.
Technical Agenda
SPEC - current status and open areas - Kate
RDF focus group - current status - Bill
Tools - update from Gary, and others.
L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502
podence@...
http://www.blackducksoftware.com
http://twitter.com/podence
http://www.linkedin.com/in/podence
http://www.networkworld.com/community/odence (my blog)
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
Kim Weins | Senior Vice President, Marketing
kim.weins@...
Follow me on Twitter @KimAtOpenLogic
650 279 0410 | cell
www.openlogic.com
Follow OpenLogic on Twitter @OpenLogic
OpenLogic, Inc.
Headquarters, Broomfield, Colorado
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx ===================================================================================================================================== This email and any attachments to it contain confidential information and are intended solely for the use of the individual to whom it is addressed.If you are not the intended recipient or receive it accidentally, please immediately notify the sender by e-mail and delete the message and any attachments from your computer system, and destroy all hard copies. If any, please be advised that any unauthorized disclosure, copying, distribution or any action taken or omitted in reliance on this, is illegal and prohibited. Furthermore, any views or opinions expressed are solely those of the author and do not represent those of ASUSTeK. Thank you for your cooperation. =====================================================================================================================================
|
|
|
hi Soeren On Thu, Sep 9, 2010 at 2:05 AM, <Soeren_Rabenstein@...> wrote: Dear All,
By uncoupling licenses and standard, I see a high risk, that we end up in many different quasi-sub-standards of spdx.
As in the example, what if several users of the license C and D give different license name tags to them, before they eventually get adopted by the license list?
One Spdx file says
1. Standard | License A
2. Standard | License B
3. Custom | License C (attached license text x)
4. Custom | License D (attached license text y)
Another one, describing the same package, says
1. Standard | License A
2. Standard | License B
3. Custom | License 3 (attached license text x)
4. Custom | License 4 (attached license text y)
And another spdx file, describing a DIFFERENT package says
1. Standard | License A
2. Standard | License B
3. Custom | License C (attached license text z)
4. Custom | License D (attached whatever)
I think for a version 1 this is a very acceptable outcome. The package is described in a very simple way. We know it has 4 licenses, they are all extracted and placed in a well defined "blurb". All a person (or more likely a tool) needs to do is parse the 4 blurbs. That is addresses one of the major problems of Ninka and Fossology want to address: to find the license. Sure the files will work on their own. But if I eventually want to update them all to the newest standard, I will end up in either a lot of mismatches, or in a lot of manual work; i.e. the very two things spdx shall avoid (in my understanding). The way I'd solve t is by allowing two types of license descriptor: 1. A text blurb that embeds the license (simple and straightforward) 2. A meta-license descriptor. A meta license descriptor is a URI (any URI, not only spdx, but spdx ones would be assumed to be widely known). The URI would indicate information such as: type of license (reference or inclusion), any variable parameters that need to be identified, any potential variability (such as known variations in spelling or punctuation). So we end with two standards: 1. Describing the licensing of the package (where a license is a URI described by the license spec, it does not list _any_ specific license) 2. The one describing the licenses form (which describes the forms that licenses take). This way the standards do not change when a new license is added. Finally, SPDX will publish a list of (accepted|approved|blessed|loved) licenses, including their URI. But others will be allowed to published their own URIs for licenses. This could be standard #3. The license describer could rather look like
DeclaredLicense = GPLv2
LicenseVariation = yes
VariationContents =
++ As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License.
++ However the source code for this file must still be made available in accordance with section (3) of the GNU General Public License.
++ This exception does not invalidate any other reasons why a work based on this file might be covered by the GNU General Public License. This is not a variant of the license, it is a different license. IMO, variants really the same license but have different text (diff would yield different results, I.e. British vs American spelling). Variants are usually by inclusion. --dmg
|
|
|
I have a thought that may help resolve.
In section 2 specify, in addition to the spec version, a license list version. So, to be compliant, an SPDX file MUST (Kate's emphasis) recognize all of the licenses in the license version list. In Kim's example, the SPDX file could be rev'ed to the new version of the list. So the 1/1/11 version of the file would be compatible with SPDX V1.0/License List V1.0 and the 3/1/11 would be compatible with SPDX V1.0/License List V1.1.
If someone was looking at two descriptions of the same package and there was a difference in the licenses, first thing they could do is check to see if both files used the same license list version.
Hi Kim, Daniel, Use case I'm worried about is how do we say what MUST be recognized when all the licenses are on the web. What happens when we don't have a stable base set of "must recognize" to conform. If we make everything on the web, then the use case of including in the spdx file, the full text of ALL licenses discovered (even if they are ones that have a short form) - will conform to the specification. Comparisons between analysis of the same package will become "interesting". Consider package "1" has licenses A, B, C, D in it. A, B, are on the web site, C, D aren't. One analysis tool produces a file with short form of A & B in the spec, C & D included verbatim. Another analysis tool produces a file with A, B, C, & D included verbatim. Both can be said to be SPDX 1.0, but if you compare both to each other, you may not draw the conclusion that they are talking about the same package. On the other hand, I do understand the concern over not rev'ing the spec too often to conform to license changes. What do people think about the following for 1.0? There is a base set of licenses, that MUST be recognized and included as short forms, to conform, and they are captured in Appendix I of the SPEC, as well as being on the web site. This gives the potential for creating a spec which is all inclusive - full text of licenses recognized as short forms, which others on the list have indicated a need for. We include language in the spec, saying these are the ones that MUST be recognized, but others on the website CAN be recognized as well. When there is critical mass of changes to rev the spec to 2.0; the set that is on the web site at that time, becomes the MUST be recognized, and additions after that are CAN be recognized. This avoids the point revision churn for licenses that John's afraid of, allows an enforcement of a minimum set, and give a path to add new licenses as they are nominated into the "active set". Thoughts? Kate --- On Wed, 9/8/10, Kim Weins < kim.weins@...> wrote: From: Kim Weins <kim.weins@...>
Subject: Re: SPDX Agenda/Minutes
To: "dmg" <dmg@...>, "Philip Odence" <podence@...>
Cc: "spdx@..." <spdx@...>
Date: Wednesday, September 8, 2010, 6:05 PM
I also agree that we should decouple
spec from licenses. We need a way to
add licenses without having to rev the spec.
Otherwise we will get lots of
spec revisions or very few license updates.
I know there has been some concern that if the list of
licenses is not
"fixed" with the spec version, you won't know what list of
licenses you need
to be able to "understand" when you get an SPDX file based
on a particular
version of the spec. I'd like to dig into this use case
more, since it seems
to me that any tooling or even manual review processes can
be designed to
just pull the latest and greatest version of licenses from
the website.
The only issue is that you may get an SPDX file that has
something marked as
an "Other" license that is now in the standard
license repo. That
shouldn't really be a problem, since all the "Other"
licenses will have full
license text in the SPDX file.
Here's an example:
Company A creates SPDX on 1/1/2011 using latest set of
standard licenses at
that point. They identify:
File A has Standard License A
File B has Standard License B
File C has Other License C
File D has Other License D
On 2/1/2011, License C is added to standard license repo
Company B reviews SPDX on 3/1/2011
All of the info is still valid -- since License C and D are
in the SPDX
file. Company B could choose to update the SPDX file
as:
File A has Standard License A
File B has Standard License B
File C now has STANDARD License C
File D has Other License D
Am I missing something here?
Kim
On Wed 9/8/10 12:48 PM, "dmg" <dmg@...>
wrote:
From the minutes:
Our implicit path had tied a fixed license list of
licenses to the
spec rev, but JohnE put forth an impassioned argument
as to why they
should be decouples...
I throw my support behind JohnE proposal. It addresses
many of the
issues I have discussed before.
--dmg
(hopefully I can make wake up in time for the meeting,
but it is tough
to only have 5 hrs of sleep :)
On Wed, Sep 8, 2010 at 11:24 AM, Philip Odence
<podence@...>
wrote:
Per discussion late meeting, agendas will be going
out in bodies of emails
and minutes will go out as links to archive at
spdx.org.
I'll strive to get minutes out a week in advance,
though I'm behind this
time. Here's where they are posted (note that Kate
is still editing, so they
won't be final until tonight) http://www.spdx.org/wiki/minutes-26aug2010
Meeting Time: Sept 9, 8am PDT / 10 am CDT / 11am
EDT / 16:00 GMT
Conf call dial-in:
NOTE: THIS NUMBER IS DIFFERENT FROM PAST NUMBERS
AND WILL BE CHANGING IN THE
FUTURE.
Conference code: 7812589502
Toll-free dial-in number (U.S. and
Canada): (877) 435-0230
International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of
toll free numbers can be
found: https://www.intercallonline.com/portlets/scheduling/viewNumbers/viewNu
mber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF
Web:
Note, we will be using a different URL for each
meeting for purposes of
taking attendance. When you login please include
your full name and company
name, so I can just copy/pate into minutes. THX.
http://blackducksoftware.na6.acrobat.com/spdx9sept10/
Administrative Agenda
Attendance
Approval of minutes
Outreach and evangelism:
Common Messaging/Presentation PhilO
Industry Venues PhilR
Website PhilO/Martin
Roll Out Plans - KimW/JohnE
Action Items
Note: Drafting related action items are embedded
in
the Wiki. http://www.spdx.org/wiki/spdx/specification
€ PhilO/Martin - Update on participation page
where to join (suggestion was
to put link in text, not just at top, consider "I
want to use the spec, vs.
I want to contribute to the spec" in navigation
section.
€ Kate- Transfer document (.pdf) back to WIKI.
€ PhilO- Update standard presentation with
LinuxCon2010 input
€ Kate- Clean up the sharing analysis to what is
accurate.
€ Kate- Publish the current version number of
the specification in brackets
behind reference
€ Kim/PhilO- Add and element of 'What's in this
for me?" to presentation
€ JeffL (w/Bill/Gary- Update zlib based on new
specification
€ All- Look for new examples to add to site.
€ PhilK- Explore possibility of LF hosting
source for SPDX tools.
€ Gary- Explore other possible hosting options
€ PhilO- Start making minutes available via
link.
€ BillS- Start up RDF sub-group. Solicite
members.
Technical Agenda
SPEC - current status and open areas - Kate
RDF focus group - current status - Bill
Tools - update from Gary, and others.
L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502
podence@...
http://www.blackducksoftware.com
http://twitter.com/podence
http://www.linkedin.com/in/podence
http://www.networkworld.com/community/odence (my blog)
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
Kim Weins | Senior Vice President, Marketing
kim.weins@...
Follow me on Twitter @KimAtOpenLogic
650 279 0410 | cell
www.openlogic.com
Follow OpenLogic on Twitter @OpenLogic
OpenLogic, Inc.
Headquarters, Broomfield, Colorado
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
