[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: License issues with metasploit-framework

On Tue, 18 Jul 2006 12:38:37 +0100 James Westby wrote:

> Hi, there is an open ITP on metasploit-framework (#323420), and the
> owner Luciano asked me to contact this list about some of the license
> issues involved with the package.

Hi, this is indeed the right list to contact.

> At the moment the framework is at version 2, and is released under a
> dual license of GPL v2 and Perl Artistic.

For all the parts that are actually under this dual licensing, that's

> There are a lot of contributed files in the package. Most have the
> following header
> ;        This file is part of the Metasploit Exploit Framework
> ;        and is subject to the same licenses and copyrights as
> ;        the rest of this package.

Seems more or less OK, even though having a clear copyright & permission
notice that explicitly refers to the dual GPLv2/Artistic would be much
better and safer. 

> and some have no license header.

These ones are concerning, especially if there is no other indication
that they really fall under the same licenses as the rest of the
I think that a clarification from upstream is needed.

> There are a few that say the
> following
> # This file is part of the Metasploit Framework and may be
> # redistributed according to the licenses defined in the Authors field
> # below. In the case of an unknown or missing license, this file
> # defaults to the same license as the core Framework (dual GPLv2 and
> # Artistic). The latest version of the Framework can always be
> # obtained from metasploit.com.

What does the "Authors field below" say?
Is there one?

If there is, then you (we) have to check whether it defines a licensing
scheme which is DFSG-free and compatible with the rest of the framework.

If there isn't, then it's more or less OK, with the above-mentioned
warning (being explicit would be far better).

> There is one with
>  * The contents of this file constitute Original Code as defined in
>  * and are subject to the Apple Public Source License Version 1.1 (the
>  * "License").  You may not use this file except in compliance with
>  * the License.  Please obtain a copy of the License at
>  * http://www.apple.com/publicsource and read it before using this
>  * file.
>  * This Original Code and all software distributed under the License
>  * are distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND,
>  * NON-INFRINGEMENT.  Please see the License for the specific language
>  * governing rights and limitations under the License.
> which the archives seem do suggest is not DFSG-free.

What was analysed on debian-legal was (at least) Apple's APSL v2.0:
definitely non-free (and GPLv2-incompatible).

This is APSL v1.1: I don't know if this version has ever been reviewed
on debian-legal.
If someone finds the time to look at it, it would be useful to assess
its DFSG-freeness and {GPLv2/Artistic}-compatibility.

If it's not {GPLv2/Artistic}-compatible, then upstream should be
persuaded to relicense or replace the file. Or possibly Debian can
substitute the file with a {GPLv2/Artistic}-compatible drop-in
replacement (if at all possible).

> There is a zlib implementation with the following license
> ===
> ===

This is actually the so-called zlib license: DFSG-free and
GPLv2-compatible, AFAICS.

> And my favourite
> # Yo yo, this be da socketNinja.
> # Alpha-2.0 release
> # Distribute and get a visit from tireIronNinja
> which I don't think is free.

It lacks (at least) permission to modify and distributed modified
versions (see DFSG#3).
It doesn't even clearly grant permission to distribute (see DFSG#1):
"Distribute" seems like an order, not a permission!
I don't understand the visit part...  :-/

Upstream should be contacted and asked to relicense this file.
Or, as usual, this file could be dropped or replaced.

> There are also binary files distributed in the tarball, these are not
> meant to be compiled, as they are for executing on the target
> computer. I'm not sure how this sits, as they are obviously not the
> preferred form of modification, and some don't include the source they
> were compiled from.

If the actual source for those binaries is not available, we are going
very far from DFSG compliance (see DFSG#2).
Upstream should be got in touch with and asked for source under
a DFSG-free and {GPLv2/Artistic}-compatible license.

Alternatively those binaries should be dropped or replaced.

> Now, we could contact upstream and get them to include proper headers
> etc., but I wanted to know how much of this was unsuitable for
> distribution, as if it leaves a severely crippled package then it's
> not really worth it.

It's up to you to decide whether it's worth fixing this melting pot of
copyrights and licenses.
Whatever you decide, thanks for contributing Debian.

> Also upstream are working on version 3 which is in alpha now. The
> decided to change the license to The Metasploit Framework License
> v1.0.
> http://www.metasploit.com/projects/Framework/msf3/download.html?Release=alpha-r3

Oh my goodness!
Another project that decides they need their own awkward and
incompatible license!

Writing a good license is a really hard task: it requires good lawyers
and a long revision process.  Worse, it can fail even with such things!
Moreover, even when you create a good license, license proliferation is
bad, since it creates barriers that obstruct free software sharing and

It would really be appreciated if you tried to persuade upstream to
adopt a well-established and clearly DFSG-free license, instead of
writing their own.

GNU GPLv2 is a good choice.
Even GPLv2/Artistic dual license is good.
Another good choice is the Expat license
(http://www.jclark.com/xml/copying.txt), if copyleft is not regarded as
an important goal.

> ===
> The Metasploit Framework License v1.0
> Copyright (C) 2006 Metasploit LLC
> ===
> The webpage requires a click through of this license to get the
> source.
> How does this license look? If it is DFSG-free, then the best option
> is probably to package this version.

I didn't find the time to thoroughly analyse the license, but I spotted
at least a choice of venue, which is non-free:

| Any
| litigation related to this License must be filed and heard in the
| courts for Travis County, Texas.

If I manage to review the license completely, I will send my analysis to
debian-legal only, because I don't think the BTS is the right place for
license analysis and discussion.
When a conclusion is reached a link to the list archives can be sent as
a followup for the bug report...

> Apologies for dumping everything here, but I want to be clear about
> the legal issues before proceeding.

Pasting the full text of licenses and unclear copyright & permission
notices is the recommended method to get advice from debian-legal, hence
I think you did nothing wrong.

> Thanks,

You're welcome!

    :-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
  Francesco Poli                             GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4

Attachment: pgpbMMA5Reniv.pgp
Description: PGP signature

Reply to: