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

[Christian Maletz]

Andrew C. Oliver schrieb:
> 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.
>>>     
>>
>>
>>
>>   
>
>




	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de