Subject: RE: [Fwd: FW: For Approval: Generic Attribution Provision]
From: "Lawrence Rosen" <>
Date: Sun, 21 Jan 2007 18:18:18 -0800

 Sun, 21 Jan 2007 18:18:18 -0800
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

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

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.


> -----Original Message-----
> From: Rick Moen []
> Sent: Sunday, January 21, 2007 2:50 PM
> To:
> Subject: Re: [Fwd: FW: For Approval: Generic Attribution Provision]
> Quoting Peter Kloprogge (
> > 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
> mark.php#approval .  After
> the user of a licence has submitted it for scrutiny to
>, 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.