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

[Michael Tiemann]

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