Draft community guidelines

[alexbayleaf]

My main task for this iteration (other than coaching) is to come up with a community guidelines document. I've just posted the draft to the mailing list so I'll just copy what I wrote there:

So, I drafted a proposed set of community guidelines. These aren't a full TOS or anything like that, but a short statement of values and then setting out a few specific interpersonal behaviours that aren't welcome, and what we'll do if they happen. I figure that when we get around to having a TOS, we include it by reference, i.e. the TOS will say something like "you agree to abide by our community guidelines".

I've put the document in github and I figure the TOS and any other policies (eg. privacy policy, copyright policy) can go there too. The good thing about having this stuff in github is that if/when we change any of our policies the change history will be visible, and people can see what's different from one version to the next.

Anyway! My draft is at https://github.com/Growstuff/policy/blob/master/community-guidelines.md and I would appreciate people reading it and letting me know what you think. I'm interested in anything ranging from high level conceptual feedback to smaller wording tweaks.

Licensing

[alexbayleaf]

(Copied from the mailing list. There are likely to be further comments/discussion in the archives there.)

So, another thing we should discuss is licensing for this project, since we'll need to add license files to whatever we commit to github.

I'm going to explain this from the ground up because I expect not everyone is completely conversant with open source license (a ha ha, is anyone? ever?) But if you are fairly familiar with this stuff, you can skip the explanations, because the tl;dr version is: GPL/copyleft or BSD-style?

For those who can't parse that, here's an explanation.

Open source/free software licenses all have certain things in common. These are fairly clearly expressed by the Free Software Foundation's list of "four software freedoms" (http://www.gnu.org/philosophy/free-sw.html) and/or the Open Source Institute's "open source definition" (http://opensource.org/osd.html/) but to summarise:

- anyone may download and use the software for any purpose
- anyone can view and study the complete source code for the software
- they need to be able to make changes to the code for their own use
- they need to be able to redistribute the software
- and they need to be able to redistribute their changes, as well

(That's more or less a rephrasing of the four software freedoms; the OSI definition adds some other twists as well, but the general idea is the same.)

An open source license is a legal document that is distributed with the software, which states what rights and responsibilities the software user has, in order to maintain the openness/freeness of the software. It's the same as the end-user agreements that most of us click "I Accept" on without reading, though the purpose is a bit different, and (handily) there are a handful of common/standard ones so that if you see that the license is "GPL v3" or "Mozilla license" or whatever, and you already know what that contains, then you don't have to read it through in detail.

Anyway, open source licenses mostly fall into two camps. The first type is the kind that says, in effect:

"You can use this software for any purpose, modify it, redistribute it, etc, but you have to leave a notice saying where it originally came from."

If you're familiar with Creative Commons, this is like the CC-BY (aka "Attribution") license. Basically you can do anything with the software, as long as you attribute it to the original author and don't try and claim it as your own. Open source licenses like this are sometimes known as "BSD style", because the license for the BSD operating system is like this. Under a BSD-style license, it's possible for someone to build commercial (non-open-source) software based on your code. Many parts of commercial software, these days, are based on open source under the hood because of this kind of license, and it's often considered a good choice if you *want* your stuff to be taken up by commercial vendors (eg. if you are writing something you want to become a widely used standard).

The second kind says:

"You can use this software for any purpose, modify it, redistribute it, etc. But if you create a derivative piece of software based on this, you must use *this exact same license* for your software."

In Creative Commons terms, this is like CC-BY-SA (aka "Attribution Share-Alike"). The best known software license of this kind is the GNU Public License (GPL). These kinds of licenses are also sometimes known as "copyleft" or "viral" licenses. They restrict re-use to those who are also using the same free/open source license, meaning that many potential commercial re-users may be unwilling or unable to modify/redistribute your code, unless they jump on the open source bandwagon (which, of course, would be a great result!) So, these licenses can be good if you don't want someone to commercialise what you're doing; on the other hand it can discourage wide uptake of your code, because not everyone wants to use the same license as you.

So, what I'd like us to discuss is, which general direction do we prefer?

Option 1:
BSD-style, or CC-BY for non-code parts of our work.
Pros: anyone can re-use, potentially wider uptake, easy to comply with license
Cons: higher potential for third-party commercial exploitation, can't include other people's GPL'd/copyleft software

Option 2:
GPL/copyleft, or CC-BY-SA for non-code parts of our work
Pros: spreads free software philosophy, less potential for third-party commercial exploitation, can incorporate others' GPL/copyleft code
Cons: may discourage wide uptake of our software

And a quick survey of some relevant or otherwise interesting sites/technologies and what they use:

- Dreamwidth: inherited software from Livejournal, where it was originally dual-licensed under the GPL and the non-copyleft Artistic License used by Perl (this sort of dual licensing, allowing people to choose, is common for Perl software but not often seen elsewhere). Dreamwidth uses CC-BY-SA for non-code parts of their site.

- OTW Archive Of Our Own: GPL

- Ruby on Rails: MIT license (BSD style); Ruby itself is under the Ruby License, which is a copyleft (i.e. GPL-like) license.

- Ravelry: included because otherwise people will ask ;) Ravelry is not open source.

- Wikipedia: content CC-BY-SA, underlying software is GPL

- Diaspora: Affero-GPL which is a version of the GPL specifically for people running network services

So, hopefully that's a fairly balanced and informative view of the two main types of license we might want to use. There are definitely advantages to each, though they vary depending on the sort of software you're building. I happen to think that BSD-style licenses are great if you want to build an underlying technology that people will embed in all kinds of things, whereas GPL is better if you are building a single coherent application, but I'm happy to hear opinions to the contrary. To keep things from getting out of hand (which open source license discussions can sometimes do) I'm going to suggest that we limit this conversation to this week only, and aim to reach consensus and commit license files to github along with the work we're doing this iteration.