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

[Andrew C. Oliver]

I have made some minor stylistic changes to the below and added it here:

http://www.buni.org/mediawiki/index.php/GAP_Against#OSD_10_Interpretation

Hopefully that is okay with Larry, otherwise I ask his forgiveness and 
will remove it.
I think it adds to the position by explaining #10.

I deleted some of the stuff at the bottom because it is more relevant to 
whether OSD 10 should be changed or relaxed (which the board has not 
stated is up for consideration as part of the acceptance of the license, 
I feel that issue should be addressed separately if it is).

Lawrence Rosen wrote:
> Rick Moen wrote [about OSD #10]:
>   
>> That provision is _necessitated_ (and implied) by the right to fork and
>> to create derivative works and use them for any purpose, but OSI had
>> failed to realise it was necessary to say so in the OSD -- until the AAL
>> come along and made OSI realise that, yes, some people _do_ feel
>> impelled towards such goofy things.  Thus, it passed a new OSD provision
>> to say "No, we meant to say, you can't do that, either."
>>     
>
> That isn't historically correct.
>
> OSD #10 was written in response to something entirely different. There were
> attempts at that time to propose licenses that mandated "click-wrap" and
> similar "I accept the license" interfaces in distributed open source
> software. Much of the community thought it was unseemly to force a specific
> method of license acceptance onto future software distribution modes,
> specifically downstream derivative works that would have to retain
> technologically obsolete or interactive code for contract formation
> purposes. The OSI Board decided to foreclose such license provisions by
> adopting OSD #10. Thereafter, an open source license could require a
> "reasonable effort under the circumstances to obtain the express assent of
> recipients" (see AFL/OSL 3.0 § 9) but nothing more technologically specific.
>
> As with the Amendments to the U.S. Constitution, when you say something in
> the OSD you are bound to interpret that provision consistently when other
> newer technologies and facts come around. So if it was improper under OSD
> #10 for an open source license to mandate upon derivative works a technology
> of license assent (presumably to encourage people to do what's best to
> protect them legally, but that's not enough reason to tamper with freedom!),
> shouldn't it also be improper to mandate a technology for author
> attribution?
>
> There may also be another object lesson in here for attorneys proposing GAP.
> At the time of OSD #10, I was general counsel of OSI, and I simultaneously
> was leading the effort to allow open source licenses to mandate "click-wrap"
> because some licensors felt they needed the extra level of legal protection
> that contract formation brings. I was roundly Slash-dotted. The Board
> overrode my objections when they adopted OSD #10 and I, as their lawyer, did
> what my clients wanted. 
>
> By way of apology, I long ago realized the community was right and I was
> wrong. The general principle that today's technology shouldn't lock in the
> future is a sound one. The Board made the right decision when it adopted OSD
> #10. 
>
> We should not give up that principle lightly now that the GAP is before us.
> In particular, any specific technology mandated by a license for derivative
> works ought to be justified upon the strongest of grounds. I haven't heard
> that yet for GAP. 
>
> Business model success isn't, in my mind, those strong grounds. Remember
> that, regardless of what the OSI Board decides about the GAP, its licensors
> will remain free to distribute source code and to authorize their licensees
> to create free copies and derivative works--and free to demand certain
> attribution (or contract formation) procedures in derivative works. It
> simply won't be an OSI-approved license. It won't conform to OSD #10. It
> won't be open source software as we now define it.
>
> /Larry
>
>
>   
>> -----Original Message-----
>> From: Rick Moen [mailto:rick at linuxmafia.com]
>> Sent: Sunday, January 21, 2007 2:50 PM
>> To: license-discuss at opensource.org
>> Subject: Re: [Fwd: FW: For Approval: Generic Attribution Provision]
>>
>> Quoting Peter Kloprogge (Kloprogge at planet.nl):
>>
>>     
>>> Rick, you are confusing me.
>>> Below you mention that OSI should support mandated-advertising
>>> licenses.
>>>       
>> No, actually, I did not.
>>
>> I said that there is nothing _inherently_ wrong (for values of "wrong"
>> entailing contravening the letter or spirit of the OSD) with licences
>> that require -some- displayed advertising crediting the original
>> copyright holder.  It _should_ be possible, I think, to draft such a
>> licence that reasonable people consider not to violate OSD #6 by
>> substantively permitting full usage of the codebase for all purposes
>> especially including commerce by third parties.
>>
>> (I don't mean "permitting" only in the Ben Tilly sense of "They could if
>> they insisted, but nobody in his right mind wants to, but rather in the
>> commerce is truly and fully _not impaired_ sense.)
>>
>> It certainly doesn't follow that SPECIFIC extant mandated-advertising
>> licences meet that criterion -- or meet the others articulated in the
>> OSD.  In particular, it doesn't follow that SugarCRM's does, nor
>> MuleSource's, nor Socialtext's, etc.
>>
>>
>>     
>>> However, multiple times I've read comments originating from
>>> you (besides others) that looks at such licenses from the perspective
>>> of whether they aim to impair commerce.
>>>       
>> As mentioned, this concern is covered by OSD#6.
>>
>>     
>>> For me a key question is if trying to impair commerce is in itself a
>>> reason to not approve a license?
>>>       
>> Peter, we try to keep licence evaluations grounded in terms of
>> compliance with the OSD.  That is what is supposed to happen on this
>> mailing list and is its chartered purpose, as described on
>> http://www.opensource.org/docs/certification_mark.php#approval .  After
>> the user of a licence has submitted it for scrutiny to
>> license-approval at opensource.org, that user also sends a description of
>> the proposal here.  Discussion of the OSD merits (ideally) ensues.
>> Then, based in part on advice and analysis posted here, the OSI Board
>> decides to either certify or not certify the licence as OSD-compliant.
>>
>> Anyway, aside from procedural objections (i.e., a once third party
>> submitted one of Microsoft's licences, whereas submission would have to
>> come from Microsoft Corporation itself before the Board would spend time
>> considering it), the "reasons to not approve a licence" should always
>> refer to the OSD.
>>
>> (I've mentioned a procedural objection, recently:  Socialtext's "GAP" =
>> Generic Attribution Provision is described as "licence", but is not
>> that, but rather a one-paragraph patch that might be applied against
>> some unspecified subset of the 58 extant OSI-certified licences.
>> Socialtext's proposal is thus defective in that it failed to submit a
>> licence at all, as the procedure requires.)
>>
>>
>> There are times when the OSD has turned out to imperfectly reflect the
>> core commonsense notions of what open source _is_.  (I recently
>> summarised those notions as "the right to fork, the right to create and
>> redistribute derivative works under the same terms, the right to use
>> code for any purpose without fee or additional permissions".)  E.g.,
>> some period after OSI approved the AAL = Attribution Assurance License --
>> around which much recent advocacy rhetoric has centred (but which seems
>> almost completely unused) -- OSI realised belatedly the need for OSD
>> #10.  ("No provision of the license may be predicated on any individual
>> technology or style of interface.")
>>
>> That provision is _necessitated_ (and implied) by the right to fork and
>> to create derivative works and use them for any purpose, but OSI had
>> failed to realise it was necessary to say so in the OSD -- until the AAL
>> come along and made OSI realise that, yes, some people _do_ feel
>> impelled towards such goofy things.  Thus, it passed a new OSD provision
>> to say "No, we meant to say, you can't do that, either."
>>
>>
>>     
>>> If there is no restriction for anyone making use of the
>>> program (#6) but for some it will just be less attractive (and there
>>> could be hundreds of reasons why this is true), is it then still open
>>> source?
>>>       
>> OSD #6 doesn't address aspects of the software that make it "less
>> attractive for some".  It concerns _licensing_ of the software, not
>> the software itself, saying the licensing "must not restrict anyone from
>> making use of the program in a specific field of endeavor".  Note that
>> wording and the rationale (which stresses that, in particular, that the
>> aim is to exclude licenses that impair commercial use).  That wording
>> will be applied by the OSI Board to the facts at hand.
>>
>> Now, you speak, if I recall correctly, as a user of SugarCRM.  SugarCRM
>> has pointedly _not_ submitted its "SugarCRM Public Licence" MPL 1.1 +
>> Exhibit B badgeware licence for evaluation.  Nor have any of the other
>> 20-odd users of Exhibit B badgeware licences -- not even Alfresco, the
>> company of OSI Board member Matt Asay.
>>
>>
>>     
>>> Going through the website most arguments
>>> against Exhibit B licenses seem to be the notion of impairing
>>> commerce. These arguments even surfaced in this group in relation to
>>> the SocialText license and attribution in general. So it felt
>>> off-topic to discuss these licenses in relation to OSD#10.
>>>       
>> I think you somewhat misread.  OSD#10 is technological neutrality.
>>
>> Socialtext's failure to actually present a _licence_ -- not to mention
>> the fact that GAP isn't even written in coherent English sentences --
>> has caused more than a little confusion here, so you're not alone.  That
>> having been said, the failure of the score of companies in question,
>> including Socialtext itself and, well, SugarCRM, Alfresco, and others,
>> has caused somewhat more -- because, really, they're the real issue, and
>> GAP is just a trial balloon.
>>
>>     
>>> I understand the rationale of #10 but it feels like there is
>>> a dis-agreement on the more crucial issue of attribution in general.
>>>       
>> "Attribution" has proved to be a meaninglessly vague term --
>> encompassing both the BSD licensing clause that has been OSI approved
>> since Day One and a ludicrously obstructive badgeware requirement of 500
>> point company name and logo that could be mandated on derivative works
>> by MPL 1.1 + GAP.   It's much better to be specific, and say what you
>> really mean, instead.
>>     
>
>
>
>   


-- 
No PST Files Ever Again
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org