[Fwd: FW: For Approval: Generic Attribution Provision]

Sat Jan 20 23:00:48 UTC 2007

Andrew Oliver wrote:
> Has anyone written Mr. Mayfield with suggested improvements to the
> language of his license?  It would be nice to have an up or down vote on
> the substance rather than the structural problems of the license
> provision.  I have a draft of how I wish it was written (clarity-wise),
> but if others agree this is a good course of action I would prefer it be
> reviewed first.

While there are risks to any committee-drafted provision, and this
discussion list isn't a committee anyway, I do believe there is merit to
Andrew's suggestion.

I'm loathe to commit myself quite yet to either the pro- or con-GAP camp for
a number of reasons, including that the language before us doesn't actually
parse. But the main reasons I don't want to vote now is that I'm in favor of
reasonable attribution requirements, just not the specific ones I've seen so
far. (Honestly, FWIW if a vote were taken now, I'd vote "NO.")

So is there a middle ground? Will an attempt to draft a middle-ground be
more productive than categorizing ourselves as either "yeah" or "nay" on
what's before us?

/Larry Rosen

> -----Original Message-----
> From: Andrew C. Oliver [mailto:acoliver at buni.org]
> Sent: Saturday, January 20, 2007 2:37 PM
> To: license-discuss at opensource.org
> Subject: Re: [Fwd: FW: For Approval: Generic Attribution Provision]
> 
> Okay baring that (and I agree it is a stretch) then I don't really see a
> #6.
> I still think you missed the crux of my argument (that logos have value
> where
> works cited type attribution does not).  I'd like to see (I realize I
> may have to wait
> since it is the weekend) some others sound off on whether they could
> join a #6
> argument (and reach a consensus as to which one).  If not then I don't
> think it should go in the paper
> (http://www.buni.org/mediawiki/index.php/GAP_Against), but might be
> attached as a minority report.  My comments are restricted to the
> socialtext GAP license.
> 
> Has anyone written Mr. Mayfield with suggested improvements to the
> language of his license?  It would be nice to have an up or down vote on
> the substance rather than the structural problems of the license
> provision.  I have a draft of how I wish it was written (clarity-wise),
> but if others agree this is a good course of action I would prefer it be
> reviewed first.
> 
> -Andy
> 
> Rick Moen wrote:
> > Quoting Andrew C. Oliver (acoliver at buni.org):
> >
> >
> >> I guess my objective is to boil the arguments down to their metal ATM.
> >>
> >> I started out disagreeing with this #6 argument, but now can be
> >> convinced of this for completely different reasons.  I feel that some
> of
> >> the reasoning is flawed, I don't think THIS license (as I read its
> >> intent structural issues aside) makes business use impossible to the
> >> extent that it would violate #6.
> >>
> >
> > Depends on which "this" licence, I think.  As a reminder, my reply to
> > Ben Tilly concerned MuleSource's MPL 1.1 + "Exhibit B" badgeware
> > licence -- which is one of the particularly bad ones.  It did not
> > address Socialtext's Generic Attribution Provision patch paragraph.
> >
> > (Which, again, I will point out, is simply _not a licence_.  If
> > compatible with open source at all, whether GAP passes OSD muster might
> > well depend on which of OSI's 58 approved licences it's applied against.
> > Which presumably is part of why OSI requires submission of entire
> > licences, and resubmission of changed licences, in the process at
> > http://www.opensource.org/docs/certification_mark.php#approval that
> > Socialtext ignored.)
> >
> >
> >
> >> Here is my #6 and possibly #1 argument
> >>
> >> Doesn't brand logo display probably have a real monetary value?
> >>
> >
> > Logo economic value doesn't in itself have relevance to OSD-compliance.
> > When I participated in making the Linuxcare Bootable Business Card, it
> > resulted in my name being in the credits displayed in the disk contents,
> > which probably had non-zero economic value to me in the long term -- but
> > made zero difference as to whether the contents are open source or not.
> >
> > However, let's see where you're going with this:
> >
> > [...]
> >
> >> However, there is a practical problem.  Depending on the size and
> >> message contained in the logo -- it COULD run afoul:
> >>
> >> 1. "This software is supported by clubbing baby seals" with a
> cartoonish
> >> display of a baby seal being clubbed... would probably prevent the
> >> sierra club and others from using my software.
> >>
> >> 2. "Hummer drivers all will burn in hell" with a caricature of a hummer
> >> driver on fire -- would prevent Hummer, athiests groups and other
> groups
> >> from using the software.
> >>
> >> 3. An inordinately LARGE logo could be of monetary value and could make
> >> the software impractical to use in business even if only on the splash
> >> screen.
> >>
> >
> > Yes, quite.  Getting back to the GAP paragraph (as opposed to
> > MuleSource's "Exhibit B" licence), the copyright holder's ability to
> > mandate a "display" of arbitrary size and logo contents, which must be
> > preserved indefinitely by downstream users, means it can functionally
> > bar any (or most) competing commercial use.  (Ben Tilly would say this
> > means merely that competitors "are ALLOWED to use the software; they
> > just don't WANT to" -- which I call sham reasoning.)
> >
> >
> >> If these are valid arguments then you have to then accept the
> >> impracticality of any logo attribution license unless OSI is going to
> >> get in the business of evaluating each logo itself to see if when used
> >> it runs afoul of the OSD...unless you believe in "self-policing" ;-)
> >>
> >
> > Well, this is perhaps excessively pessimistic.  Imagine a logo
> > requirement for an original copyright holder logo + company name + URL
> > not to exceed 120 by 120 pixels that must be on an "About" screen for
> > any derivative that has a user interface.
> >
> > Now, users of that licence who abuse it to mandate obscene or disruptive
> > logos or company names or URLs would be being jackasses and injuring
> > their works' reuse prospects but not preventing the licence from being
> > used for open source.  (It's always been easy to abuse open source
> > licences in a way that results in proprietary or otherwise impaired
> > code.  Consider for example declaring that a binary codebase is
> > BSD-licensed, but never getting around to issuing source code.  That
> > code remains proprietary, even though the licence is not.)
> >
> >
> 
> 
> --
> No PST Files Ever Again
> Buni Meldware Communication Suite
> Email, Calendaring, ease of configuration/administration
> http://buni.org