For Approval: Common Public Attribution License (CPAL)

[Matthew Flaschen]

Ross Mayfield wrote:

>> I see no evidence that anyone considered such OSD #10 issues while APL
>> was under consideration. Really, it doesn't look like the license was 
>> thoughtfully considered at all.
> 
> I think that different individuals have different views about the
> approved OSI licenses. Russ has his opinion on APL, but others may
> have a different opinion.

That is true, but Russ was around for the deliberations (such as there
were) of APL, and you and I were not.

> For example, many  commentators have been very critical about the GPL.

Nonetheless, it's probably the most used license in the world, while the
APL is extremely unpopular.

> I don't understand your basis for the statement that the APL was not thoughtfully considered.

Reading the archives.  It is most obvious from "Unfortunately, even
after two tries there have been insufficient comments on the Adaptive
Public License.  Maybe the third's the charm?" at
http://www.mail-archive.com/license-discuss@opensource.org/msg07431.html
.  It was then discussed on the list for about a week, then it seems to
have been put on the backburner until it was recommended by Russ for
approval in December 2004
(http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:9268:apdpdalipapaedpgofih)
.  Note that both of the comments Russ linked are from April 2004, and
the resubmission was in May 2004.


However, it would be better to hear from someone who was there for the
process.

> Your view of OSD 10 is simply not correct. The record would not
> reflect consideration of attribution notices and OSD 10,

I see no evidence anyone considered #OSD 10 in relation to the APL at all.

> because OSD 10 did not address attribution notices.

OSD #10 says, "No provision of the license may be predicated on any
individual technology or style of interface."  It obviously does not
explicitly mention this kind of attribution, but that hardly means it's
irrelevant.

> As Larry Rosen, the General
> Counsel of the OSI at the time, noted in a January email about OSD 10
> on this issue:
> 
> "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.

It was written in response to click-wrap.  However, it was not written
to be specific to click-wrap.  Rather, it determined what the problem
was (click-wrap clauses limited flexibility in technology and
interface), and decided such constraints were generally unacceptable.

>> The GPL does have a runtime attribution requirement (2.c), but this
>> doesn't require a graphic image, URL, or arbitrary phrase.  It also
>> doesn't specify form or require prominence.  The interface of GPL
>> software (if that clause is taken advantage of) need only have
>> summarized copyright and warranty information, with options for the user
>> to view details if they want to.
> 
> The point is that prominent used in a wide variety of OSI licenses
> without problem. The use of prominent to refer to notices in the files
> is not analytically different from its use on an interface.  You are
> not correct about GPLv3

I didn't mention GPLv3 mainly because it isn't OSI-approved, though I
hope it will be.  GPLv3 7.b. allows restrictions "requiring preservation
of specified reasonable legal notices or author attributions in that
material or in the Appropriate Legal Notices displayed by works
containing it"
> The attribution information is only limited to "reasonable" author
attribution and they do not exclude graphics.

Reasonable's the key word, isn't it...  It means "unreasonable" author
attribution requirements can be removed (because "All other
non-permissive additional terms are considered "further restrictions"
within the meaning of section 10. If the Program as you received it, or
any part of it, purports to be governed by this License, supplemented by
a term that is a further restriction, you may remove that term.").

Whether a required graphic is reasonable under GPLv3 is debatable, but I
think not given how interface-neutral the "Appropriate Legal Notices"
requirement is.  Several people, including me, have also commented that
7.b may be too broad.  In three days, the final license will come out,
and we will see whether this wording survives.

>> This definition is subjective (doesn't "sufficient duration" depend on
>> vision, age, attention, etc.) and at the least, could eventually result
>> in a profusion of attribution, slowing the splash screen into a
>> slideshow.
>> This is an OSD #3 problem, since it constrains practical modification.
> 
> The issue that you raised is whether "prominent" was too vague. We
> were pointing that "prominent" is widely used in other OSI approved
> licenses and has not been a problem. We agree that the notice
> requirements are different.

It's true that "prominent" hasn't been an issue in these other licenses.
 However, I think the term is much more important in yours.  This is
because it refers to runtime attribution, and because CAPL's definition
of prominent would require that multiple attributions have be equal
prominence (which does not have a precedent).

> I am puzzled by your concern about "sufficient duration" since we were 
> trying to clarify the requirement to meet your concerns.

It's vague, but Rick is right that this may be necessary.  However, the
real issue is when you have to display a dozen logos equally prominently
for sufficient duration.  This is what I am worried about.

> We agree with Rick Moen on this issue. Please
> note that the OSI website has a graphic and phrase relating to the
> Creative Commons license very similar to our proposal on every page.

I know this is just an analogy, but the website is under only one
license; in fact, it used to be under two, but it was changed to CC for
some reason (probably to simplify).  CAPL could require an arbitrary
number of different attributions if many CAPL programs were merged into
a Larger Work (or even a single program).

> Your premise is incorrect. The OSD is not limited to guaranteeing
> rights to users

I think it is, when you understand that companies and developers
redistributing and modifying software are also users.  It was never
designed to serve the needs of the initial developer (except when they
later become a user of modified versions of their software).

> I appreciate your view of the market, but I would like to understand
> the factual basis for it.

My observation of MediaWiki, Firefox, and other programs.  Firefox
actually demands you remove branding if you make any changes.
Nonetheless, most users of IceWeasel and BurningDog know it's based on
Firefox.

 I am running a software company and my
> experience is that, without attribution,  "everyone" will not know who
> made our software.

I said everyone would know who made SocialText Wiki, and that most
people would know that forks were based of SocialText (but consider
whether forks will be significant if you use a license like "Open
Software License" that requires providing source code for network
communication)

> OSI is effective because its decisions are based on
> the realities of the industry.

Maybe, but the OSD is certainly not based on "the realities of the
industry".  It is based on the Debian Free Software Guidelines; DFSG
dates back to before there was a substantial open source industry, when
it was drafted to specify essential user freedoms.

> I am working to make Socialtext available to the community every day 
> and I know that I need this flexibility.

Maybe so, but that doesn't mean it is necessarily open source.

> We respect OSI and its process: we have worked with License Discuss
for over eight months and have
> made numerous changes to our proposed license. I hope that OSI will
> show similar respect for our experience and needs.

I'll finish by making concrete suggestions again.  Removing the "graphic
image" allowance (and perhaps changing "graphic user interface" to "user
interface") should solve the OSD #10 issue.

The OSD #3 issue is more serious, and I don't see how you could
eliminate it entirely.  However, if you remove the option to have
attribution apply to the Larger Work, that should limit the number of
attributions that could apply at one time.

Matt Flaschen