5 ms·

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 leg

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 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 17y ago
The Apache Software Foundation has something similar. It's mostly for ass-covering should future "SCO"s arise.
- Maciek416 17y ago
  That makes sense. You'd almost expect that every single widely-used project should have something like this (jQuery is a good example).
- jrockway 17y ago
  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 17y ago
    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/ http://www.apache.org/licenses/ (see 'Contributor License Agreements')
jacquesm 17y ago
Some ? Make that 'most'. Any open source project that requires people to go and sign pieces of paper is putting barriers up where non should exist. I'm actually quite impressed with clojure, but this one aspect will stop me forever from contributing so it is a one-way street as far as I'm concerned. Not that I'm in a position to do so (as a clueless newbie) but who knows what the future holds.
- Raphael_Amiard 17y ago
  Well i think consideration should be given to the fact that it's a language project driven by a single individual trying to make his living out of it, not a dbms bought by a multinational company. I personnally have no problem with that. It's also a sign of the fact that Rich wants to keep a pretty strong hand on what is happening with clojure, and as far as the project is a language project, i find that quite healthy. Also, imagining that you would have a contribution to make to Clojure, and you'd really want to make it (because you work with it everyday for example). What would stop you to even consider signing the agreement ? (true question)
  - jacquesm 17y ago
    > What would stop you to even consider signing the agreement ? (true question) Anything ending on a '?' should be a true question :) I think what would stop me is the fact that the contribution alone is not enough, that on top of that I would be required to enter in to some legally binding agreement. The benefits from what I can see are exclusively one-sided. I'm fine with Rich Hickey wanting to keep a strong hand on what is happening, I'm not so fine with him taking (shared) ownership of all contributions. This could lead to all kinds of trouble, for instance in the event of his untimely expiration. His estate would suddenly be the party that I find myself holding 'joint copyright' with on something that I wrote. That could cause a lot of headaches. So, instead if that situation would come up I'd release it out of the clojure contributions package as a stand-alone thing. Anything that needs http://www.sun.com/software/opensource/contributor_agreement.jsp http://www.sun.com/software/opensource/contributor_agreement... this much legalese is probably best not signed until you've had a lawyer look it over, and that's going to set you back a pretty penny. Contracts are great for people that do not trust each other, they add a stiff price on top of the original arrangement which makes it expensive to break. A low-life open source contributor has no place signing contracts that carry possible consequences over and above the contribution. That should be the sum total of it, requiring people to sign stuff imho is not the way to go about this.

davidw 17y ago

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

Maciek416 17y ago
That makes sense. You'd almost expect that every single widely-used project should have something like this (jQuery is a good example).
jrockway 17y ago
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 17y ago
  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/ http://www.apache.org/licenses/ (see 'Contributor License Agreements')

jacquesm 17y ago

Some ? Make that 'most'. Any open source project that requires people to go and sign pieces of paper is putting barriers up where non should exist. I'm actually quite impressed with clojure, but this one aspect will stop me forever from contributing so it is a one-way street as far as I'm concerned. Not that I'm in a position to do so (as a clueless newbie) but who knows what the future holds.

Raphael_Amiard 17y ago
Well i think consideration should be given to the fact that it's a language project driven by a single individual trying to make his living out of it, not a dbms bought by a multinational company. I personnally have no problem with that. It's also a sign of the fact that Rich wants to keep a pretty strong hand on what is happening with clojure, and as far as the project is a language project, i find that quite healthy. Also, imagining that you would have a contribution to make to Clojure, and you'd really want to make it (because you work with it everyday for example). What would stop you to even consider signing the agreement ? (true question)
- jacquesm 17y ago
  > What would stop you to even consider signing the agreement ? (true question) Anything ending on a '?' should be a true question :) I think what would stop me is the fact that the contribution alone is not enough, that on top of that I would be required to enter in to some legally binding agreement. The benefits from what I can see are exclusively one-sided. I'm fine with Rich Hickey wanting to keep a strong hand on what is happening, I'm not so fine with him taking (shared) ownership of all contributions. This could lead to all kinds of trouble, for instance in the event of his untimely expiration. His estate would suddenly be the party that I find myself holding 'joint copyright' with on something that I wrote. That could cause a lot of headaches. So, instead if that situation would come up I'd release it out of the clojure contributions package as a stand-alone thing. Anything that needs http://www.sun.com/software/opensource/contributor_agreement.jsp http://www.sun.com/software/opensource/contributor_agreement... this much legalese is probably best not signed until you've had a lawyer look it over, and that's going to set you back a pretty penny. Contracts are great for people that do not trust each other, they add a stiff price on top of the original arrangement which makes it expensive to break. A low-life open source contributor has no place signing contracts that carry possible consequences over and above the contribution. That should be the sum total of it, requiring people to sign stuff imho is not the way to go about this.