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

[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