[License-discuss] a GPLv3 compatible attribution for MIT/BSD?

[Clark C. Evans]

On Wed, Feb 1, 2012, at 05:16 PM, Karl Fogel wrote:
> Rick Moen wrote:
> > I'm generally doubtful about new licences without a really 
> > compelling reason, and the whole sordid badgeware episode 
> > from 2006-7 tends to make me particularly skeptical of novel 
> > licences talking about 'reasonable attribution terms'.
> 
> Basically my feelings too, FWIW.

I think there is room for an otherwise permissive license that
requires attribution of component parts to be presented to users 
in a tasteful manner that provides acknowledgement.  Closing this
gap is important for libraries and other "under the hood" software
that would otherwise be completely invisible.

As such, this isn't at all like requiring a badge.  We're talking
about dozens of components in most modern systems, and those are
further derived from dozens more.  I think it's an engineering
problem to create a catalog that stores this and a compelling and
broadly useful user interface screen to display this information.

>From those who routinely write permissive libraries, filling this
gap would be a boon.  Currently, you're either permissive or 
copyleft... there's no middle ground.  I think a requirement on 
works "containing" your work that asks for tasteful attribution 
but is not a full-blown copyleft to be a very nice sweet spot.

On Wed, Feb 1, 2012, Rick Moen wrote:
> I personally consider most licence requirements for 
> 'visual display of OSS attributions' to be at minimum 
> a bit obnoxious

I think a solid test for this approach is if applications would,
of their own effort, deploy such attribution without being
compelled.  If the practice is accepted broadly enough, then we
could consider a license which would compel the practice for
those who would otherwise not participate.

> However, even SugarCRM, Inc. could see that that was going to eventually 
> boomerang on them, so they wisely moved to Affero GPLv3 starting with 
> Sugar Community Edition 6.

I'd note that SugarCRM retains in their latest release the 7b
"Powered By" additional non-permissive term.  

On Wed, Feb 1, 2012, at 05:30 PM, Rick Moen wrote:
> The term 'attribution' tends to be used for a variety of different
> things, so you may wish to start there.

Yes.  Perhaps using the word Acknowledgment may help; I don't know.

> Classically in software, it refers to copyright notices, e.g., 
> in source code.  In the last decade, the aforementioned group 
> of Web 2.0 / SaaS hucksters started referring to mandatory 
> runtime advertising as 'attribution'

It is seen as part of the quid-pro-quo from those releasing their
work.  Like it or not, advertising and attribution are pretty
much on the same spectrum.  

For grant/contract based businesses, although one is officially
paid for new works, your engagement is based upon reputation,
and, for this purpose you need to have public acknowledgment.  
If no one knows the extent of your work, it's difficult to get
sponsorship, contracts, or grants.

Anyway, what's is most problematic about badgeware requirements, 
and indeed is a feature from the businesses using such terms, is 
that it discourages other commercial uses. 

> http://linuxgazette.net/159/misc/lg/sugarcrm_and_badgeware_licensing_again.html

I think Richard Fontana has some nice background on this:

http://lists.debian.org/debian-legal/2011/12/msg00038.html
http://lists.debian.org/debian-legal/2011/12/msg00049.html
http://lists.debian.org/debian-legal/2011/12/msg00045.html

I will say that the wording SugarCRM uses implies to me that
adding additional screens requires you to include their badge,
which I'm absolutely sure isn't accurate.  The 7b clause talks
about *preservation* of attribution in materials, not the
injection of false attribution into someone else's work.

> 'Visual display of OSS attributions' required via GPLv3 clause 7b
> sounds a whole lot like the aforementioned Web 2.0 / SaaS notion of 
> 'attribution' and difficult to distinguish from what SugarCRM did 

Ok, so here's GPLv3 7b, noting that 'material' is defined 
above is stuff "you add to a covered work":

  Requiring preservation of specified reasonable legal 
  notices or author attributions in that material or in 
  the Appropriate Legal Notices displayed by works 
  containing it; or

So, I read this as having two parts.  The first part is what
enables badgeware.  Your "Powered By" graphic is part of the
material you added and since it is an attribution, you can
require that it not be removed. 

  Requiring preservation of specified reasonable legal 
  notices or author attributions in that material

However, there's the other conditional sentence...

  Requiring preservation of specified reasonable legal 
  notices or author attributions in the Appropriate 
  Legal Notices displayed by works containing it

This is the part I'm thinking might work as a basis.  The
Appropriate Legal Notices ("ALN") is explicitly defined earlier
as being something akin to an "About" box with legal notices.
It must be prominently and conveniently available.  You could
can ask that your "reasonable author attributions" be shown
in the ALN of a work containing yours.

If you're a component, and you wish to require attribution in
works containing it you must do three things: (a) you have to
have an ALN yourself, and (b) your ALN must have a reasonable
author attribution and/or legal notices, (c) your license must
require that these author attributions and legal notices be
preserved.  Only then might you compel display of attributions.

I see this as quite sensible.  The only question for me is what
*reasonable* can mean.  I'd like it to include some sort of logo
for the project, the project's title, and stuff like that.  If
the interface is visual, you could show them.  If an interface 
is textual, you've got the title/link as text.

I think if the "containing work" uses graphical branding for
itself, then asking for graphical logos is reasonable.  I was also
thinking... even though the GPLv3 might require a derived work to
have an ALN accessible from every *interactive* user interface, it 
doesn't mean this license term should.  In particular, it might be 
a real pain for developers to add this sort of stuff early in the
development phase.  However, once branding is added... I think it's 
fair enough to ask for attribution at that point.

So, the entire legal term might be contingent upon the existence of 
graphical.  If there is branding and it is a graphical interface, 
it is reasonable to ask that attributions also be graphical.  If 
you don't have branding, you don't have self-attribution, so in
this case, we may not want to be anything other than permissive.

> I know Clark was also talking about a 'registry of OSS works and
> dependencies with pretty logos, license terms, and others', and
> encouraging crediting such works in public deployments, which 
> sounds useful, I guess, but I'm not enthusiastic about 'an emergent
> consensus on acceptable attribution practices for those who might
> otherwise wish to not play along', as it is highly prone to abuse,
> and I doubt any such 'emergent consensus' is likely.

Now, that'd I'd like to hear more about ;)

> And, really, how about we call runtime advertising by its real name, and
> cease this subterfuge of mislabeling it as 'attribution'?

I don't think a pop-up dialog that enumerates credits for
component parts of a work, even if you require it to show a
title, include logos and hyperlink would constitute a subterfuge.

That said, no one will do such a thing if it isn't technically
convenient, visually attractive, and culturally acceptable.

Best,

Clark