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
