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

[Rick Moen]

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.