From:	Charles Bailey	Date:	Fri Apr 28 17:45:45 2006
Subject:	Re: Does masquerading conflict with artistic control?

On 4/28/06, Allison Randal <allison@wgz.org> wrote:
>
> On Apr 26, 2006, at 21:45, Charles Bailey wrote:
>
> > In reading the new draft of the AL, I'm struck by the potential of
> > section 4 (and by extension 5) to support ham-handed or malicious
> > replacement of the Standard Version.  As I read it, a Modified Version
> > may replace the Standard Version on a system as long as the author of
> > the MV makes the changes available to the author of the SV, whether or
> > not the SV's author wants them.  As a concrete example, one might
> > distribute a version of Perl that sends a copy of the process
> > environment (or /etc/passwd, or name-your-favorite-local-info) to the
> > distributor prior to executing the task it was invoked to perform.  It
> > would be legitimate under 4(a) to replace the default Perl
> > installation on the system with this "modified" version, as long as
> > you sent Larry Wall a patch which would cause the standard Perl to
> > send you this info as well.
>
> Potentially, yes, though once they've given their complete source
> code to Larry/TPF under the Artistic License we can publicly reveal
> exactly what they've done. No one would choose to install such code
> once they're aware of what it's doing.


For the subset of people paying attention, I agree.  For the cases where
it's buried in a larger installation, or the user's consent to the
installation is questionable (e.g. adware), perhaps not.  I was thinking
that there's often enough weasel room in "user consent", "permitted access"
and the like to give the Black Hats cover; it'd be nice to have a licensing
hook to deny them use of your tool for evil purposes.  Possibly too
proactive, but para 13 got me to thinking about the possible role of a
license in promoting the author's notion of good social behavior.

If someone were maliciously installing hacked versions of Perl on
> people's machines against their will, that would fall into a
> completely different legal category, and isn't something for a
> license to address.


IANAL, but I don't think this is necessarily true.  If you click 'OK' when
the Sony DRM installer asks, the fact that it sneaks in a buggy rootkit
doesn't put it into a different legal category than if it installed a
well-designed userspace agent.  (Well, there's the negligence issue, but I'm
not sure to what standard the author is held, especially with the typical
disclaimers of warranty.)

These things said, I really don't want to make a big issue of this.  I'd
wondered whether there was some utility to building into the license some
notion that the Package's author had some say over what other works could
represent themselves as the Package.  The current effect of the AL is that
the author has no say.  That's a defensible point, and maybe even a basic
tenet of "free" software.  Just musing . . .


> ... but the potential for
> > (at least reputational)  harm to the original author and the SV seem
> > substantial.
>
> Other legal tools are helpful too, such as the Perl trademark to
> identify versions of Perl that are sufficiently Perl-ish. (This one
> definitely would not be.)


Er, I got sort of lost here.  Since the AL explicitly grants anyone the
right to distribute the Package, as long as they say they're doing it, and
implicitly (by making 4(b) one of several options) grants the right to
represent whatever you distribute as the Package, I'm not sure how trademark
helps you.  At one level, can you grant someone the right to distribute the
Package named Perl but deny them the right to refer to it as Perl?  (Yes,
this depends on how they refer to it: information is different from
advertising, for instance.)  At another level, I doubt trademark use impacts
much on what happens when you type C<perl> on the command line.

> P.S. One other <nit type="trivial">If you disclaim implied warranty,
> > why not expressed?</nit>  I guess one can claim that "express
> > warranty" is now a term of art.
>
> If you include every possible warranty disclaimer, it could run for
> several pages. You have to draw the line somewhere, and this one fell
> on the "unlikely to apply" side.



I got lost here too.  My only point was that the warranty the AL presumably
meant to disclaim was an "expressed" warranty (i.e. one stated), rather than
an "express" warranty (i.e. a quick one).  The error is so common, though,
that I expect "express warranty" is now considered as a term of art
identical in meaning to "expressed warranty".  Again, a trivium.

To the extent that this is useful discussion, thanks for replying.  To the
extent that it's soaking up time revisiting settled issues, feel free to
devnull it.

--
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu