# Wiki: Choosing Software Licenses for Your Brigade Project

**URL:** https://discourse.codeforamerica.org/t/wiki-choosing-software-licenses-for-your-brigade-project/822
**Category:** Technical Skillsharing
**Tags:** open-source
**Created:** [July 1, 2020, 3:44pm UTC](https://discourse.codeforamerica.org/t/wiki-choosing-software-licenses-for-your-brigade-project/822 "2020-07-01T15:44:06Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![elb](https://sea2.discourse-cdn.com/flex020/user_avatar/discourse.codeforamerica.org/elb/32/484_2.png) [@elb](https://discourse.codeforamerica.org/u/elb)
#### Post date: [July 1, 2020, 3:44pm UTC](https://discourse.codeforamerica.org/t/wiki-choosing-software-licenses-for-your-brigade-project/822/1 "2020-07-01T15:44:06Z")

</div>

User Sourced Guide to Open Source Software Licenses. This is a Wiki; please edit it!

_Previous posts and reading_

- [Software licenses discussion](https://discourse.codeforamerica.org/t/software-licenses-discussion/230)
- [Choose a license](https://choosealicense.com/): Guide to Open Source Licenses

Overall guidance to Brigade projects provided to Open Oakland from the authors of the BSD license:

> The likelihood of patent issues for you guys is small, but you’re doing open government work, so if you’re successful lots of others will pick up your code. On that basis, I absolutely believe that one of the permissive licenses (MIT, BSD, Apache) makes sense. And Apache buys you some extra protection on the patent issue

**MIT**

From @ryan.b.harvey at Code for New Orleans

> We generally try to make everything as permissive as possible, which usually means something like MIT.

From @chris at Code for Philly:

> MIT is a good default choice if thinking about licensing seems like too much work because it at least 1) protects the rights of all contributors to reuse their works and 2) you can easily switch from MIT to almost any other license later

From @tdooner and Open Oakland

> At OpenOakland, we had this discussion as well. Being conveniently located next to UC Berkeley, we were able to take advantage of advice from the authors of the BSD license. Here are some quotes from what they said

> Either the MIT or BSD license is good. The 2-clause BSD license is  
> claimed to be slightly more permissive, but they seem about the  
> same to me.

**BSD**  
From @tdooner:

> The 2-clause BSD license is claimed to be slightly more permissive, but they (MIT/BSD) seem about the same to me.

**GPL/ LGPL**

From @chris at Code for Philly:

> the main thing that GPL/LGPL add is this notion of _user_ rights. Someone could take an MIT licensed project, provide it to a government as a vendor, and not allow that government access to the source code for the essential customizations they made. I think many brigade members would be upset to know their contributions could be used by a vendor to capture a public agency. The GPL/LGPL goes beyond the developer rights that MIT grants and also guarantees rights to the _users_ of software–that if someone gives you software based on the GPL project they _have_ to offer you the code too and let you do what you want with it

From @tdooner and a conversation with authors of the BSD license:

> I would avoid the GPL license, especially version 3, as it makes  
> it (by design) difficult for commercial companies to use the software.

**Apache**

From @ryan.b.harvey at Code for New Orleans:

> if you’re modifying other open source code as part of the project, you have to be careful about consistent licensing clauses on that software. This is almost always a concern with Apache or GPL’d software.

From @tdooner

> MIT is permissive like the Berkeley license. Apache is, likewise, but adds one useful feature: If anyone creates a patent and then uses it in Apache-licensed code that they distribute, anyone who receives that code or derivative works gets a license to the patent for free.

**GNU v 3.0**  
From Chris Houston at Code for Chapel Hill and [NCCovidSupport](http://www.nccovidsupport.org)

> We decided to go with a GNU v3.0 license, basically allowing the code to be used by anyone without any restrictions and no warranty / liability.

**Creative Commons: CC0**

From @ryan.b.harvey at Code for New Orleans

> For non-code artifacts, the Creative Commons licenses are a great resource as well, and we generally try to make that content CC0 (world-wide public domain) as much as possible, with the same considerations about consistent licensing for adaptations of existing content.

---

<div class="post-metadata">

### Author: ![chris](https://sea2.discourse-cdn.com/flex020/user_avatar/discourse.codeforamerica.org/chris/32/10_2.png) [@chris](https://discourse.codeforamerica.org/u/chris)
#### Post date: [July 1, 2020, 4:03pm UTC](https://discourse.codeforamerica.org/t/wiki-choosing-software-licenses-for-your-brigade-project/822/2 "2020-07-01T16:03:19Z")

</div>

I’ve long gone with MIT because it’s the easy consensus, but I suspect that fulfilling our mission to truly democratize software in the public commons requires a serious look at more copyleft licenses like GPL.

Linux, Git, WordPress, and MySQL are examples of GPL software, and you’d be hard pressed to find examples of technologies that did more to shift the power of software creativity into the people’s hands

Under the conventional Silicon Valley understanding of success you’ll find framing most software license debates, the GPL may make things harder, and those technologies look like failures as their authors aren’t sitting on billions in stock. But I think their success looks a lot more like the kind of success we want from the work we do in the brigade network

---

<div class="post-metadata">

### Author: ![Mari](https://sea2.discourse-cdn.com/flex020/user_avatar/discourse.codeforamerica.org/mari/32/992_2.png) [@Mari](https://discourse.codeforamerica.org/u/Mari)
#### Post date: [July 1, 2023, 7:04am UTC](https://discourse.codeforamerica.org/t/wiki-choosing-software-licenses-for-your-brigade-project/822/3 "2023-07-01T07:04:09Z")

</div>


