I gathered the license information for the Perl modules downloaded and installed by install_perl_libs.pl and added this information to README. Two of the modules use LGPL. The others use the Artistic License or GPL. It would be great if someone could go through them and double check.

There was one module (Digest-HMAC) which I couldn't find the license for. The Digest-HMAC module was a dependency for the Authen-SASL 2.12 module. The Digest-HMAC module no longer appears to be a dependency for Authen-SASL 2.13. I updated the Authen-SASL URL to fetch version 2.13 and removed Digest-HMAC from install_perl_libs.pl and README.

I added code to install_perl_libs.pl which requires the user to enter 'YES' the script will install and download the modules. The following is displayed:

=====================================================================
*** NOTICE ***

This script will download and install Perl modules distributed under
the following licenses:
- The "Artistic License"
- GNU General Public License (GPL)
- GNU Library or "Lesser" General Public License (LGPL)

See the README file for more information.
=====================================================================
Type YES to proceed, type NO to abort:


Regarding the Microsoft artifacts, the instructions direct the person installing the management node to the URL of the page where the supplemental utilities can be obtained. These are not direct download links. Can the responsibility to read the license terms provided by the 3rd party be left to the person downloading the files?

Thanks,
Andy



Andy Kurth wrote:
I will look up the licenses of the modules the install_perl_libs.pl script downloads/installs and include a disclaimer when the script is executed. I will add the license information to the list of prerequisites in README. Will this be sufficient?

-Andy

Kevan Miller wrote:

On Oct 23, 2009, at 10:36 PM, Josh Thompson wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri October 23 2009 4:45:26 pm Kevan Miller wrote:
On Oct 21, 2009, at 1:27 PM, Josh Thompson wrote:
(Question to mentors: Do I need to vote in a successive email in
this thread,
or is this post an implicit vote?)

You should either include an explicit +1 in the initial vote email, or
"reply" in another email. Either is acceptable. I kind of prefer a
separate email, but that's just me...

Okay - since I didn't include and explicit +1 in the initial message, I'll do
it here.

+1

Most votes will include a formal statement on what the vote is about.
E.g.:

[ ] +1 yes, release VCL 2.1
[ ] 0 dunno
[ ] -1 no, don't release VCL 2.1 (provide reasons).

Now that you mention it, I remember seeing that in some places. Somehow, I came up with an example email calling for a vote that I linked to off of this
page:

http://cwiki.apache.org/confluence/display/VCL/VCL+Release+Procedures

direct link to email:

http://mail-archives.apache.org/mod_mbox/stdcxx-dev/200601.mbox/%3c43c1c0a0.7040...@roguewave.com%3e

That email doesn't include what you mentioned. I'll revise the release docs
to explain that part should be in there and maybe find a better example
email.

This is the strangest Apache "release" that I've ever seen... Taking
some getting used to... I have some questions/comments. Haven't
decided on my vote, yet.

Since this is the only Apache "release" those of us from NCSU have ever seen, can you explain further why you say it is so strange? I thought the release procedures page followed the suggested guidelines pretty well. I'm assuming the items listed below aren't explaining that but are points you think need
addressing before finalizing a release.

It's "strange" to me, because I typically assume there is a binary build, in addition to the source. Installation seems pretty involved. I'm just going to be *reading* the installation steps, not actually following them...


* web/.ht-inc/conf.php contains references to Shibboleth and UNC. I
assume that's holdover from VCL's origins.

I left it in there as an example of how Shibboleth authentication would be added in. It is commented out, but I can completely remove it if you think
it is confusing.

It's fine, I think...


* Instructions on installation, prereqs, etc should be clear that a
user must determine the licensing of the technologies that you are
requiring/referring to/downloading. It's not clear to me if that
information is being conveyed. Clearly, you require GPL, LGPL, and
microsoft proprietary artifacts. Wondering how much of this needs to
flow through legal-discuss... Prolly Alan and Matt have thought about
this already.

The web frontend only requires dojo to be installed. It is Apache Licensed. The licensing for JPGraph is explained in the INSTALLATION file as well as the fact that it is not needed. There are several options on how you use VCL, and therefore what external software is needed for use by the backend. I'll defer to Aaron and Andy to answer this point further since the backend
is not my area of focus.

* managementnode/bin/install_perl_libs.pl will download install
libraries, IIUC. What are the licenses of these artifacts? Users need
to be made aware of what you are doing for them...

So, my concern is that we're clear about the licensing implications of VCL. If VCL automatically downloads some set of libraries, then users need to be made aware of the licensing implications...

--kevan




--
Andy Kurth
Virtual Computing Lab
Office of Information Technology
North Carolina State University
andy_ku...@ncsu.edu
919.513.4090

Reply via email to