Re: [Fwd: FW: For Approval: Generic Attribution Provision]

[Nicholas Goodman]

Great - I'm glad we're all having a real discussion based on merit of an attribution clause.  Kudos again to Ross for putting something up for real discussion.

clause, which have already been articulated here, I would offer a
hearty "amen" to the arguments made earlier.  Simply, I agree that a
splash-screen attribution requirement would not be onerous, and it
would echo certain splash-screen language that has already been
included in other, OSI-approved licenses.

Yes.  It seems to be in line with previous OSI licenses and in line with what many "attribution license" companies do for THEIR attribution currently (ref: Sugar "About" page).

Here is the original proposal (from Socialtext) with my proposed edits
in [BRACKETED CAPS]:

"Redistributions of the [original code] in binary form or source code
form, must ensure that each time the resulting executable program
[RUNS], a display of the same size as found in the [original code]
released by the original licensor (e.g., splash screen or banner text)
of the original licensor's attribution information, which includes:

(a) Company Name
(b) Logo (if any) and
(c) URL

[MUST APPEAR FOR ENOUGH TIME AS TO BE LEGIBLE]."

Seems consistent with "giving credit where credit is due."  I'm cool with the legibility edit. 

I think that sorts out the size/placement which leads me to one suggestion:  One of the issues I had with the original wording (included in your edits) was leaving the requirement of placement/size as determined by original code:
"... a display of the same size as found in the original code released by the original licensor ..."
I believe the wording (yours/mine/ross/whomever) has to LIMIT the nature of the attribution and not leave it up to the original licensor.  Otherwise, we're back where we started (badgeware on every UI) screen.  If OSI is going to approve, generally for ubiquitous use, an attribution rider should limit to appropriate attribution places (IMHO).  Notice that my definition of "appropriate" was inferred, in part, from what people using Attribution Licenses do currently for other copyright holders (docs/about/etc).

How does this sound?  I also agree with Nicholas Goodman's suggested
additional language addressing trademark rights, in his post from
11/29.

The last thing that I would reiterate from my original "compromise" attribution rider is the language about "if such a splash screen or about page is present in redistribution".  I think that OSD #10 requires that no particular technology be present (ie, can't require a GUI and be OSD compliant).  This language allows it to meet #10 because attribution on Splash/About page is not a requirement if there isn't an About or Splash page present (non GUI circumstances).

Nick

[Ross Mayfield]

I think limiting the attribution affordance for licensors will bring
us back where we started (or are today, a day when yet another open
source company launched with MPL + attribution), and a license that is
designing what is "appropriate" is designing software, if not choosing
technology.

Is striking the example language, "(e.g., splash screen or banner
text)" a considerable compromise?

Ross

On 12/4/06, Nicholas Goodman <ngoodman@...> wrote:

>
>  Great - I'm glad we're all having a real discussion based on merit of an
> attribution clause.  Kudos again to Ross for putting something up for real
> discussion.
>  clause, which have already been articulated here, I would offer a
> hearty "amen" to the arguments made earlier. Simply, I agree that a
> splash-screen attribution requirement would not be onerous, and it
> would echo certain splash-screen language that has already been
> included in other, OSI-approved licenses.
>
>  Yes.  It seems to be in line with previous OSI licenses and in line with
> what many "attribution license" companies do for THEIR attribution currently
> (ref: Sugar "About" page).
>  Here is the original proposal (from Socialtext) with my proposed edits
> in [BRACKETED CAPS]:
>
> "Redistributions of the [original code] in binary form or source code
> form, must ensure that each time the resulting executable program
> [RUNS], a display of the same size as found in the [original code]
> released by the original licensor (e.g., splash screen or banner text)
> of the original licensor's attribution information, which includes:
>
> (a) Company Name
> (b) Logo (if any) and
> (c) URL
>
> [MUST APPEAR FOR ENOUGH TIME AS TO BE LEGIBLE]."
>
>  Seems consistent with "giving credit where credit is due."  I'm cool with
> the legibility edit.
>
>  I think that sorts out the size/placement which leads me to one suggestion:
>  One of the issues I had with the original wording (included in your edits)
> was leaving the requirement of placement/size as determined by original
> code:
>  "... a display of the same size as found in the original code released by
> the original licensor ..."
>  I believe the wording (yours/mine/ross/whomever) has to LIMIT the nature of
> the attribution and not leave it up to the original licensor.  Otherwise,
> we're back where we started (badgeware on every UI) screen.  If OSI is going
> to approve, generally for ubiquitous use, an attribution rider should limit
> to appropriate attribution places (IMHO).  Notice that my definition of
> "appropriate" was inferred, in part, from what people using Attribution
> Licenses do currently for other copyright holders (docs/about/etc).
>  How does this sound? I also agree with Nicholas Goodman's suggested
> additional language addressing trademark rights, in his post from
> 11/29.
>
>  The last thing that I would reiterate from my original "compromise"
> attribution rider is the language about "if such a splash screen or about
> page is present in redistribution".  I think that OSD #10 requires that no
> particular technology be present (ie, can't require a GUI and be OSD
> compliant).  This language allows it to meet #10 because attribution on
> Splash/About page is not a requirement if there isn't an About or Splash
> page present (non GUI circumstances).
>
>  Nick

--
--
Ross Mayfield
CEO
Socialtext, Inc.
ross.mayfield@...
aim:rossdmayfield
skype:rossmayfield
t. [phone]
f. [phone]
company: http://www.socialtext.com
weblog: http://ross.typepad.com
many-to-many: http://www.corante.com/many
this email is: [ ] bloggable [ x ] ask first [ ] private

[David Woolley]

> > [RUNS], a display of the same size as found in the [original code]

Still doesn't provide an implementable definition of "size".

> > released by the original licensor (e.g., splash screen or banner text)
> > of the original licensor's attribution information, which includes:
> >
> > (a) Company Name
> > (b) Logo (if any) and
> > (c) URL
> >
> > [MUST APPEAR FOR ENOUGH TIME AS TO BE LEGIBLE]."

That is actually a very long time for most users, as one would have to
allow for non-native speakers and those with disabilities that made
reading difficult, or required, for example, screen readers.

[Nicholas Goodman]

On Mon, 2006-12-04 at 14:30 -0800, Ross Mayfield wrote:

I think limiting the attribution affordance for licensors will bring
us back where we started (or are today, a day when yet another open
source company launched with MPL + attribution), and a license that is
designing what is "appropriate" is designing software, if not choosing
technology.

Again, the idea is to NOT restrict technology/use by explicitly saying attribution in appropriate places are not required in headless or NON GUI circumstances.  Hence the suggested language (if such a splash screen or ... exist).

Allowing the broad ability to do attribution via any method the original author determines (I think your proposed language intends this, yes?) would clearly open the door for badgeware.  ie, without explicitly limiting the "nature" of the attribution it could become exceptionally onerous.  ESPECIALLY since this provision is meant to be considered as an addendum to any OSI license it should be considered carefully. 

Is striking the example language, "(e.g., splash screen or banner
text)" a considerable compromise?

Actually, I would suggest the opposite.  Changing the wording to ensure that licensors can not impose onerous conditions would likely explicitly identify those places and not grant anything else.  ie, Attribution required can only be required on a splash screen, about page, online help, etc.
 
Does the compromised wording I've suggested put us at an impass?  ie, attribution is only acceptable to you (and others) if it's on every UI screen and attribution is only acceptable to me (and others) if it's restricted to appropriate places. 

I'm losing my stamina for advocating against badgeware; the Tsunami of VC dollars behind this issue is formidable.  I've made the case that the type of attribution desired is NOT in line with the Open Source effect; I'm guessing the OSI Board has to sort the issue themselves now. 

I've resigned to accept that open source may become a bit more "caveat emptor" and acronyms like CTFL (Check the Frickin License) may be part of "Getting Started with Open Source" articles/guides/etc.  I PERSONALLY am okay in that world, because I know licensing (fairly) well.  For every one of me, there are 10,000 users/buyers/developers that will need to know how to CTFL.  C'est la vie.

We can all still get along and have a cup of tea; even if we disagree.  I look forward to hearing what the OSI Board sorts out with this proposal.

Kind Regards,
Nick

[Brian Behlendorf]

I think the fundamental question for this list is whether badgeware is
copacetic to Open Source.  My intuition is that giving credit to authors
is cheap for the value it provides, even if we're talking about screen
real estate or headers added to network protocols, and if it ever gets
expensive or unreasonable then that'll natually lead people to seek and
develop alternatives.  The idea of badgeware doesn't appear to be opposed
to forking or other essential freedoms.  So long as the author of a
derivative work has the right to add their own badge in some way, and so
long as badges don't have to be propagated to aggregate works (e.g.,
Fedora doesn't have to add a SugarCRM logo to the whole Fedora package
collection just because a SugarCRM RPM is contained within), it seems like
a fair balance.  But it is a departure from what's accepted today, and I
like the drive towards a generic provision that could be added to any
license.

  Brian

[John Cowan]

Brian Behlendorf scripsit:

> I think the fundamental question for this list is whether badgeware is
> copacetic to Open Source.  My intuition is that giving credit to authors
> is cheap for the value it provides, even if we're talking about screen
> real estate or headers added to network protocols, and if it ever gets
> expensive or unreasonable then that'll natually lead people to seek and
> develop alternatives.  The idea of badgeware doesn't appear to be
> opposed to forking or other essential freedoms.  So long as the author
> of a derivative work has the right to add their own badge in some way,
> and so long as badges don't have to be propagated to aggregate works
> (e.g., Fedora doesn't have to add a SugarCRM logo to the whole Fedora
> package collection just because a SugarCRM RPM is contained within), it
> seems like a fair balance.  But it is a departure from what's accepted
> today, and I like the drive towards a generic provision that could be
> added to any license.

The trouble is that if you pull a chunk of code (more than a snippet,
less than the whole thing) out of a badgeware GUI/web program and
incorporate it into a program that doesn't have a graphical UI,
what then?  I find a nifty implementation of some algorithm or
other, I add it to my command-line program, how and where do I
display the badge?

--
John Cowan   <cowan@...>   http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script.  One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.'  --Beverly Erlebacher

[Ben Tilly]

On 12/9/06, John Cowan <cowan@...> wrote:
> Brian Behlendorf scripsit:
[...]
> The trouble is that if you pull a chunk of code (more than a snippet,
> less than the whole thing) out of a badgeware GUI/web program and
> incorporate it into a program that doesn't have a graphical UI,
> what then?  I find a nifty implementation of some algorithm or
> other, I add it to my command-line program, how and where do I
> display the badge?

Slightly more generously, suppose that I add a small chunk of code
from a badgeware program into an existing GUI/web program.  To do that
do I have to go through *every* screen to add the badge even though it
is only used in one place?  If so, that's a pretty big disincentive
for using that code.  A big enough one that in practice I'm going to
choose not to do it.

Cheers,
Ben

[zengyi]

 

[Russ Nelson]

zengyi writes:
 > un-subscribe

Everyone who got on this list, got on it by sending email to
license-discuss-subscribe@... .  Why would ANYBODY consider
ANY other method to unsubscribe from the list than by sending email to
license-discuss-unsubscribe@... .

Sending an email with the subject "un-subscribe" is very unlikely to
get you un-subscribed.  Just so you know.

--
--my blog is at    http://blog.russnelson.com   | You can do any damn thing
Crynwr sells support for free software  | PGPok | you want, as long as you
521 Pleasant Valley Rd. | [phone]       | don't expect somebody else
Potsdam, NY 13676-3213  |     Sheepdog          | to pick up the pieces.

[Dalibor Topic]

Brian Behlendorf <brian <at> collab.net> writes:

>
>
> I think the fundamental question for this list is whether badgeware is
> copacetic to Open Source.  My intuition is that giving credit to authors
> is cheap for the value it provides, even if we're talking about screen
> real estate or headers added to network protocols, and if it ever gets
> expensive or unreasonable then that'll natually lead people to seek and
> develop alternatives.  The idea of badgeware doesn't appear to be opposed
> to forking or other essential freedoms.

I'd say that badgerware that requires displaying and propagating trademarked
logos, is fundamentally contrary to the idea of open source, since it makes it
very hard to actually fork the code without running foul of trademark laws.

cheers,
dalibor topic

[Craig Muth]

> The trouble is that if you pull a chunk of code (more than a snippet,
> less than the whole thing) out of a badgeware GUI/web program and
> incorporate it into a program that doesn't have a graphical UI,
> what then?  I find a nifty implementation of some algorithm or
> other, I add it to my command-line program, how and where do I
> display the badge?

Good point.  It seems like this should be addressed somehow, if
possible.  Does anyone
have a take on how the Attribution Assurance License works in this case?

> copacetic to Open Source.  My intuition is that giving credit to authors
> is cheap for the value it provides, even if we're talking about screen

I agree very much with this sentiment.  There seem to be some sticky
points, but I am glad an effort is being made to work through them to
find a compromise.  Support companies are making healthy profits from
open source these days (and I applaud them for doing so), but often
the guy who did the initial commit of the bulk of the code (and ideas)
to begin a project gets left in the dust without much recognition.

I think a strength of the OSI has been its recognition that open
source licenses are not one-size-fits-all.  In the interest of
disclosure I concede that I hope to use an attribution provision (or
license) for my own little project if one is settled on.  Otherwise,
I'll likely go the customized attribution clause route.  I'd like to
require forkers to keep 2 hyperlinks to my site in the "Options" box
that is part of my ui.  Other than this, I want to allow them to use,
modify, include, and sell it etc. without having to release the source
of apps they include it into.  My project is a UI component that is
much more likely to be embedded in other projects than forked by them.
 The unmodified GPL IMO serves projects that have large contrubtor
bases (Linux, etc.) extremely well.

--Craig Muth

[Anderson, Kelly-2]

Seems like the Attribution gui could be on the install program... even
in such a case.

-Kelly

-----Original Message-----
From: Craig Muth [mailto:craig.mu@...]
Sent: Monday, December 11, 2006 8:57 PM
To: license-discuss@...
Subject: Re: [Fwd: FW: For Approval: Generic Attribution Provision]

> The trouble is that if you pull a chunk of code (more than a snippet,
> less than the whole thing) out of a badgeware GUI/web program and
> incorporate it into a program that doesn't have a graphical UI,
> what then?  I find a nifty implementation of some algorithm or
> other, I add it to my command-line program, how and where do I
> display the badge?

Good point.  It seems like this should be addressed somehow, if
possible.  Does anyone
have a take on how the Attribution Assurance License works in this case?






E-Mail messages may contain viruses, worms, or other malicious code. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective action against such code. Sender is not liable for any loss or damage arising from this message.

The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized.

[John Cowan]

Anderson, Kelly scripsit:

> Seems like the Attribution gui could be on the install program... even
> in such a case.

Not all install programs have GUIs.

--
I could dance with you till the cows            John Cowan
come home.  On second thought, I'd              http://www.ccil.org/~cowan
rather dance with the cows when you             cowan@...
came home.  --Rufus T. Firefly

[Brian Behlendorf]

On Sun, 10 Dec 2006, Ben Tilly wrote:

> On 12/9/06, John Cowan <cowan@...> wrote:
>> Brian Behlendorf scripsit:
> [...]
>> The trouble is that if you pull a chunk of code (more than a snippet,
>> less than the whole thing) out of a badgeware GUI/web program and
>> incorporate it into a program that doesn't have a graphical UI,
>> what then?  I find a nifty implementation of some algorithm or
>> other, I add it to my command-line program, how and where do I
>> display the badge?
>
> Slightly more generously, suppose that I add a small chunk of code
> from a badgeware program into an existing GUI/web program.  To do that
> do I have to go through *every* screen to add the badge even though it
> is only used in one place?  If so, that's a pretty big disincentive
> for using that code.  A big enough one that in practice I'm going to
> choose not to do it.

Ben's example is easier to answer.  Yes, it's a big disincentive - as
would having to relicense your application to be GPL rather than another
license just because that code you desire is GPL-licensed.  Inconvenience
doesn't seem to be a primary constraint.

The answer to John's would presumably be - "well, implement a GUI".  A
more serious answer is that I'm not suggesting that all possible badgeware
provisions be accepted, but that it would be possible to come up with one.
A provision that says that the badge must be "somewhere prominent and
user-visible within a single click or keyboard input" might be an
acceptably generic way of stating it.  If you're building a DNS server
that has no user interface other than the DNS information returned on a
lookup, that's a trickier situation, but how much harm is done by saying
such a no-UI project can't use code from the badgeware project?

  Brian

[Brian Behlendorf]

On Mon, 11 Dec 2006, Dalibor Topic wrote:
> I'd say that badgerware that requires displaying and propagating trademarked
> logos, is fundamentally contrary to the idea of open source, since it makes it
> very hard to actually fork the code without running foul of trademark laws.

No, not really.  If I tell you that you must include this logo in this way
in the UI of your redistributed work, then I am implicitly but inarguably
giving you a license to trademark rights I might have in that logo and
name, limited to usage as defined by that license.

  Brian

[Matthew Flaschen]

Brian Behlendorf wrote:

> Yes, it's a big disincentive - as
> would having to relicense your application to be GPL rather than another
> license just because that code you desire is GPL-licensed.

One is a licensing restraint, while the other is a restraint that hurts
usability.  The OSD seems to be much more tolerant of the former.

> [H]ow much harm is
> done by saying such a no-UI project can't use code from the badgeware
> project?
>
>     Brian

I don't see how that restriction could possibly be allowed by OSD #10
(License Must Be Technology-Neutral).  I think #10 is meant to avoid
such arbitrary boundaries.

Matthew Flaschen

[Lawrence Rosen]

> On Mon, 11 Dec 2006, Dalibor Topic wrote:
> > I'd say that badgerware that requires displaying and propagating
> > trademarked logos, is fundamentally contrary to the idea of
> > open source, since it makes it very hard to actually fork the
> > code without running foul of trademark laws.

Brian Behlendorf responded:
> No, not really.  If I tell you that you must include this logo in this way
> in the UI of your redistributed work, then I am implicitly but inarguably
> giving you a license to trademark rights I might have in that logo and
> name, limited to usage as defined by that license.

Brian, if you give me a license to trademark rights you have in your logo
and name, and thereby allow or require me to apply that logo or name to my
derivative works over whose quality you have no control, you are likely to
lose your trademark.

Dalibor Topic's fear (from the vantage point of the licensee who forks) is
not realistic because forking is always allowed for open source software
regardless of the trademarks it bears, but the licensor should fear that his
trademark will become useless if he requires it to be displayed on those
forks.

The stronger the GAP requirements to include licensor's logo and trademark
in prominent places on uncontrolled goods, the more likely the loss of the
trademark. Given that reality of trademark law, I'm curious why so many
companies seem to want such strong attribution in UIs of other companies'
modified software?

/Larry

[Matthew Flaschen]

Not all programs *have* installers.  Besides, the installer isn't likely
to be the part derived from the badgeware.

Matthew Flaschen

John Cowan wrote:
> Anderson, Kelly scripsit:
>
>> Seems like the Attribution gui could be on the install program... even
>> in such a case.
>
> Not all install programs have GUIs.
>

[Matthew Flaschen]

Lawrence Rosen wrote:

I'm curious why so many
> companies seem to want such strong attribution in UIs of other companies'
> modified software?

That's a very good question, and I don't know for sure.  However, I
think part of it is that they don't take OSD #3 seriously.  They expect
copies to have minor or non-existent changes, and want to emphasize that
they own and control the program; the accuracy of this obviously varies
considerably.  Probably the drafters didn't really fathom people
extracting code for totally unrelated use.

Matthew Flaschen

[Larry M. Augustin]

I don't believe you need a license to the trademark Foo to say a piece of
software is "Foo-based", "derived from Foo", or "based on Foo".  That's
simply an expression of fact describing the origin of the code in the
derivative work.  I believe you could require attribution of that form
without granting a license to the trademark.

Trademark usage around Open Source is a whole other area that needs some
attention.

Larry

--
Larry M. Augustin

> -----Original Message-----
> From: Lawrence Rosen [mailto:lrosen@...]
> Sent: Tuesday, December 12, 2006 10:24 PM
> To: license-discuss@...
> Subject: RE: [Fwd: FW: For Approval: Generic Attribution Provision]
>
> > On Mon, 11 Dec 2006, Dalibor Topic wrote:
> > > I'd say that badgerware that requires displaying and propagating
> > > trademarked logos, is fundamentally contrary to the idea of
> > > open source, since it makes it very hard to actually fork the
> > > code without running foul of trademark laws.
>
> Brian Behlendorf responded:
> > No, not really.  If I tell you that you must include this logo in this
> way
> > in the UI of your redistributed work, then I am implicitly but
> inarguably
> > giving you a license to trademark rights I might have in that logo and
> > name, limited to usage as defined by that license.
>
> Brian, if you give me a license to trademark rights you have in your logo
> and name, and thereby allow or require me to apply that logo or name to my
> derivative works over whose quality you have no control, you are likely to
> lose your trademark.
>
> Dalibor Topic's fear (from the vantage point of the licensee who forks) is
> not realistic because forking is always allowed for open source software
> regardless of the trademarks it bears, but the licensor should fear that
> his
> trademark will become useless if he requires it to be displayed on those
> forks.
>
> The stronger the GAP requirements to include licensor's logo and trademark
> in prominent places on uncontrolled goods, the more likely the loss of the
> trademark. Given that reality of trademark law, I'm curious why so many
> companies seem to want such strong attribution in UIs of other companies'
> modified software?
>
> /Larry
>