For Approval: Generic Attribution Provision

Wed Nov 29 08:18:15 UTC 2006

On Mon, 2006-11-27 at 18:48 -0800, Ross Mayfield wrote:

> Socialtext which wishes to find a resolution for the attribution issue
> through the proposal of a Generic Attribution Provision.  A copy of
> the following message is available in HTML format here:
> https://www.socialtext.net/stoss/index.cgi?attribution_memo
> 
> I look forward to the conversation,

Ross, as I commented on a ZDNet thread, you've earned my respect (not
that it matters) by bringing your license to OSI and having a real
discussion about UI attribution.  I'm one of the critics of UI
attribution licenses, but I'm glad someone brought it to place where
forced UI attribution can be vetted to OSD in a reasonable manner.  I do
hope you receive the criticism of this provision in that light.

> needs than Linux. These application products could be "lost" in the
> larger distributions. The obligations imposed by the attribution

I'm uncertain why copyleft licenses don't meet the needs for "avoiding
larger distrib hiding" without compensation.  Where does a license like
the GPL not suit your needs?  If people are hiding it in their
distributions will GPL (even with FOSS exception) not meet your needs?

> provision are very similar to the reproduction of legal notices which
> are found in virtually all open source licenses.

Attribution in documentation, source, and a splash screen at startup (to
date approvals) are not "very similar" to a required use of a trademark
that is not owned by the person fulfilling their obligations.  Redhat
has sent letters to downstream vendors clearing stating their rights to
not have their trademarks used.  They are quite different (more below). 

> However, we understand that attribution may cause problems for OSI,
> particularly since different companies may have different attribution
> notices and may use different "base" licenses (all recent attribution
> agreements are based on the MPL).. Socialtext would like to suggest
> that OSI consider an "attribution" provision which can be used for any
> "modifiable" license.

I think if an attribution provision, limited to be reasonable and in
line with previous approvals (docs, splash page, etc) would not be
detrimental to the open source effect.  I think having it as a general
provision would be beneficial in license proliferation and remove
objections from these companies just writing their own licenses willy
nilly.

> Generic Attribution Provision
> 
> Redistributions of the [original code] in binary form or source code
> form, must ensure that each time the resulting executable program, a
> display of the same size as found in the [original code] released by
> the original licensor (e.g., splash screen or banner text) of the
> original licensor's attribution information, which includes:
> 
> (a) Company Name
> (b) Logo (if any) and
> (c) URLs 
> 

IMHO this allows exactly the problem with the current Mozilla Exhibit B
going around.  This provision allows a "blank check" because HOW the
original code attributes determines how prominent or  onerous it is.
I'm not a player in this (ie, OSI board) but I've suggested alternative
language below that would limit to more common and appropriate
attribution locations.  This is similar to what MOST people do currently
(in Documentation, About Page if present, etc).  Common places to
acknowledge the work that contribute to the whole application.  Remember
the open source effect is TRYING to make multiple open source projects
open for reuse in subsequent applications NOT limit those uses.

> 					POSITION STATEMENT
> 
> 	1.	Consistent with OSD.  Attribution is merely a form of notice which
> is consistent with Section 4, the Integrity of the Author's Source
> Code, of the Open Source Definition. Virtually every OSI approved
> license requires the inclusion of copyright and other legal notices
> (and frequently more elaborate information, see below). The
> attribution requirement is similar to this notice requirement.

They're similar in that they are both attribution, but they are quite
dissimilar in their burden.  Let's be clear: there is a BIG difference
between a note in a splash screen, document and a badge (amount many) on
EACH UI screen.  

Consider other attribution circumstances: The artist that samples
(perhaps even with payment) a Beatles song attributes the original
copyright and work in a page inside the CD.  Or the inside CD cover,
or ... The attribution clause proposed this would require the new artist
to place Powered by the Beatles(tm) on EVERY customer facing "screen"
such as concert posters, CD covers, websites, etc.

> Rationale: Encouraging lots of improvement is a good thing, but users
> have a right to know who is responsible for the software they are
> using. Authors and maintainers have reciprocal right to know what

Let's say we're in perfect agreement that no one should try and hide the
source of the source, but should users be required to know the hundred
or so names of developers that contributed to the Apache web server when
they go to a website?  Should someone claim they wrote it?  No.  Should
someone remove license copyright notices?  No.

> they're being asked to support and protect their reputations.
> Accordingly, an open-source license must guarantee that source be
> readily available, but may require that it be distributed as pristine
> base sources plus patches. In this way, "unofficial" changes can be
> made available but readily distinguished from the base source.

I don't think the source is an issue, is it?  I'm not sure anyone is
saying that there should be no attribution in source files.

> 	2.	Already Approved.  OSI has approved several licenses which include
> attribution, Attribution Assurance License, Open Source License and
> the Adaptive Public License, as consistent with the Open Source
> Definition.

I wasn't around for the rationale but I'm guessing they were limited
enough in scope, as to not limit rights but rather provide modest
attribution in appropriate "give credit where credit is due" places.  I
don't think they intended approving attribution to dictate a visual logo
(advertisement) on EVERY UI screen.  Perhaps others can revisit this for
the benefit of everyone?

> 2.  Redistributions of the Code in binary form must be accompanied by
> this GPG-signed text in any documentation and, each time the resulting
> executable program or a program dependent thereon is launched, a
> prominent display (e.g., splash screen or banner text) of the Author's
> attribution information, which includes:
> (a) Name ("AUTHOR"),
> (b) Professional identification ("PROFESSIONAL IDENTIFICATION"), and
> (c) URL ("URL").

Notice it says launched.  ie, notice of copyright NOT a UI banner on
each screen.

> 	3.  Not a Burdensome Requirement.   Some individuals have expressed
> concern that attribution requirements will result in products where
> the screens are filled with logos. Yet, by their nature, licenses with
> attribution will only permit the original licensor to include its logo
> since the license cannot be amended by sublicensors. Many open source

Are you saying that multiple UI attribution license can not be
combined?  

If they can be combined the UI filled with badges could be VERY real if
enough people use badgeware.  Certainly many of the badgeware
applications would look different if the open source projects they used
had the same requirement.  I counted 18 for Sugar; a testament to how
good open source projects can benefit everyone.  How many OSI approve
licenses does SocialText use?  If you send me the list of the projects
SocialText used I'm happy to create a mockup of YOUR UI if we live in a
badgeware world.  You can see what the commercial viability of your
software would be if those that came before believe they deserved this
same right.  Do you have an splash screen or an about page for every END
USER of SocialText listing all the COPYRIGHT holders you've used?
Remember open source projects often have MULTIPLE Copyright holders that
might have different attribution clauses.  Joe Jimmy from Jersey and
Susy Soody from Sarasota could probably have their picture included.

If they can not be combined (can you explain what you mean if I've
misunderstood) then that seems to be in conflict with OSD; and VERY much
against the open source effect.  Open Source strives to make it easy for
people to reuse code; increases quality and decreases duplicate work.
Not being able to combine two licenses that are both OSI approved would
be, well, very odd.

> 	4.  Applications.  The needs of "application" open source software
> are different from the more traditional "operating system" open source
> software. Application software is frequently distributed by third
> parties with other products without any notice to end users; this

I would venture to say that infrastructure OS is more commonly
distributed then applications.  

By different are you really saying better?  Somehow because you are
writing code that is geared more towards end users it is worth MORE
protection and recognition then everyone else?  For instance, the ~7500
lines of code that make "grep" that are used ubiquitously and with great
utility; it receives no such place on the UI screen for a web
application that is a few simple lines of perl code.  In all the code
that comes together to display a web page or processing a record or do
any number of application things why is the 5% these application
companies (some php code) special?  Each took $$ and time to make, but
somehow an application is special?  

I don't understand... Please do share why widely distributed  code built
using real developers and real costs ($$) are worth less than what
application companies are writing.  

> possible under open source licenses without attribution. For example,
> the incorporation of application programs anonymously into
> distributions by large companies could destroy the market for open
> source application software.

Again: consider using a copyleft license if you want to prevent this.
This force you claim can destroy the market can be mitigated by a
license which makes it difficult, if not impossible to embed.  Why does
GPL not meet this need?

> 	5.  Part of a Larger Problem.  Some individuals have expressed
> concern that the attribution licenses are not approved by OSI. Yet,
> many other modifications of open source licenses have not been
> approved by OSI, such as FOSS and Affero. OSI should address the
> entire problem or can be accused of selective enforcement.

Preaching to the choir here.  The OSI reviews license.  They won't
review license that aren't submitted by original authors.  SO... There's
no selective enforcement.  It's a community thing.  People like me
applying pressure to companies claiming to be open source but have not
passed the de facto vetting to the definition of open source.  

> 	6.  Community Acceptance.  These licenses are used by Socialtext,
> Zimbra, Alfresco,  Qlusters and SugarCRM. Yet their communities have
> not expressed objections to this requirement. Many of these companies
> are building business models which include distribution by third
> parties so the distributors do not have a problem with this approach.

Hey, Shareware with no expiration date is "beer" software.  I'm not sure
you'd hear people complaining about receiving free to use software.
Oracle gives away a version of it's database; the Oracle community isn't
complaining about that.  Calling it open source, and the connotation
that it has freedoms in USE is different.  Microsoft Communities will
sing the laurels of their benefactor.  Doesn't mean it's accepted by an
open source community because people like the software you let them run
for free.  

Are any of these downstream distributors able to legally use your
trademarks in the distribution without some understanding or agreement
from you?  All is fine and dandy when blessed by parties with a business
arrangement.  Can a competitor use your code and trademark legally you
have no recourse to stop them?

> 	7.  Consistent with Creative Commons. Creative Commons includes
> "attribution" as one of the key decisions that need to be addressed in
> using their licenses.

Creative Commons is applied in proper places.  ie, a note in a post etc.
If I quote from a creative commons piece I have to make a note of it
somewhere.  I don't have to place their logo on my entire website.

> 	8.  Not BSD Advertising Requirement. An attribution requirement is
> not similar to the "advertising" requirement. It does not impose
> "vague" requirements to mention the Berkeley Software Distribution in
> undefined "advertising". On the contrary, it is very specific and easy
> to understand and comply with.

Well, I think the original Exhibit B is actually MORE specific than the
proposed Attribution Provision.  As onerous as it may be, it at least
spells out the pixel size so it's CLEAR the impact that each combined
license will have.  This requirement leaves it up to the original author
how onerous the provision is (pixel size, watermarks, etc).

I'd like to suggest an alternative attribution provision that provides
the same "attribution to the user" but is much less onerous.  I'm no
attorney so I'm perfectly willing to let it be wordsmithed by anyone on
this list.  I disagree with it, but suggest it as a useful compromise
and for discussion.  I'm a strong critic of UI attribution and something
like the following would remove most of my objections (not that my
objections are any more or less valuable than anyone elses):

Generic Attribution Provision

        Redistributions of the original code in binary form or source
        code form, must ensure that each time the resulting executable
        program, a display of items (a),(b),(c) released by the original
        licensor on a splash screen or about page of the original
        licensor’s attribution information if such a splash screen or
        about page is present in redistribution, which includes:

        (a) Company Name
        (b) Logo (if any) and
        (c) URL

        Original Licensor grants limited use of Trademark and Logo as
        necessary to fulfill obligations of this provision.

Note: the "diffs" are clearer in HTML on my blog should anyone wish to
review it there.
http://www.nicholasgoodman.com/bt/blog/2006/11/27/compromise-attribution-rider-on-any-osi-license/

Kind Regards,
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20061129/be70b1ea/attachment.html>