[License-discuss] a GPLv3 compatible attribution for MIT/BSD?
Rick Moen
rick at linuxmafia.com
Thu Feb 2 01:30:54 UTC 2012
Quoting Clark C. Evans (cce at clarkevans.com):
> As an update to this thread, I've revived my interest in
> trying to keep GPLv3 compatibility with this approach;
> a reasonable, attribution terms for a MIT derived license
> or the GPLv3 itself (under 7b).
The term 'attribution' tends to be used for a variety of different
things, so you may wish to start there.
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', too -- a rather propagandistic sleight of tongue, in my
view -- an approach that reached the pinnacle of absurdity with SugarCRM
Community Edition 5.x's perversion of GPLv3, using clause 7b to
re-implement the same obnoxious name-and-graphical-logo on every page
requirement widely rejected in the openly badgeware licences that they
claimed were open source. One of my analyses:
http://linuxgazette.net/159/misc/lg/sugarcrm_and_badgeware_licensing_again.html
Quoting:
GPLv3 section 7 is _not_ about attribution provisions. It is about
required legal notices (e.g., trademark) and other permitted
supplementary terms. Clause 7b says that "Requiring preservation of
specified reasonable legal notices or author attributions in that
material or in the Appropriate Legal Notices displayed by works
containing it" are permitted, but I very much doubt that FSF had in
mind required, immutable runtime display of trademarked logos and
advertising on every user interface screen of the program and all
derivatives -- which has the obvious effect of severely impairing
freedom of third-party commercial use.
An FSF author involved with the GPLv3 draft speaks to FSF's intent
(FWIW): http://gplv3.fsf.org/additional-terms-dd2.html
A GPL licensee may place an additional requirement on code for which
the licensee has or can give appropriate copyright permission, but only
if that requirement falls within the list given in subsection 7b.
Placement of any other kind of additional requirement continues to be a
violation of the license. Additional requirements that are in the 7b
list may not be removed, but if a user receives GPL'd code that purports
to include an additional requirement not in the 7b list, the user may
remove that requirement.
The literal wording of 7b is exactly as quoted above.
Getting back to Clark's initiative:
> 1. Create a set of open source components that can be used
> for the visual display of OSS attributions in a manner that
> satisfies both the GPLv3 requirements as well as being
> broadly useful enough for projects to incorporate.
'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
in its 5.x series. CPAL is also generically in the same category, but
its specific requirements are IMO orders of magnitude less burdensome,
enough to constitute a difference in kind.
(What's the difference between 'specified reasonable legal notices or
author attributions in that material' and required, immutable runtime
display of trademarked logos and advertising on every user interface
screen of the program and all derivatives? Degree, I suspect. If
reality is messy and lacks sharp distinctions sometimes, so be it.)
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.
And, really, how about we call runtime advertising by its real name, and
cease this subterfuge of mislabeling it as 'attribution'?
More information about the License-discuss
mailing list