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 _______________________________________________ License-discuss mailing list [email protected] http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
