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

[Andrew C. Oliver]

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