

LCA: How to destroy your community - rythie
http://lwn.net/SubscriberLink/370157/33038a9113a805df/

======
Maciek416
Some of these guidelines are pretty nasty and serious, some of them are very,
very subtle. For example, when reading this rule:

"5. Employ large amounts of legalese. Working with the project should involve
complex contributor agreements, web site content licensing, non-disclosure
agreements, trademark licenses, and so on. [...]"

I can't help but be reminded of the process involved in contributing to
Clojure:

<http://clojure.org/contributing>

Obviously this comparison is not fair to the Clojure project, but if you
squint a little bit, some contributors might be scared off by even the
smallest roadblock.

~~~
davidw
The Apache Software Foundation has something similar. It's mostly for ass-
covering should future "SCO"s arise.

~~~
jrockway
Not really. It's more for ease in relicensing. When contributers don't assign
copyright, the license can never change, since their contributions bind the
original project to the original license.

Emacs is a good example of this working. Because Emacs is copyrighted by GNU
and not its contributers, it was a simple matter of changing a few strings to
change the license from GPL2 to GPL3.

For projects without copyright assignments, this is not possible; the Linux
kernel will be GPL2 forever, even if someone wants to change. Some copyright
holders are long dead, and contacting their estate to change some terms in the
license agreement is impractical. (This is a shame, too; a GPL3 version of
Linux would be great for hardware hackers everywhere.)

~~~
davidw
What you are describing is the motivation behind the FSF assignment
requirement, what I was talking about was the Apache Software Foundation:

<http://www.apache.org/licenses/> (see 'Contributor License Agreements')

------
mckinsey
While reading this, it struck me as though Magento (the open-source e-commerce
shopping cart) could be guilty of using some of those tactics.

