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

[Ben Tilly]

On 12/12/06, Lawrence Rosen <lrosen@...> wrote:
> > On Mon, 11 Dec 2006, Dalibor Topic wrote:
[...]

> 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?

Is it possible that they did not discuss this issue in depth with counsel?

Cheers,
Ben

[Rick Moen]

Quoting John Cowan (cowan@...):

> The OSI Definitions don't merely contemplate certain types of software
> reuse, but *every* type of software reuse.

Which brings me to a point I'm pretty sure nobody has yet mentioned:
Given an aspiring open source licence with a "Generic Attribution"
(i.e., mandated graphical advertising) provision, what happens when
Joe/Jane Coder uses some substantive covered code from Codebase A, plus
some from Codebase B?  Does his/her derivative work need to sport _two_
advertising logos in the bottom-left corner?  With addition of
borrowings from Codebases C, D, and E, Joe/Jane would seem to have
accumulated a big enough crowd of logos for them to form a basketball
team, nicht wahr?

That doesn't seem a lot like open source to me, substantively.

--
Cheers,           A mosquito cried out in pain:       The cause of his sorrow
Rick Moen         "A chemist has poisoned my brain!"  Was para-dichloro
rick@...                                   Diphenyltrichloroethane.

[David Dillard]

Suppose you want to combine two sets of code where the attribution
clauses in the licenses state (as in the Terracotta license) that you
must put the text at the very bottom and in the center.  You can't meet
the terms of both licenses.  Thus, you cannot combine the two sets of
code.  Seems silly to let attribution requirements prevent such a
combination.


--- David

> -----Original Message-----
> From: Rick Moen [mailto:rick@...]
> Sent: Wednesday, December 13, 2006 7:22 PM
> To: license-discuss@...
> Subject: Re: [Fwd: FW: For Approval: Generic Attribution Provision]
>
> Quoting John Cowan (cowan@...):
>
> > The OSI Definitions don't merely contemplate certain types
> of software
> > reuse, but *every* type of software reuse.
>
> Which brings me to a point I'm pretty sure nobody has yet mentioned:
> Given an aspiring open source licence with a "Generic Attribution"
> (i.e., mandated graphical advertising) provision, what
> happens when Joe/Jane Coder uses some substantive covered
> code from Codebase A, plus some from Codebase B?  Does
> his/her derivative work need to sport _two_ advertising logos
> in the bottom-left corner?  With addition of borrowings from
> Codebases C, D, and E, Joe/Jane would seem to have
> accumulated a big enough crowd of logos for them to form a
> basketball team, nicht wahr?
>
> That doesn't seem a lot like open source to me, substantively.
>
> --
> Cheers,           A mosquito cried out in pain:       The
> cause of his sorrow
> Rick Moen         "A chemist has poisoned my brain!"  Was
> para-dichloro
> rick@...                                  
> Diphenyltrichloroethane.
>

[Rod Dixon, J.D., LL.M.]

I would add OSD#3 and #4 as well.  Mandatory badgeware seems per se contrary to the spirit and letter of the OSD. Aside from the open source matter, if a badgeware proponent carefully reads some of the thoughtful comments posted on this list, it should become apparent that some forms of badgeware use do not well-serve the holder of the trademark anyway (that is, if the badgeware is an appropriate trademark).  There must be numerous ways to implement a less imposing signal of attribution than a mandatory badgeware restriction dressed up as a trademark license tucked inside a software copyright license.

Rod Dixon

On Dec 13, 2006, at 4:33 PM, Matthew Flaschen wrote:

Brian Behlendorf wrote:

I consider that unfortunate,

personally, but am willing to swallow my idealism - that allowing

badgeware to carry the label "Open Source" might be better for the world

than creating a big schism, and consuming passion and energy on a

distinction that doesn't really affect fundamental freedoms we value

about Open Source.

    Brian

It does affect fundamental freedoms, though.  For example, interfaces

could easily become burdensome if multiple types of badgeware are

developed.  Worse, one statement has implied that multiple forms of

badgeware could not be combined at all:

Ross Mayfield wrote:

Yet, by their nature, licenses with

attribution will only permit the original licensor to include its logo

since the license cannot be amended by sublicensors.

Finally, there remains the objection on OSD #10 grounds.  It is not

acceptable to limit open source code to GUI programs.

Matthew Flaschen

[John Cowan]

David Dillard scripsit:
> Suppose you want to combine two sets of code where the attribution
> clauses in the licenses state (as in the Terracotta license) that you
> must put the text at the very bottom and in the center.  You can't meet
> the terms of both licenses.  Thus, you cannot combine the two sets of
> code.  Seems silly to let attribution requirements prevent such a
> combination.

There are dozens of reasons for incompatibilities between various
OSI-certified licenses.

--
John Cowan    http://ccil.org/~cowan  cowan@...
'Tis the Linux rebellion / Let coders take their place,
The Linux-nationale / Shall Microsoft outpace,
We can write better programs / Our CPUs won't stall,
So raise the penguin banner of / The Linux-nationale.  --Greg Baker

[David Dillard]

There are, but that would be a truly silly one.
 

> -----Original Message-----
> From: John Cowan [mailto:cowan@...]
> Sent: Wednesday, December 13, 2006 10:12 PM
> To: David Dillard
> Cc: license-discuss@...
> Subject: Re: [Fwd: FW: For Approval: Generic Attribution Provision]
>
> David Dillard scripsit:
> > Suppose you want to combine two sets of code where the attribution
> > clauses in the licenses state (as in the Terracotta
> license) that you
> > must put the text at the very bottom and in the center.  You can't
> > meet the terms of both licenses.  Thus, you cannot combine the two
> > sets of code.  Seems silly to let attribution requirements prevent
> > such a combination.
>
> There are dozens of reasons for incompatibilities between
> various OSI-certified licenses.
>
> --
> John Cowan    http://ccil.org/~cowan  cowan@...
> 'Tis the Linux rebellion / Let coders take their place, The
> Linux-nationale / Shall Microsoft outpace, We can write
> better programs / Our CPUs won't stall, So raise the penguin
> banner of / The Linux-nationale.  --Greg Baker
>

[Rick Moen]

Quoting John Cowan (cowan@...):

> David Dillard scripsit:
> > Suppose you want to combine two sets of code where the attribution
> > clauses in the licenses state (as in the Terracotta license) that you
> > must put the text at the very bottom and in the center.  You can't meet
> > the terms of both licenses.  Thus, you cannot combine the two sets of
> > code.  Seems silly to let attribution requirements prevent such a
> > combination.
>
> There are dozens of reasons for incompatibilities between various
> OSI-certified licenses.

This, however, is immiscibility of two codebases under the _same_ licence.

--
Cheers,                  Higgeldy Piggeldy             "Phooey on Freud and his
Rick Moen                Hamlet of Elsinore            Psychoanalysis --
rick@...      Ruffled the critics by        Oedipus, Schmoedipus,    
                         Dropping this bomb:           I just loved Mom."      

[Ben Tilly]

On 12/14/06, Rick Moen <rick@...> wrote:
> Quoting John Cowan (cowan@...):
> > David Dillard scripsit:
[...]
> > There are dozens of reasons for incompatibilities between various
> > OSI-certified licenses.
>
> This, however, is immiscibility of two codebases under the _same_ licence.

Is this new?

Suppose that I have 2 GPLed programs, and one exercised their rights
under section 8 to, say, deny distribution in the USA due to patent
concerns.  Wouldn't merging the two involve sublicensing the one that
did not exercise their rights under section 8.  If so, then that is
prevented by section 4 of the GPL.  Therefore it is at least possible
that those two GPLed program might not be able to be merged.

IANAL, TINLA and all that good stuff.

Cheers,
Ben

[Rick Moen]

Quoting Ben Tilly (btilly@...):

> On 12/14/06, Rick Moen <rick@...> wrote:
> >Quoting John Cowan (cowan@...):
> >> David Dillard scripsit:
> [...]
> >> There are dozens of reasons for incompatibilities between various
> >> OSI-certified licenses.
> >
> >This, however, is immiscibility of two codebases under the _same_ licence.
>
> Is this new?
>
> Suppose that I have 2 GPLed programs, and one exercised their rights
> under section 8 to, say, deny distribution in the USA due to patent
> concerns.  Wouldn't merging the two involve sublicensing the one that
> did not exercise their rights under section 8.  If so, then that is
> prevented by section 4 of the GPL.  Therefore it is at least possible
> that those two GPLed program might not be able to be merged.

I believe you've just described a patent obstacle, not a licensing one.

The derivative work would be lawful, hence not in violation of copyight
everywhere in the free world^W^W^W^Woutside the USA -- and also in the
USA after elimination or expiration of that patent threat.

(BTW, it is not clear to me that sublicensing occurs in your
hypothetical:  GPLv2's grant is explicitly _directly_ from the copyright
holder to all lawful recipients who accept its terms.)

--
Cheers,           A mosquito cried out in pain:       The cause of his sorrow
Rick Moen         "A chemist has poisoned my brain!"  Was para-dichloro
rick@...                                   Diphenyltrichloroethane.

[Matthew Flaschen]

Rick Moen wrote:

> Does his/her derivative work need to sport _two_
> advertising logos in the bottom-left corner?  With addition of
> borrowings from Codebases C, D, and E, Joe/Jane would seem to have
> accumulated a big enough crowd of logos for them to form a basketball
> team, nicht wahr?

This objection been mentioned, and the closest thing to a rebuttal was:

Ross Mayfield wrote:

> Yet, by their nature, licenses with
> attribution will only permit the original licensor to include its logo
> since the license cannot be amended by sublicensors.

This would seem to ban combining multiple badgeware programs.

Matt

[Matthew Flaschen]

Rick Moen wrote:
> I believe you've just described a patent obstacle, not a licensing one.
>
> The derivative work would be lawful, hence not in violation of copyight
> everywhere in the free world^W^W^W^Woutside the USA -- and also in the
> USA after elimination or expiration of that patent threat.

No, the license says that the "the original copyright holder who places
the Program under this License may add an explicit geographical
distribution limitation excluding those countries".  This is a
limitation of the copyright license itself, not only a practical patent
obstacle.

Matt Flaschen

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> No, the license says that the "the original copyright holder who places
> the Program under this License may add an explicit geographical
> distribution limitation excluding those countries".  This is a
> limitation of the copyright license itself, not only a practical patent
> obstacle.

I believe you've just changed the subject fundamentally, from what we
were just talking about.

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> Rick Moen wrote:
>
> > Does his/her derivative work need to sport _two_
> > advertising logos in the bottom-left corner?  With addition of
> > borrowings from Codebases C, D, and E, Joe/Jane would seem to have
> > accumulated a big enough crowd of logos for them to form a basketball
> > team, nicht wahr?
>
> This objection been mentioned, and the closest thing to a rebuttal was:
>
> Ross Mayfield wrote:
>
> > Yet, by their nature, licenses with
> > attribution will only permit the original licensor to include its logo
> > since the license cannot be amended by sublicensors.

It's not clear to me that such is _necessarily_ true of all
"attribution" [sic] (i.e., mandatory displayed advertising) licences.
However:

> This would seem to ban combining multiple badgeware programs.

In that case, _those_ licences would, I would say, substantively
contravene OSD#3, Derived Works.

Quoting an offlist side-discussion I was recently in:   Code reuse,
albeit somewhat rarer than often believed, is 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.

--
Cheers,                   I have yet to see any problem, however complicated,
Rick Moen                 which, when you looked at it in the right way, did
rick@...       not become still more complicated. -- Poul Anderson

[Matthew Flaschen]

Rick Moen wrote:
> I believe you've just changed the subject fundamentally, from what we
> were just talking about.


How so?  I'm attempting to give my perspective on section 8, which
everyone had been discussing.

Matt Flaschen

[Craig Muth]

Are we discussing attribution licenses in general, or only
"badgeware"?  It seems as though many of these questions raised also
apply to the Attribution Assurance License, which has already been
approved.

> must put the text at the very bottom and in the center.  You can't meet
> the terms of both licenses.  Thus, you cannot combine the two sets of
> code.  Seems silly to let attribution requirements prevent such a
> combination.

I think that is a good point.  I believe most of these problems could
be solved and a compromise could be found, if one were desired.
Perhaps there could be some wording saying that the badge doesn't have
to be at the "very bottom", but close to the bottom.  Regarding the
sticky point of borrowing code from a badgeware project for a project
without a GUI, maybe the attribution should not be required if there's
no UI (someone mentioned this earlier as a compromise).  Of course,
this could make a loophole where you fork to a non-UI app, and then to
a UI app and don't have to use the badge.

I think it's also a good point that similar "gotchas" exist in the
current open source license landscape.  If your license is Apache and
you want to incorporate some GPL code, you may be out of luck.  With
all licenses, the copyright holders can grant the new project
permission to use the code with different terms or a different license
if they desire.  If we're talking about grabbing a useful function, I
think the copyright holders of an attribution license project would be
as likely to grant such permission as copyright holders of a GPL'ed
project.

IMO the original issue raised by the SugarCRM people is important.
For projects that want to open source a compelling and useful project,
the prospect of your code being rebranded (with little or no
modification) and/or sold (or supported for money, arguably a close
cousin to selling) with no "by the way these guys did all the work" is
a daunting one.  Pulling someone else's code into yours and
distributing it under your project's name is de facto attributing it
to yourself.  If the end result was that you added something of value
to the code, then it was good for open source.  If you did not improve
the code, but only rebranded and profited from it, then I would argue
that it was *very bad* for open source (in that it discourages coders
from releasing their code as open source) and the spirit of open
source will visit you three times in the night:)  It seems the trick
is to guard against the latter while not restricting the former.  This
is admittedly not a simple task.

As aptly stated by many here, the right of a company to have a
licenses that addresses this issue is not being debated.  Rather, the
debate is whether any regress to this issue should be labeled "open
source" (and of course whether a final solution can conform to the 10
points of http://opensource.org/docs/definition.php).  I believe that
it can, although perhaps not in the exact form submitted by
SocialText.

For people who don't have a powerful brand / company / web presence /
group of contributors but who want to release something "open source"
(let people use, modify, fork, redistribute, sell), knowing their
project can get swallowed by another project or support-based company
is discouraging.  Those of you who represent large companies that make
money from supporting code created by others probably don't grasp that
to the extent that others do.  I do think that such support companies
play an important role and are beneficial to the open source movement,
sometimes contributing back to the projects.  However, I don't think
they should begrudge giving credit where credit is due (ie to the
group whose code they're profiting by).

Although I think many here on the list have made valid refutations for
many points raised by SugarCRM, I think this one still stands:

> I guess they didn't notice that it's not open source.  They downloaded it,
> accessed the source, modified it, forked it, and redistributed it.  If it
> smells like open source and tastes like open source...maybe it's open
> source?

--Craig Muth

[Michael Tiemann-2]

On Fri, 2006-12-15 at 09:52 -0500, Craig Muth wrote:

> IMO the original issue raised by the SugarCRM people is important.
> For projects that want to open source a compelling and useful project,
> the prospect of your code being rebranded (with little or no
> modification) and/or sold (or supported for money, arguably a close
> cousin to selling) with no "by the way these guys did all the work" is
> a daunting one.  Pulling someone else's code into yours and
> distributing it under your project's name is de facto attributing it
> to yourself.

I disagree.  First, this problem has been around forever--ever since GNU
compilers were used by people who built products with them without ever
saying "This PlayStation (R) product was developed, simulated, debugged,
and brought to market courtesy of GNU and other free software
technologies".  Ever since the BSD guys made their excellent TCP/IP
stack available so that companies like Apple and Microsoft could
incorporate these into their OS technologies.  It's not a new thing.

Now, some savvy customers, particularly enterprise customers, actually
do care about the integrity of the source code.  It is interesting to me
that the reviews of Oracle's "Unbreakable Linux" are hardly restrained
at all in their denigration of Oracle's offering, while at the same time
praising the quality of Red Hat's bits.  How can this be?  Red Hat
didn't write Linux?  Heck, we didn't write 90% of what ships as Red Hat
Enterprise Linux.  But somehow a committed involvement in the process of
developing, debugging, packaging and certifying has accrued some measure
of value, whereas mere rebranding of bits engenders only scorn.  In that
light, a company selling to enterprise customers, customers who actually
care about the integrity of the products, even if they don't want to
read or modify the source code, care about whether they are dealing with
a reputable entity, meaning somebody who can actually fulfill the
promises they make.

>   If the end result was that you added something of value
> to the code, then it was good for open source.  If you did not improve
> the code, but only rebranded and profited from it, then I would argue
> that it was *very bad* for open source (in that it discourages coders
> from releasing their code as open source) and the spirit of open
> source will visit you three times in the night:)  It seems the trick
> is to guard against the latter while not restricting the former.  This
> is admittedly not a simple task.

I disagree with this idea.  I disagree that distribution and profit is,
in and of itself, bad for open source.  There are many, many cases where
open source has been helped tremendously by entrepreneurs who managed to
find a way to bring the bits to places that would otherwise never have
had them.  I think that companies making promises they cannot fulfill
are bad for themselves, but not bad for open source per se.

> As aptly stated by many here, the right of a company to have a
> licenses that addresses this issue is not being debated.  Rather, the
> debate is whether any regress to this issue should be labeled "open
> source" (and of course whether a final solution can conform to the 10
> points of http://opensource.org/docs/definition.php).  I believe that
> it can, although perhaps not in the exact form submitted by
> SocialText.

Right.  As we have seen, when Sun chose the GPL for Java, people did not
suddenly say "hey--the GPL is evil because Sun has adopted it!".
Instead, the community welcomed Sun's commitment to the GPL as a formal
agreement to play by the community's rules.  Good for Sun.

On the other hand, the community has read the Microsoft/Novell agreement
as an affront to the community, whether or not their agreement does
breach the GPL in some specific way or another.  This should not be a
surprise to anybody--their agreement is exclusive, and a common thread
of the community is inclusivity, GPL incompatibility notwithstanding.
(I say GPL incompatibility notwithstanding because GPL
compatibility/incompatibility is not governed by a limited commercial
agreement--it is a cultural or community choice one makes, like choosing
to eat with one's left or right hand.)

I have long supported the open-minded approach of the OSI which, in
turn, has supported many models of collaboration and commerce.  But I
would hate for the OSI to make itself irrelevant by embracing a new
model specifically designed for commerce that fundamentally undermines
other significant values of open source, which we are discussing.

> For people who don't have a powerful brand / company / web presence /
> group of contributors but who want to release something "open source"
> (let people use, modify, fork, redistribute, sell), knowing their
> project can get swallowed by another project or support-based company
> is discouraging.

For you.

>   Those of you who represent large companies that make
> money from supporting code created by others probably don't grasp that
> to the extent that others do.  I do think that such support companies
> play an important role and are beneficial to the open source movement,
> sometimes contributing back to the projects.  However, I don't think
> they should begrudge giving credit where credit is due (ie to the
> group whose code they're profiting by).

I've already addressed this, but can you imagine "Powered by
Shakespeare" at the bottom of every movie that has a plot that can be
related to one of his works?

> Although I think many here on the list have made valid refutations for
> many points raised by SugarCRM, I think this one still stands:
>
> > I guess they didn't notice that it's not open source.  They downloaded it,
> > accessed the source, modified it, forked it, and redistributed it.  If it
> > smells like open source and tastes like open source...maybe it's open
> > source?
>
> --Craig Muth

[Craig Muth]

Nicholas Goodman wrote:
> What am I missing?  What do the USER, COMMUNITY, and WORLD get out of
> badgeware other than more startups popping out more pseudo open source
> applications?  (ie, Free to use software)

The value is that the project was released as open source in the first
place.  Some people must believe that the attribution-license projects
in question have value, judging by their large numbers of users.  If
you're a company that does customer service and it's either Seibol or
SugarCRM, whose source you can download, modify, and use for free, you
probably think SugarCRM has tremendous value.

An approved attribution clause could possibly result in more useful
code being released as open source, rather than as shareware etc.,
especially where the code is maintained by a person or small group and
tends to be focused on a very specific idea or component.  However,
the preferred option for projects of large scope and with large
committer bases will likely remain the unmodified GPL (the
contributions by a large number of committers benefits you by
improving your code and makes your contribution less by proportion,
thus outweighing the lack of credit given and making attribution less
deserved).

--Craig Muth

[Craig Muth]

Michael Tiemann wrote:
> I disagree with this idea.  I disagree that distribution and profit is,
> in and of itself, bad for open source.  There are many, many cases where

I disagree with that idea as well.  As I said...

> > to the extent that others do.  I do think that such support companies
> > play an important role and are beneficial to the open source movement,
> > sometimes contributing back to the projects.  However, I don't think

What I proposed was bad for open source was specifically when
companies rebrand and charge money without contributing back.

Since you mentioned Redhat specifically, I'll say that I think Redhat
has been quite good for open source.  I'm not among those who scorn
Redhat for the rebranding of bits.  I've used Redhat quite a bit and
don't grudge the big red hat logo in the least.

Redhat is an example of a company that took a large general-purpose
project with many talented contributors (Linux) and itself became a
contributor, at the same time as making a healthy profit from it
(regarding which I repeat that I applaud).

Not all projects are like this though.  Not all projects have a huge
group of contributors to leverage.  Many projects deal with a very
specific application or component, and can't reasonably expect help
from contributors.  This is why the OSI has approved more than just
the GPL - because not all projects are alike.

> I've already addressed this, but can you imagine "Powered by
> Shakespeare" at the bottom of every movie that has a plot that can be
> related to one of his works?

I'm not sure the Shakespeare analogy is easily applicable to software.
 To offer another analogy, I would suggest Redhat wouldn't have
begrudged Torvalds requesting a modest link to his home page show up
in the UI's of Linux forks, even though he of course did not request
this.  I would also suggest that after Linux became an entity unto
itself, with thousands of contributors, he likely would have have
relinquished any attribution demand, had he made any.  The obvious
retort is "what about a giant 'powered by Linus' logo on the X
desktop?"  To this I would reply that I agree that a compromise should
be found.

--Craig Muth

[Matthew Garrett]

On Fri, Dec 15, 2006 at 10:57:45AM -0500, Craig Muth wrote:

> What I proposed was bad for open source was specifically when
> companies rebrand and charge money without contributing back.

Given that the BSD license (one of the original open source licenses)
explicitly allows this, and given the continued popularity of such
licenses, I think it's unlikely that this belief is especially common.

> I'm not sure the Shakespeare analogy is easily applicable to software.
> To offer another analogy, I would suggest Redhat wouldn't have
> begrudged Torvalds requesting a modest link to his home page show up
> in the UI's of Linux forks, even though he of course did not request
> this.  

Given that (as far as I know) Linus has made no significant contribution
to any Linux UI, that would be a pretty clear contravention of OSD 9.

> I would also suggest that after Linux became an entity unto itself,
> with thousands of contributors, he likely would have have relinquished
> any attribution demand, had he made any.  The obvious retort is "what
> about a giant 'powered by Linus' logo on the X desktop?"  To this I
> would reply that I agree that a compromise should be found.

The attribution clause in the original 4-clause BSD license is often
held to be inconvenient, but just about at the limits of acceptability.
It has several major usability advantages over the sort of license
you're suggesting - it doesn't restrict the form of the derived work in
any way, and it doesn't introduce any difficulties in combining multiple
works under the same license.

--
Matthew Garrett | mjg59@...

[Nicholas Goodman]

On Fri, 2006-12-15 at 10:25 -0500, Craig Muth wrote:
> Nicholas Goodman wrote:
> > What am I missing?  What do the USER, COMMUNITY, and WORLD get out of
> > badgeware other than more startups popping out more pseudo open source
> > applications?  (ie, Free to use software)
>
> The value is that the project was released as open source in the first
> place.  Some people must believe that the attribution-license projects
> in question have value, judging by their large numbers of users.  If

So... The value is that there is more "free to download" and "use"
software in the world?  That's compelling, and even a trend (Oracle
express edition, MSFT Express, etc), but it's not necessarily open
source.  I'm trying to figure out why these companies find the term
"shared source" or "public source" or "community source" so offensive.
I'm NOT dogging freeware.   Freeware is good for users, not as good as
Open Source, but it's good for users.  :)

>Not all projects are like this though.  Not all projects have a huge
>group of contributors to leverage.  Many projects deal with a very
>specific application or component, and can't reasonably expect help
>from contributors.  This is why the OSI has approved more than just
>the GPL - because not all projects are alike.

Let's consider this:
100k+ projects on sourceforge; clearly the vast majority of them don't
have the commit base that Linux does.  I'll admit many of these projects
are old and dead, but there are literally tens of thousands of projects
that meet the profile you describe.  ie, small commit base, niche
project, relatively small code base, easy to rebrand (Tcl scripts, php
application, etc).

These companies, people, etc seem comfortable with the understanding of
open source as has been established over the past decade or so.  So
let's be clear here:  We're talking about a few (< 20, primarily VC
backed) NEW companies and individuals, not a huge population of people
currently doing open source feeling like they've been ripped off.  

How about a question to anyone:  Is there anyone that has been doing
open source for years, but now feels that badgeware is necessary for
them to continue to do "open source?"  Perhaps if people share they're
ready to leave open source because they don't have a badgeware license
that indicates a gap in the "license market."