Date   

Re: Agenda for Aug 26 meeting

Clow, Marshall <mclow@...>
 

On Aug 25, 2010, at 6:52 AM, Philip Odence wrote:
Attached is the agenda. I've called out the logistical info separately.
I won't be attending this week, due to a conflict.

See you at the next meeting.

-- Marshall


Re: Agenda for Aug 26 meeting

Philip Odence
 

Forgot attachment.


Agenda for Aug 26 meeting

Philip Odence
 

Attached is the agenda. I've called out the logistical info separately.

Note: We are in flux with dial in numbers, so please check every time.

and Note: I am experimenting with using the Web log in to take attendance, so please plan to log in.

Meeting Time

Aug 26, 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. - http://blackducksoftware.na6.acrobat.com/spdxaug26/



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


Re: fossbazaar wiki and LinuxCon followup

Tom "spot" Callaway
 

On 08/24/2010 05:17 PM, Martin Michlmayr wrote:
* Tom spot Callaway <tcallawa@...> [2010-08-24 21:09]:
I should have left the answer to tbm who set it up.
Fair enough. :)

I'm still hopeful that there is some wiki intelligence in addition to
Drupal already present, and if not, I can make the case for us to move
to mediawiki. ;)
Bob's right. We're using Drupal and the Drupal wiki module.

What functionality do you need that's currently not there?
Well, there are a few things:

1. New page creation is really awkward.
2. There is no native wiki link syntax, so I would end up making a lot
of long URLs that aren't useful.
3. There is no native wiki section syntax, so I'd have to write a lot
more html than I'd prefer.
4. There is no wiki syntax for embedding one page in another. so I can't
really do what I've done in the mockup that I made on fedoraproject.org
(see my original email).
5. There are no default target mappings to sections (see #3), so I'd
have to hardcode them.

Drupal is a great CMS, but it is not such a great wiki.

~tom


Re: fossbazaar wiki and LinuxCon followup

Martin Michlmayr
 

* Tom spot Callaway <tcallawa@...> [2010-08-24 21:09]:
I should have left the answer to tbm who set it up.
Fair enough. :)

I'm still hopeful that there is some wiki intelligence in addition to
Drupal already present, and if not, I can make the case for us to move
to mediawiki. ;)
Bob's right. We're using Drupal and the Drupal wiki module.

What functionality do you need that's currently not there?
--
Martin Michlmayr
Open Source Program Office, Hewlett-Packard


Re: fossbazaar wiki and LinuxCon followup

Tom "spot" Callaway
 

On 08/24/2010 04:37 PM, Bob Gobeille wrote:

On Aug 24, 2010, at 2:20 PM, Tom spot Callaway wrote:

On 08/24/2010 04:12 PM, Bob Gobeille wrote:
Drupal
Drupal isn't really a wiki, it's a CMS. That distinction is important
here, because it means we can't do anything besides basic HTML.
I realized you would say this right after I hit send. I was thinking there was a drupal wiki module. But the only thing I see is:
http://www.interestingto.me.uk/DrupalWikiModule

I should have left the answer to tbm who set it up.
Fair enough. :)

I'm still hopeful that there is some wiki intelligence in addition to
Drupal already present, and if not, I can make the case for us to move
to mediawiki. ;)

~tom


Re: fossbazaar wiki and LinuxCon followup

Bob Gobeille
 

On Aug 24, 2010, at 2:20 PM, Tom spot Callaway wrote:

On 08/24/2010 04:12 PM, Bob Gobeille wrote:
Drupal
Drupal isn't really a wiki, it's a CMS. That distinction is important
here, because it means we can't do anything besides basic HTML.
I realized you would say this right after I hit send. I was thinking there was a drupal wiki module. But the only thing I see is:
http://www.interestingto.me.uk/DrupalWikiModule

I should have left the answer to tbm who set it up.

bobg


Re: fossbazaar wiki and LinuxCon followup

Tom "spot" Callaway
 

On 08/24/2010 04:12 PM, Bob Gobeille wrote:
Drupal
Drupal isn't really a wiki, it's a CMS. That distinction is important
here, because it means we can't do anything besides basic HTML.

~spot


Re: fossbazaar wiki and LinuxCon followup

Bob Gobeille
 

Drupal

On Aug 24, 2010, at 12:24 PM, Tom spot Callaway wrote:

Just out of curiousity, what kind of wiki is FOSSBazaar using? It
doesn't seem very full featured, so a lot of what I discussed doing at
LinuxCon is going to be much more complicated.


fossbazaar wiki and LinuxCon followup

Tom "spot" Callaway
 

Just out of curiousity, what kind of wiki is FOSSBazaar using? It
doesn't seem very full featured, so a lot of what I discussed doing at
LinuxCon is going to be much more complicated.

However, assuming that the wiki technology we use is flexible, I went
ahead and implemented a very rough (and incomplete mockup) on the Fedora
wiki (we're using mediawiki, which I know is capable of doing everything
I'd described).

Please take a look at it and let me know if it is something interesting
to the group.

https://fedoraproject.org/wiki/TomCallaway/SPDX_License_List

I put some notes there as well to explain things. If you have questions,
hit me. :)

~tom


Re: Examples

Philip Odence
 

Peter,
The examples you cite are, as you speculated, out of date. We need to create some current ones. 
Getting the site up and running before LinuxCon was a bit of a scramble, though Martin did a great job getting it to the point of credibility, albeit with some holes. 
We'll be back on our biweekly meeting schedule starting a week from today.
Phil


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

On Aug 18, 2010, at 7:45 PM, Peter Williams wrote:

Hi all,

While looking at the draft spec, i noticed that the specification
examples page, <http://spdx.org/spec/examples>, is empty.  However,
there do seem to be some examples at
<https://fossbazaar.org/wiki/spdx/examples>.  Is this just a case of
some missing links?  Or are the examples on the wiki out-of-date?

If those examples are up-to-date it would definitely ease understanding
the spec.

Peter Williams
<http://www.openlogic.com>
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx


Examples

Peter Williams <peter.williams@...>
 

Hi all,

While looking at the draft spec, i noticed that the specification examples page, <http://spdx.org/spec/examples>, is empty. However, there do seem to be some examples at <https://fossbazaar.org/wiki/spdx/examples>. Is this just a case of some missing links? Or are the examples on the wiki out-of-date?

If those examples are up-to-date it would definitely ease understanding the spec.

Peter Williams
<http://www.openlogic.com>


Next Call

Philip Odence
 

Sorry about any confusion. As per the minutes of the 7/29 meeting, no meeting today. Next meeting is normal time, two weeks from today.


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


Re: Hello world and additional licenses

Philip Odence
 

Yes, that's clearly the tradeoff, Soeren. I think the question is how "expensive" it is to add licenses to the list and maintain them. I suspect that as with the spec, we'll have a working area for candidate licenses and a process for promoting to the official list. 

We had some in person discussion about this at the LinuxCon BoF session last night and it was clear that this subject needs more discussion and work. Thanks for joining in and shining some light on it.



On Aug 11, 2010, at 7:44 AM, <Soeren_Rabenstein@...> <Soeren_Rabenstein@...> wrote:

Hi Phil
 
Wouldn’t it make sense to include as many licenses as possible? (except maybe the very strange ones)
Sure this will all more data to the specification. But limiting the specification may bloat Software BOMs with license texts (which would be required to be included under spdx, as I understand it).
 
If you want to limit the covered licenses, I still definitely would vote for including
·         Ruby
·         Xfree
·         RhEcos and Ecos (the old version eCos is still surprisingly often present in embedded devices, regardless of the fact that RedHat dropped the project long time ago)
·         OSSL
·         OLDAP-2.8
 
Cheers
 
Soeren
 
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Philip Odence
Sent: Wednesday, August 11, 2010 6:33 PM
To: Soeren Rabenstein(Soeren Rabenstein, II.M.)
Cc: spdx@...
Subject: Re: Hello world and additional licenses
 
Welcome, Soeren. Glad to have you aboard. 
 
This is certainly fair discussion. The goal has been to have the standard license list cover a large majority of cases (Kate's been talking about 90% coverage). Beyond that we have provided a mechanism for including licenses that are not on the list, the main differences being that for the latter the user will include the text of the license in the SPDX file, not just a reference to our list. 
 
So, that fact that you have run across a license in your work would not on the face say that it meets the criteria for being included on the list. Do you think the licenses you list are fairly common and would belong on the list for that reason? Or do you think our criteria are too tight and that we should try to be more comprehensive in our coverage?
 

Phil

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
 
On Aug 11, 2010, at 2:30 AM, <Soeren_Rabenstein@...> wrote:


Hello spdx mailing list

I guess I am the first new subscriber, since you went public?
My name is Soeren Rabenstein, I am in ASUSTeK's legal department since early 2009 and responsible for European legal compliance as well as implementation of a FOSS license compliance program.

Thank you for creating the specification. We are very interested in bringing forward the standard, since "Software-BOMs" form a key element of our compliance program (we actually switched to the term "BOC"="Bill of Code", to avoid confusion with actual, physical BOMs) and supply chain management turned out to be the biggest challenge over here.

As a first contribution, I compared the list of specified licenses in the spdx-draft with my own approval list. As a result I would like to propose the following licenses to be added to spdx. With the exception of the last item, these are all licenses I came across during my practice. I may add them myself through the wiki, but currently I cannot see a working wiki page on this.
I am also happy to dig our more licenses that are not yet listed.


License Identifier: ClArtistic
Formal Name: Clarified Artistic License 1.0
URL: http://www.ncftp.com/ncftp/doc/LICENSE.txt 

License Identifier: XFree86-1.1
Formal Name: XFree86 License 1.1
URL: http://www.xfree86.org/current/LICENSE4.html 

License Identifier: Ruby
Formal Name: Ruby License
URL: http://www.ruby-lang.org/en/LICENSE.txt 

License Identifier: RHeCos
Formal Name: Red Hat eCos Public License v1.1
URL: http://ecos.sourceware.org/old-license.html 

License Identifier: eCos
Formal Name: The eCos license version 2.0
URL: http://www.gnu.org/licenses/ecos-license.html 

License Identifier: OSSL
Formal Name: OpenSSL License
URL: ? (No direct web source known, license text therefore attached to this mail)

License Identifier: ErlPL
Formal Name: Erlang Public License Version 1.1
URL: http://www.erlang.org/EPLICENSE 

License Identifier: gsoPL
Formal Name: gSOAP Public License Version 1.3b
URL: http://www.cs.fsu.edu/~engelen/license.html

License Identifier: SugPL
Formal Name: SugarCRM Public License
URL: http://www.sugarcrm.com/crm/SPL

License Identifier: YPL
Formal Name: Yahoo! Public License 1.1
URL: http://www.zimbra.com/license/yahoo_public_license_1.1.html 

License Identifier: OLDAP-2.8
Formal Name: OpenLDAP Public License Version 2.8
URL: http://www.openldap.org/software/release/license.html 

License Identifier: ZimPL
Formal Name: Zimbra Public License, Version 1.3
URL: http://www.zimbra.com/license/zimbra-public-license-1-3.html 


...AND OF COURSE ;)

License Identifier: WTFPL
Formal Name: Do What The Fuck You Want To Public License
URL: http://sam.zoy.org/wtfpl/ 


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@...
____________________________________________________________



=====================================================================================================================================
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.
=====================================================================================================================================
<OpenSSL-License.txt><ATT00001..c>
 
=====================================================================================================================================
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.
=====================================================================================================================================


Re: Pretty printer binaries available

Gary O'Neall
 

Thanks Bill for the reply.

Sorry - I sent out the wrong username - it's spdx@.... Give
that a try and let me know if you have any problems.

Gary

On Wed, 11 Aug 2010 15:12:29 -0400, Bill Schineller
<bschineller@...> wrote:
Thanks Gary - thrilled that you contributed our first tool.
Although I explicitly specified ssl/tls, port 21, and accepted
certificate, seems to be rejecting the password spdx1 for user spdx

re:"With respect to some of your earlier questions,
* License Names and Pretty Printing - I was only able to extract
the URL for the license (as a resource) from the SPDX document which
doesn't lead to a very pretty license name. Should we add a property
License Name? Should I parse the URL and only print out the tag (e.g.
after the #)?"

---> I'd like to go with parsing the URL and printing out the tag (after
the #).

We ought to have an RDF document on our site for each license, and the
License Name is a property of each license.

re: "Namespace and tags - I noticed in the example we have only one
namespace for SPDX and the tags used in the example did not match the
tags
in the specification in all cases - e.g. License in the file is tagged
FileLicense in the example. Do we want to have separate namespaces for
File, License, and Document? If not, do we want the tags to be unique
(e.g. FileLicense and PackageLicense)? Technically, the tags don't
need
to be unique, but it may aid in humans reading the RDF/XML file."

---> I think it's ok to adopt in the RDF the non-unique (shorter) tags
as
in the specification. On one of the calls, the vibe from the group was
for the shorter tags. (e.g. 'License', not 'FileLicense'). Unfortunately
I
never sent around a new example incorporating that feedback (by then the
zilb example was making the rounds). I think it is acceptable and
correct
to keep it in the same namespace.

- Bill

On 8/10/10 11:19 PM, "Gary O'Neall" <gary@...> wrote:

I uploaded the pretty printer java program to the source auditor ftp
server. It's a secure web server, so I apologize in advance if it's a
bit
inconvenient to download.

The ftp server is at ftp.sourceauditor.com <ftp://ftp.sourceauditor.com>
You need to use explicit tls/ssl over port 21. Logon with user spdx and
password spdx1

The file SPDXPretty.zip contains the files mentioned in the previous
email
(copied below).

Let me know if you need more information or if you have any problems.

Gary



From: package-facts-bounces@...
[mailto:package-facts-bounces@...] On Behalf Of Gary O'Neall
Sent: Sunday, August 08, 2010 11:32 PM
To: package-facts@...
Subject: Java Pretty Printer

I completed an "alpha" version of a Java based pretty printer. It's
10MB
in binary form with its dependencies. Is there a place on the Wiki I
can
upload this to? I tried to add it to a page as an attachment to a new
discussion page, but the .zip filetype was not allowed. Please advise
on
the best method to get this to the group.

Attached is a modified zlib example (see notes below on what items were
changed) and an example output.

Below is some information and discussion points related to the pretty
printer development:

I'm sure there are a few improvements to be made before calling this a
"release", but it does provide some formatting and works for the zlib
example. I would appreciate any feedback once you have access to the
application.

To run the application, make sure you have a JRE 1.6 installed (JRE
version 1.5 may work, but it untested). Unzip the files in your
favorite
directory. Execute the jar file with a single text parameter of a file
path for the SPDX RDF Document.

On windows, this would be "java -jar SPDXPretty.jar
examples\zlib-1.2.5.spdxv3.rdf (assuming you copied the attached example
file into the same directory as the .jar file and your cd'd to that
directory).

I made a few changes to the zlib example to bring it up to date to the
draft 20100731. It is in the zip file in the examples directory.

I run into a few questions/issues as I implemented this, outlined below:

* Namespace and tags - I noticed in the example we have only one
namespace for SPDX and the tags used in the example did not match the
tags
in the specification in all cases - e.g. License in the file is tagged
FileLicense in the example. Do we want to have separate namespaces for
File, License, and Document? If not, do we want the tags to be unique
(e.g. FileLicense and PackageLicense)? Technically, the tags don't
need
to be unique, but it may aid in humans reading the RDF/XML file.

* I changed the tags in the example to match the document in
cases
where they were still unique (e.g. ShortDescription -> ShortDesc)

* License Names and Pretty Printing - I was only able to extract
the URL for the license (as a resource) from the SPDX document which
doesn't lead to a very pretty license name. Should we add a property
License Name? Should I parse the URL and only print out the tag (e.g.
after the #)?

* Example use of hasFile - In the example, the object of the
hasFile predicate for the package subject all have the same URI. I
believe
these should be unique since they represent different file objects. I
changed the example to make these individual and unique.

* The disjunctive licenses are implemented but not tested.

* There has not been much testing (Unit or otherwise)


I would like to make the code available as an open source project. It
is
written using Jena (http://jena.sourceforge.net/) and contains a Java
class
which is a model basically wrapping a Jenna model of the RDF document.
It
would probably be useful for many of you who are writing tools.

I could post the code to SPDX, but I would rather maintain it in a
repository which supports svn. I'm thinking Google code may be a good
location. Open to suggestions.

As far a licenses, it's currently under a 3 clause BSD since it's GPL
compatible and simple. I'm open to other licenses, so let me know if
you
have a preference - we could even create a nice complex set of license
choices ;) Do keep in mind this is dependent on Jena which is licensed
under a 3 clause BSD and contains some Apache licensed code.

Appreciate any comments.

Best regards,

Gary O'Neall
Source Auditor Inc.







Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com


Re: Pretty printer binaries available

Bill Schineller
 

Thanks Gary – thrilled that you contributed our first tool.
Although I explicitly specified ssl/tls, port 21, and accepted certificate, seems to be rejecting the password spdx1  for user spdx

re:”With respect to some of your earlier questions,
·        License Names and Pretty Printing – I was only able to extract the URL for the license (as a resource) from the SPDX document which doesn’t lead to a very pretty license name.  Should we add a property License Name?  Should I parse the URL and only print out the tag (e.g. after the #)?”

---> I’d like to go with parsing the URL and printing out the tag (after the #).    

We ought to have an RDF document on our site for each license, and the License Name is a property of each license.

re: “Namespace and tags – I noticed in the example we have only one namespace for SPDX and the tags used in the example did not match the tags in the specification in all cases  - e.g. License in the file is tagged FileLicense in the example.  Do we want to have separate namespaces for File, License, and Document?  If not, do we want the tags to be unique (e.g. FileLicense and PackageLicense)?   Technically, the tags don’t need to be unique, but it may aid in humans reading the RDF/XML file.”

---> I think it’s ok to adopt in the RDF  the non-unique (shorter) tags as in the specification.   On one of the calls, the vibe from the group was for the shorter tags. (e.g. ‘License’, not ‘FileLicense’). Unfortunately I never sent around a new example incorporating that feedback (by then the zilb example was making the rounds). I think it is acceptable and correct to keep it in the same namespace.

- Bill

On 8/10/10 11:19 PM, "Gary O'Neall" <gary@...> wrote:

I uploaded the pretty printer java program to the source auditor ftp server.  It’s a secure web server, so I apologize in advance if it’s a bit inconvenient to download.
 
The ftp server is at ftp.sourceauditor.com <ftp://ftp.sourceauditor.com>   You need to use explicit tls/ssl over port 21.  Logon with user spdx and password spdx1
 
The file SPDXPretty.zip contains the files mentioned in the previous email (copied below).
 
Let me know if you need more information or if you have any problems.
 
Gary

 

From: package-facts-bounces@... [mailto:package-facts-bounces@...] On Behalf Of Gary O'Neall
Sent: Sunday, August 08, 2010 11:32 PM
To: package-facts@...
Subject: Java Pretty Printer

I completed an “alpha” version of a Java based pretty printer.  It’s 10MB in binary form with its dependencies.  Is there a place on the Wiki I can upload this to?  I tried to add it to a page as an attachment to a new discussion page, but the .zip filetype was not allowed.  Please advise on the best method to get this to the group.
 
Attached is a modified zlib example (see notes below on what items were changed) and an example output.
 
Below is some information and discussion points related to the pretty printer development:
 
I’m sure there are a few improvements to be made before calling this a “release”, but it  does provide some formatting and works for the zlib example.  I would appreciate any feedback once you have access to the application.
 
To run the application, make sure you have a JRE 1.6 installed (JRE version 1.5 may work, but it untested).  Unzip the files in your favorite directory.  Execute the jar file with a single text parameter of a file path for the SPDX RDF Document.
 
On windows, this would be “java –jar SPDXPretty.jar examples\zlib-1.2.5.spdxv3.rdf (assuming you copied the attached example file into the same directory as the .jar file and your cd’d to that directory).
 
I made a few changes to the zlib example to bring it up to date to the draft 20100731.  It is in the zip file in the examples directory.
 
I run into a few questions/issues as I implemented this, outlined below:
 
·        Namespace and tags – I noticed in the example we have only one namespace for SPDX and the tags used in the example did not match the tags in the specification in all cases  - e.g. License in the file is tagged FileLicense in the example.  Do we want to have separate namespaces for File, License, and Document?  If not, do we want the tags to be unique (e.g. FileLicense and PackageLicense)?   Technically, the tags don’t need to be unique, but it may aid in humans reading the RDF/XML file.

·        I changed the tags in the example to match the document in cases where they were still unique (e.g. ShortDescription -> ShortDesc)

·        License Names and Pretty Printing – I was only able to extract the URL for the license (as a resource) from the SPDX document which doesn’t lead to a very pretty license name.  Should we add a property License Name?  Should I parse the URL and only print out the tag (e.g. after the #)?

·        Example use of hasFile – In the example, the object of the hasFile predicate for the package subject all have the same URI.  I believe these should be unique since they represent different file objects.  I changed the example to make these individual and unique.

·        The disjunctive licenses are implemented but not tested.

·        There has not been much testing (Unit or otherwise)

 
I would like to make the code available as an open source project.  It is written using Jena (http://jena.sourceforge.net/) and contains a Java class which is a model basically wrapping a Jenna model of the RDF document.  It would probably be useful for many of you who are writing tools.  
 
I could post the code to SPDX, but I would rather maintain it in a repository which supports svn.  I’m thinking Google code may be a good location.  Open to suggestions.
 
As far a licenses, it’s currently under a 3 clause BSD since it’s GPL compatible and simple.  I’m open to other licenses, so let me know if you have a preference – we could even create a nice complex set of license choices ;)  Do keep in mind this is dependent on Jena which is licensed under a 3 clause BSD and contains some Apache licensed code.
 
Appreciate any comments.
 
Best regards,
 
Gary O’Neall
Source Auditor Inc.
 
 
 
 
 


Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com


Re: Hello world and additional licenses

dmg
 

Kate was right, I should have gone l,to LinuxConf

in the same line as Richard comment, why not include every license
found in the Linux kernel?

I am sure many of you have customers that need this data for the kernel


in fact, last week I discuss that the kernel is a very good exercise
to test the spec
much better than simple examples. If it can do the kernel, it could do
almost anything


---dmg

On 8/11/10, Richard Fontana <rfontana@...> wrote:
On Wed, Aug 11, 2010 at 06:33:01AM -0400, Philip Odence wrote:
So, that fact that you have run across a license in your work would not on
the
face say that it meets the criteria for being included on the list. Do you
think the licenses you list are fairly common and would belong on the list
for
that reason?
Hi,

(First, happy to join this list after attending the LinuxCon session
yesterday.)

Of the ones Soeren listed, the OpenSSL license (or, I guess,
conjunction-of-licenses) stands out to me as one of the most commonly
encountered (it is not 'common' in the sense of being reused by
different projects, but because of the ubiquity of OpenSSL). Although
this may not bear on criteria for list inclusion, it is also a license
that often leads to angst for Linux distributions because of GPL
incompatibility arguments and the presence of an advertising clause.

- Richard


Richard E. Fontana
Open Source Licensing and Patent Counsel
Red Hat, Inc.
direct: +1 978 392 2423
mobile: +1 978 397 1504
fax: +1 978 392 1001
mail: rfontana@...
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx

--
--dmg

---
Daniel M. German
http://turingmachine.org


Re: Hello world and additional licenses

Richard Fontana
 

On Wed, Aug 11, 2010 at 06:33:01AM -0400, Philip Odence wrote:
So, that fact that you have run across a license in your work would not on the
face say that it meets the criteria for being included on the list. Do you
think the licenses you list are fairly common and would belong on the list for
that reason?
Hi,

(First, happy to join this list after attending the LinuxCon session
yesterday.)

Of the ones Soeren listed, the OpenSSL license (or, I guess,
conjunction-of-licenses) stands out to me as one of the most commonly
encountered (it is not 'common' in the sense of being reused by
different projects, but because of the ubiquity of OpenSSL). Although
this may not bear on criteria for list inclusion, it is also a license
that often leads to angst for Linux distributions because of GPL
incompatibility arguments and the presence of an advertising clause.

- Richard


Richard E. Fontana
Open Source Licensing and Patent Counsel
Red Hat, Inc.
direct: +1 978 392 2423
mobile: +1 978 397 1504
fax: +1 978 392 1001
mail: rfontana@...


Re: Hello world and additional licenses

kate.stewart@...
 

Hi Soren,
    Welcome.    Glad to have your input  :)      

   Wiki version of spec needs to be refreshed to correspond to the latest draft, and I'll try to work on it this weekend.   If anyone else has time before,  just let me know and I'll bounce you the raw doc file. 

    Can definitely add the licenses you list immediately below (I agree about eCOS - saw it alot), and if the others you sent earlier are commonly being encountered in analysis - then yes they should be included. Will add the short list below to the next draft, at least, and based on others input we can figure out what to do with the others ( how common is the WTFPL?  ;) ).  

   There's 1900+ licenses out there, and we're just trying to keep the tracking of licenses to a reasonable level.   Thoughts on criteria to be listed are it must be present in significant number of packages already or strategic (ie. new one, anticipated to be present).   What defines "significant" is a good topic for the next call on Aug 26th.  

Kate
 

--- On Wed, 8/11/10, Soeren_Rabenstein@... <Soeren_Rabenstein@...> wrote:

From: Soeren_Rabenstein@... <Soeren_Rabenstein@...>
Subject: RE: Hello world and additional licenses
To: podence@...
Cc: spdx@...
Date: Wednesday, August 11, 2010, 6:44 AM

Hi Phil

 

Wouldn’t it make sense to include as many licenses as possible? (except maybe the very strange ones)

Sure this will all more data to the specification. But limiting the specification may bloat Software BOMs with license texts (which would be required to be included under spdx, as I understand it).

 

If you want to limit the covered licenses, I still definitely would vote for including

·         Ruby

·         Xfree

·         RhEcos and Ecos (the old version eCos is still surprisingly often present in embedded devices, regardless of the fact that RedHat dropped the project long time ago)

·         OSSL

·         OLDAP-2.8

 

Cheers

 

Soeren

 

From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Philip Odence
Sent: Wednesday, August 11, 2010 6:33 PM
To: Soeren Rabenstein(Soeren Rabenstein, II.M.)
Cc: spdx@...
Subject: Re: Hello world and additional licenses

 

Welcome, Soeren. Glad to have you aboard. 

 

This is certainly fair discussion. The goal has been to have the standard license list cover a large majority of cases (Kate's been talking about 90% coverage). Beyond that we have provided a mechanism for including licenses that are not on the list, the main differences being that for the latter the user will include the text of the license in the SPDX file, not just a reference to our list. 

 

So, that fact that you have run across a license in your work would not on the face say that it meets the criteria for being included on the list. Do you think the licenses you list are fairly common and would belong on the list for that reason? Or do you think our criteria are too tight and that we should try to be more comprehensive in our coverage?

 

Phil

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

 

On Aug 11, 2010, at 2:30 AM, <Soeren_Rabenstein@...> wrote:



Hello spdx mailing list

I guess I am the first new subscriber, since you went public?
My name is Soeren Rabenstein, I am in ASUSTeK's legal department since early 2009 and responsible for European legal compliance as well as implementation of a FOSS license compliance program.

Thank you for creating the specification. We are very interested in bringing forward the standard, since "Software-BOMs" form a key element of our compliance program (we actually switched to the term "BOC"="Bill of Code", to avoid confusion with actual, physical BOMs) and supply chain management turned out to be the biggest challenge over here.

As a first contribution, I compared the list of specified licenses in the spdx-draft with my own approval list. As a result I would like to propose the following licenses to be added to spdx. With the exception of the last item, these are all licenses I came across during my practice. I may add them myself through the wiki, but currently I cannot see a working wiki page on this.
I am also happy to dig our more licenses that are not yet listed.


License Identifier: ClArtistic
Formal Name: Clarified Artistic License 1.0
URL: http://www.ncftp.com/ncftp/doc/LICENSE.txt

License Identifier: XFree86-1.1
Formal Name: XFree86 License 1.1
URL: http://www.xfree86.org/current/LICENSE4.html

License Identifier: Ruby
Formal Name: Ruby License
URL: http://www.ruby-lang.org/en/LICENSE.txt

License Identifier: RHeCos
Formal Name: Red Hat eCos Public License v1.1
URL: http://ecos.sourceware.org/old-license.html

License Identifier: eCos
Formal Name: The eCos license version 2.0
URL: http://www.gnu.org/licenses/ecos-license.html

License Identifier: OSSL
Formal Name: OpenSSL License
URL: ? (No direct web source known, license text therefore attached to this mail)

License Identifier: ErlPL
Formal Name: Erlang Public License Version 1.1
URL: http://www.erlang.org/EPLICENSE

License Identifier: gsoPL
Formal Name: gSOAP Public License Version 1.3b
URL: http://www.cs.fsu.edu/~engelen/license.html

License Identifier: SugPL
Formal Name: SugarCRM Public License
URL: http://www.sugarcrm.com/crm/SPL

License Identifier: YPL
Formal Name: Yahoo! Public License 1.1
URL: http://www.zimbra.com/license/yahoo_public_license_1.1.html

License Identifier: OLDAP-2.8
Formal Name: OpenLDAP Public License Version 2.8
URL: http://www.openldap.org/software/release/license.html

License Identifier: ZimPL
Formal Name: Zimbra Public License, Version 1.3
URL: http://www.zimbra.com/license/zimbra-public-license-1-3.html


...AND OF COURSE ;)

License Identifier: WTFPL
Formal Name: Do What The Fuck You Want To Public License
URL: http://sam.zoy.org/wtfpl/


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@...
____________________________________________________________



=====================================================================================================================================
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.
=====================================================================================================================================
<OpenSSL-License.txt><ATT00001..c>

 

=====================================================================================================================================
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.
=====================================================================================================================================

-----Inline Attachment Follows-----

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


Re: Hello world and additional licenses

Soeren_Rabenstein@...
 

Hi Phil

 

Wouldn’t it make sense to include as many licenses as possible? (except maybe the very strange ones)

Sure this will all more data to the specification. But limiting the specification may bloat Software BOMs with license texts (which would be required to be included under spdx, as I understand it).

 

If you want to limit the covered licenses, I still definitely would vote for including

·         Ruby

·         Xfree

·         RhEcos and Ecos (the old version eCos is still surprisingly often present in embedded devices, regardless of the fact that RedHat dropped the project long time ago)

·         OSSL

·         OLDAP-2.8

 

Cheers

 

Soeren

 

From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Philip Odence

Sent: Wednesday, August 11, 2010 6:33 PM
To: Soeren Rabenstein(Soeren Rabenstein, II.M.)
Cc: spdx@...
Subject: Re: Hello world and additional licenses

 

Welcome, Soeren. Glad to have you aboard. 

 

This is certainly fair discussion. The goal has been to have the standard license list cover a large majority of cases (Kate's been talking about 90% coverage). Beyond that we have provided a mechanism for including licenses that are not on the list, the main differences being that for the latter the user will include the text of the license in the SPDX file, not just a reference to our list. 

 

So, that fact that you have run across a license in your work would not on the face say that it meets the criteria for being included on the list. Do you think the licenses you list are fairly common and would belong on the list for that reason? Or do you think our criteria are too tight and that we should try to be more comprehensive in our coverage?

 

Phil

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

 

On Aug 11, 2010, at 2:30 AM, <Soeren_Rabenstein@...> wrote:



Hello spdx mailing list

I guess I am the first new subscriber, since you went public?
My name is Soeren Rabenstein, I am in ASUSTeK's legal department since early 2009 and responsible for European legal compliance as well as implementation of a FOSS license compliance program.

Thank you for creating the specification. We are very interested in bringing forward the standard, since "Software-BOMs" form a key element of our compliance program (we actually switched to the term "BOC"="Bill of Code", to avoid confusion with actual, physical BOMs) and supply chain management turned out to be the biggest challenge over here.

As a first contribution, I compared the list of specified licenses in the spdx-draft with my own approval list. As a result I would like to propose the following licenses to be added to spdx. With the exception of the last item, these are all licenses I came across during my practice. I may add them myself through the wiki, but currently I cannot see a working wiki page on this.
I am also happy to dig our more licenses that are not yet listed.


License Identifier: ClArtistic
Formal Name: Clarified Artistic License 1.0
URL: http://www.ncftp.com/ncftp/doc/LICENSE.txt

License Identifier: XFree86-1.1
Formal Name: XFree86 License 1.1
URL: http://www.xfree86.org/current/LICENSE4.html

License Identifier: Ruby
Formal Name: Ruby License
URL: http://www.ruby-lang.org/en/LICENSE.txt

License Identifier: RHeCos
Formal Name: Red Hat eCos Public License v1.1
URL: http://ecos.sourceware.org/old-license.html

License Identifier: eCos
Formal Name: The eCos license version 2.0
URL: http://www.gnu.org/licenses/ecos-license.html

License Identifier: OSSL
Formal Name: OpenSSL License
URL: ? (No direct web source known, license text therefore attached to this mail)

License Identifier: ErlPL
Formal Name: Erlang Public License Version 1.1
URL: http://www.erlang.org/EPLICENSE

License Identifier: gsoPL
Formal Name: gSOAP Public License Version 1.3b
URL: http://www.cs.fsu.edu/~engelen/license.html

License Identifier: SugPL
Formal Name: SugarCRM Public License
URL: http://www.sugarcrm.com/crm/SPL

License Identifier: YPL
Formal Name: Yahoo! Public License 1.1
URL: http://www.zimbra.com/license/yahoo_public_license_1.1.html

License Identifier: OLDAP-2.8
Formal Name: OpenLDAP Public License Version 2.8
URL: http://www.openldap.org/software/release/license.html

License Identifier: ZimPL
Formal Name: Zimbra Public License, Version 1.3
URL: http://www.zimbra.com/license/zimbra-public-license-1-3.html


...AND OF COURSE ;)

License Identifier: WTFPL
Formal Name: Do What The Fuck You Want To Public License
URL: http://sam.zoy.org/wtfpl/


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@...
____________________________________________________________



=====================================================================================================================================
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.
=====================================================================================================================================
<OpenSSL-License.txt><ATT00001..c>

 

=====================================================================================================================================
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.
=====================================================================================================================================

1561 - 1580 of 1589