[Fwd: FW: For Approval: Generic Attribution Provision]
rick at linuxmafia.com
Sat Dec 16 08:03:09 UTC 2006
Quoting Ben Tilly (btilly at gmail.com):
> If you wish to find relevant material, I was the one who raised #8 in
> the GPLv2. And my point was that immiscibility between 2 codebases
> under essentially the same license is not new for open source.
But that was _not_ the same licence. Moreover, even in your
hypothetical, they _are_ miscible; the derivative work is merely not
lawful in the one country where the upstream coder so specified for
legal reasons, per clause 8.
> The starting comment for this subthread was your saying that we had
> "immiscibility of two codebases under the _same_ licence."
And so you felt obliged to drag in a hypothetical that did _not_ use the
same licence, but was in fact miscible anyway -- and managed thereby to
utterly ignore and distract from my point. Bully for you, Ben. Well done.
Meanwhile, struggling painfully back to the point, I'll just quote from
my side of an offlist conversation to someone else, on the point I _was_
actually talking about, as opposed to your recent irrelevant sideshow:
To answer your question: Sure, but this _isn't_ licence combinatorics,
but rather an effect that happens with multiple borrowings from
codebases all under the _same_ licence.
The point is that a natural coding activity, of code reuse without
any licence incompatibility, is substantively blocked by the particular
form of badgeware requirement referred to in the Subject header. (I'm
trying to be careful about logic: The same problem presumably might not
exist in other badgeware provisions not under discussion.)
> [code reuse is less common than often asseumed]
True enough. However, it's an important enough core notion of open
source to be referred to (though without specific mention of _multiple_
codebases) in OSD#3. Like forking, it's (IMVAO) an important reserve
power, regardless of how often used in practice.
> [multiple "badgeware" advertising clauses don't _block_ reuse, just
> make it a bit messy]
As a poster just pointed out, with at least one recent formulation of
a badgeware provision (the one with requirement of positioning in
the exact centre bottom), it _is_ actually impossible.
Moreover, even the theoretically possible cases might be reasonably
interpreted as making use infeasible in practice, e.g., three or more
mandated logos strike me as not something a reasonable user would
> [OSI helping distinguishing between reasonable and unreasonable burdens
> would be a good thing; but what is immediately relevant is compliance
> with the extant OSD criteria or not.]
As things stand, with Alfresco and others so far specifically eschewing
an "if any" qualifier on the "user interface" wording, I'd speculate
that OSD#10 is a bigger obstacle, anyway.
> [What's wrong with three or more logos? Haven't I seen commercial
> webmail screens? Mailstream technical Web sites?]
I can't help thinking this is a sloppy comparison.
Users of Web-based mail clients and mainstream techie Web site are
entering into a contractual business relationship for services. (It
remains that, regardless of whether money changes hands, as I went to
some pains to remind people on
They are consenting to being barraged by advertising, of that and other
sorts, pursuant to that business relationship.
However, even given that fundamentally different nature of the event --
the user is not making code reuse, and is not directly using it at all,
as you well know (as this model has been discussed to death back to the
OpenSales licensing symposiums I think we both attended, and in other
places), the Web site does not bear multiple logos prominently placed on
the site ("Lovingly crafted code from Foo!", "Lovingly crafted code from
Bar!", "lovingly crafted code from Baz!") that were legally mandated
upon the site-hosting company by software licences.
You seem to come close, above, to saying "Aww, be a sport, Rick.
Logos are everywhere in business; what are a few more between friends?"
However, the question is not whether [multiple] advertising logos are OK
in a business setting, Web, app-server, or otherwise, but rather whether
a requirement to retain them, mandated by software licensing in a way
that would cause them to accumulate through code reuse, is compatible
with the principles articulated in OSD#3 and maybe OSD#6 -- leaving
aside for a moment the larger problem of OSD#10.
More information about the License-discuss