Licensing a Nonprofit's First Open Source Release
You volunteer with a 12-person nonprofit that runs a free tutoring program. Their IT coordinator wrote a 900-line Python script that imports student attendance from CSV files into their database. It works well, and two nearby nonprofits have asked to use it. The board agrees to publish it on GitHub, but the coordinator is uneasy: 'If we put it online, a for-profit company could take it, add a login screen, and sell it. We want people to share improvements, not lock us out.' The organization has no lawyer and no prior open-source experience. They also want outsiders to report bugs and submit patches, but they are worried about accepting code with unclear ownership. The script is currently in a private folder on the coordinator's laptop, with no version history. You have one meeting to recommend a licensing and contribution approach.
1. The board's top priority is preventing a competitor from selling a modified closed version. Compare the practical effect of the MIT license, the GNU GPLv3, and publishing with no license, and recommend one. Explain what 'open source' does and does not guarantee about commercial use.
Read the worked answer
Start by separating three things: copyright, licensing, and the OSI definition. With no license, the code is publicly visible but legally all rights reserved; nobody may copy or modify it, so it is not open source. MIT (or BSD) is permissive: a competitor may take the code, modify it, ship only binaries, and sell it, provided it keeps the copyright notice and license text. That directly conflicts with the board's stated priority. GPLv3 is copyleft: anyone who distributes a modified version must license the whole derivative under GPLv3 and make the corresponding source available. A competitor may still charge money, and may use the code internally without distributing, but cannot turn it into a closed product. If the board also fears a hosted service built from the code, AGPLv3 adds a network-use source requirement. 'Open source' means the freedoms to run, study, redistribute, and improve; it does not mean noncommercial. Recommendation: GPLv3 (or AGPLv3 if SaaS is the real fear), with a clear README stating the license and a trademark note so the nonprofit's name and logo are not licensed with the code. This meets the sharing goal without promising exclusivity.
2. Design a lightweight contribution workflow. What files should be in the repository, how should patches be handled, and how do you address the ownership concern without a lawyer?
Read the worked answer
Keep the process light enough for a 12-person nonprofit to sustain. The repository root should contain: LICENSE with the full GPLv3 text (not a link only); README.md explaining what the script does, the supported Python version, the CSV format, install and run steps, and how to get help; CONTRIBUTING.md stating that bugs go to the issue tracker and changes come as pull requests, with a small style and test expectation; and a short CODE_OF_CONDUCT.md. For ownership, avoid a heavyweight legal process but do not ignore provenance. Require each commit to carry a Developer Certificate of Origin-style sign-off: 'I wrote this or have the right to submit it under the project license.' That is a statement, not a copyright assignment; contributors keep copyright and grant the project license. Ask contributors to confirm they did not copy code from a proprietary source. Maintainers should review for license compatibility before merging, keep decisions in public issues, and record who merged what. Do not accept patches by private email with no public record. Add a SECURITY.md with a private reporting address for vulnerabilities. This gives an audit trail and makes the nonprofit's obligations clear without a lawyer.