[Fwd: FW: For Approval: Generic Attribution Provision]
Rick Moen
rick at linuxmafia.com
Sat Dec 16 18:56:05 UTC 2006
Quoting John Cowan (cowan at ccil.org):
> > 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.
>
> I guess we are not done yet.
>
> Suppose someone comes to me and said "Are you John Cowan?", receives
> an affirmative answer, and then goes to you and asks you "Are you
> John Cowan?" is told "No", and then complains because our answers
> were inconsistent. They aren't, because although the two questions are
> expressed in the same words, they aren't the same question.
This has all gotten rather silly.
Apparently, someone (perhaps you) recently posted a rather pointless
hypothetical about two "GPLed" codebases, one with a clause 8 addition
making it unlawful to use in some specific country -- claiming that this
was an already existing example of two codebases being incompatible
despite being under the same licence -- with the alleged point, such as
it was, being that immiscible codebases under the same licence were
(allegedly) nothing new.
My reply, once I was told the exact hypothetical and realised just how
dumb it really is, was thus: (1) No, those are not under the same
licence, and (2) no, anyway, they _remain_ miscible codebases, with the
derivative work merely unlawful in the one particular country where it
has legal problems.
At this point, I'm quite done with this inane digression, and would
appreciate returning to the main discussion about "attribution"
(mandatory graphical advertising) clauses and OSD #3, 6, and 10.
For example:
> By the same token, a license that says "Put my badge centered on the
> top" and another license from another programmer that says "Put my
> badge centered on the top" are *not* the same license, because of the
> indexicalness of "my". Therefore it's hardly surprising that they are
> inconsistent.
I'm not sure what your point is. Those requirements _could_ physically
be simultaneously complied with. The derivative work sporting two
mandatory advertising logos would start looking pretty silly, though.
Four or five, more so. (See below.)
> > 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.
>
> But there is a license incompatibility. You've just pointed it out.
I'm afraid I fail to grasp any essential impossibility to requiring
multiple mandatory logos (other than cases like multiple logos required
to be, e.g., in the exact centre bottom, as one provision recently
discused requires); maybe you can explain that to me.
> > 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 tolerate.
>
> This is what makes the old-BSD advertising clause obnoxious; nevertheless,
> the four-clause BSD is still presumably open source.
Sorry, there is a vital difference in kind:
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
That BSD clause's encumbrance was not on what the code may and may not
(or must and must not) contain or become -- but rather on advertising
about the codebase: its features, and its usage.
My point is that an "attribution" (mandatory graphical advertising)
software licence clause, after its effect has been multiplied through
code reuse to requiring _three or four or five_ mandatory graphical
logos festooned around every screen, starts to make reasonable reuse
infeasible in practice. That was not true of the "obnoxious" BSD clause #3.
More information about the License-discuss
mailing list