Convert most http: links to https:
[wiki.git] / projects / collaboration.mdwn
1 SIPB projects should generally be free software with open collaboration, that is to say, with source code freely available and legally reusable in other free software, and with development processes visible to the community and open to community participation.
2
3 # Free software
4
5 For software and source code, the [[SIPB project licensing recommendation|doc/code-licensing]] advises you to choose one of the following two licenses:
6
7 * the [MIT license](https://opensource.org/licenses/MIT), also known as the "Expat" or "X11" license. This is a short, permissive license that allows code to be distributed and reused in most forms, without placing redistribution requirements on the user or distributor.
8
9   The MIT license is often seen in smaller works, although most of the X Window System and other Project Athena works (including Debathena) use this license.
10 * the [GNU GPLv2+](https://opensource.org/licenses/gpl-license). This is a longer "copyleft" license that ensures that anyone who redistributes your work must provide access to source code, and anyone who reuses your work must license the resulting work under the GPL (or a compatible license).
11
12   Most large free software projects, including the Linux kernel, the GNU userland, and Firefox, as well as scripts.mit.edu and Invirt (XVM), use the GPL.
13
14 Once you've chosen a license, you should make it clear that your
15 software is available under this license. See the following pages:
16
17 * <a>Licensing your software under the MIT license</a>
18 * <a>Licensing your software under the GPL</a>
19
20 If you're also distributing a Debian package of your software, see
21
22 * <a>Writing a debian/copyright file</a>
23
24 ## Rationale
25
26 Since projects tend to vary as to GPLv2, GPLv2+ ("version 2 or, at your option, any later version"), or GPLv3/3+, we currently recommend GPLv2+ for compatibility.
27
28 There are other licenses, most notably including the <a>BSD license</a>, which is similar to the MIT license, and the <a>AGPLv3</a>, which provides slightly more restrictions on reusers so that hosting a web application effectively counts as distribution. Code available under the GPLv3 can be used in an AGPLv3 application, but code only available under the AGPL cannot be used in a GPL application. Again, we recommend the GPL for compatibility.
29
30 For a permissive license, MIT and BSD are basically equivalent ([MIT TLO](http://tlo.mit.edu/community/software) recommends BSD online, but in person indicates that they don't differentiate). We recommend MIT over BSD just because much of Athena already uses it, [MIT appears substantially more popular](https://github.com/blog/1964-license-usage-on-github-com), and [Github recommends it](https://choosealicense.com/).
31
32 We anticipate that most SIPB projects' needs are best served by selecting either the MIT license or the GPL and moving on. However, if you are interested in this subject, you can learn more at [GNU's licensing website](https://www.gnu.org/licenses/) and [the Open Source Initiative's](https://www.opensource.org/licenses/). You can also read more about free and open source
33 software on GNU and OSI's websites; see also the [Debian Free
34 Software Guidelines](https://www.debian.org/social_contract#guidelines) and an [FAQ for it](https://people.debian.org/~bap/dfsg-faq.html).
35
36 # Free documentation
37
38 The [[SIPB documentation licensing recommendation|doc/doc-licensing]] advise *dual-licensing* (i.e., making available with both licenses) documentation under:
39
40 * the <a>Creative Commons Attribution-Share Alike</a> license, and
41 * the <a>GNU Free Documentation License</a>, with no Invariant Sections, no Front-Cover Texts, and no Back-Cover-Texts.
42
43 Both of these are popular licenses for free non-code creative works. For example, Wikipedia has in the past used the GFDL and currently uses CC-BY-SA.                                    
44
45 # Open collaboration
46
47 A license without the code is worthless! Make sure your code is posted somewhere accessible. If you're using a version control system (which you should), the easiest approach is to set up public read-only access to your repository. Options that SIPB projects have used include
48
49  * <a>Subversion or git in an Athena AFS locker</a>
50  * <a>Subversion or git on scripts.mit.edu</a>
51  * <a>Github</a>, a commercial git hosting service free for open-source/public projects
52
53 Code without an idea of development progress isn't worthless, but it's still not quite optimal. Again, options that SIPB projects use include
54
55  * A development <a>mailing list</a> that's public or open to interested contributors on request.
56  * Publicly readable <a>archives</a> of your mailing list. (Mailman lists support archiving, or you can add a Discuss archive, for example using [[Pergamon|/doc/pergamon]].)
57  * <a>Trac</a>, a bug tracker and source code browser available via the scripts.mit.edu autoinstaller.
58  * <a>Github</a> issues.
59  * <a>Launchpad</a>, the bug tracker and source code / Debian package host that Ubuntu developed and opened to others.