• Probably mention open source and/or free software in the title

Definitely too much for a 20-30 minute time slot. Idea for information split: (1) Licenses. (2) Contributing to FOSS projects. If can get 2 half-hour slots at a hackathon, could present both as related but separate, so people can come to one or both.

• Pro: The 4 freedoms: https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms

In more pragmatic terms:

• Freedom to use the code without restrictions
• Freedom to study the code and change how it works
• Can share code among multiple contributors
• Can let others use your code freely as long as they follow the license

--- Skylar

• ??? con: Open-sourcing potentially unethical software: Stable Diffusion, malware, Tornado Cash.

• “if you want your software to be packaged by linux distributions and reach a wide audience, a FOSS license is almost always a requirement.” — Skylar
  • Debian Free Software Guidelines (DFSG). Rules of other distros. You can still package something yourself but if you want it to be in official repos of Ubuntu/Debian/Fedora/etc., you need to use approved open source licenses.
• Can enable others to audit your software for security, privacy, performance, etc.
• Faster and cheaper to reuse existing code for your projects
• Ensure that the project lives beyond the scope/lifetime of the original developer/company (mitigate risk of abandonware)
• Can make money! https://www.gnu.org/philosophy/free-sw.en.html#selling
  • This is a later item because it is rather important - we all need to put food on the table.

• SPDX: https://spdx.org/licenses/

Software Package Data Exchange (SPDX) is an open standard for software bill of materials (SBOM) (thanks Wikipedia). It's connected to the Linux Foundation.

• Free Software Foundation: https://www.gnu.org/licenses/license-list.html

A historic leader in free software, promoting the GPL and opposing the term “open-source” for skipping over the freedom aspect.

• Open Source Initiative: https://opensource.org/

Another historic leader in free software, focusing more on the pragmatism of free software.

• Software Conservancy: https://sfconservancy.org/

A nonprofit supporting software freedom. They provide support for FOSS projects and work to enforce free software licenses.

• Software in the Public Interest: https://www.spi-inc.org/

A nonprofit providing funds for free open source projects.

— Skylar

Most free licenses are variants of the following.

• MIT
• BSD
• Apache

• GPL, LGPL, AGPL. Overview, then differences between them.

These waive away a copyright entirely but are still free software.

• Unlicense
• ??? Potentially an issue as not all countries have a concept of public domain. May be solved by using an appropriate license?

We present these solely to inform the reader.

• ??? Proprietary licenses
  • All rights reserved. Most common apps and services (Windows, MacOS, Discord, Slack, GitHub, etc) fall under this.
  • Note that most Software as a Service/Service as a Software Substitute are also proprietary.
• ??? Open source after a period of time? https://mariadb.com/bsl-faq-mariadb/ and QT
  • It depends on the developers keeping their word to open source the code later. For example, KDE has a legal agreement with QT that KDE can continue to work on a fork of QT if QT ever becomes proprietary.
• ??? Open core?
  • A free open source product and a proprietary (possibly commercial) product, or a FOSS product that requires purchase of proprietary modules to be functional. Could put off users and developers if the FOSS product is substantially lacking in features compared to the proprietary product.
• ??? Source available?
  • Source code can be read, but modification/redistribution may not be allowed. For example: tarsnap, GitHub repos without a license.
  • Note that even if source code is leaked or reverse-engineered, a proprietary license or terms of service for that code may legally restrict you from doing anything with it.
  • Other variants of source available licenses include Apple's Academic License (https://info.computerhistory.org/apple-lisa-code), which is free for academic use only and cannot be sold.
• ??? Licensing on ethical appeals?
  • For example, the JSON license says, “The Software shall be used for Good, not Evil.” This has been seen as a problematic clause for not specifying what “good” or “evil” means.

• ??? Maybe something on trademarks, since I think BSD or Apache may have more to say on those. Also overall say something about trademarks because you can for example use Firefox's code but if you substantially change it you just can't call it Firefox.

Most projects assign the copyright of your patches to you, the contributor. Some projects require you to sign away your copyright, and potentially additional rights. Here are a few important examples.

• GNU Emacs: Contributing to Emacs itself or the official package repository (ELPA) requires you to assign your copyright to the FSF. That's about it, afaik.
• Developer Certificate of Origin (DCO): Contributing to the Linux kernel requires signing this. In brief, the certificate verifies that the user wrote the open-source changes and allows the project to use them in a way consistent with the license. https://developercertificate.org/
• Contributor License Agreement (CLA): Can be very restrictive. CLAs typically allow the owner of the project (typically a foundation or a company) to relicense your patches. CLAs are controversial because if the company makes the project proprietary, you no longer own the open-source code that you contributed. The company does. This has spoiled the relationship between a few communities already.

I recommend checking the contributor requirements before hacking away. Just know that CLAs tend to favor the corporations issuing them at the expense of the developers. https://blog.hansenpartnership.com/the-community-corrosive-effects-of-clas/

— Skylar

• Consider how much legal protection the license gives, and how much trouble you will go to enforce it.
• Consider how much it may persuade or dissuade potential contributors

In Summary:

• Permissive licenses benefit developers, who can borrow and contribute to the software more easily
• Restrictive licenses benefit users, who gain additional software freedom protections
• Proprietary licenses benefit companies who rely on source-code secrecy to profit from it

— Skylar

• Understand important FOSS is to the software stack (https://xkcd.com/2347/)
• Understand how to report bugs and cooperate with maintainers
• Understand how to be a good contributor (git, mailing lists, docs, etc)
• Understand if a project requires you to sign your copyright away for your contributions (see above)
• Find a free software project and hack on it!
  • Send PRs to your favorite projects on GitHub
  • Join internships dedicated to free software:
  • Ask your employer to work on free software

— Skylar

Many FOSS contributors are volunteers, and many companies who take from FOSS do not contribute back. Some FOSS developers have protested this in various ways. In any case, it is clear that the work that most FOSS developers do is not proportional to their compensation for that work. So knowing that FOSS currently does not pay as well as it should, how are people currently making a living from it?

• Sponsorship (eg GitHub sponsors, LiberaPay)
• Selling the software anyways, even if people can compile it for free
  • This is more common when compiling from source involves a difficult toolchain (Windows/MacOS/Android) or bleeding edge dependencies (projects still in development), or if buying from an online store comes with perks (eg automatic updates, achievements in the case of FOSS games sold on Steam, etc)
  • Targeting price to platforms: Krita is free on their website, but can be paid for on the Windows Store (cite? might have been a different app). Many apps are free (or their premium version is free) on F-Droid, but paid on the Play Store and iOS. — Jeffrey Fisher

Reasons probably include: Easier to take payments on store but still want to offer elsewhere. Increase number of people using it by having it be free, but still make some money from commonly used app stores.

• Selling non-software products (CDs, documentation, etc)
• Selling support
  • This is how companies like RedHat and Canonical make money
• Offering hosting services
  • Sourcehut. Mastodon, though I don't think it's paid.
• Donations
• Employment at a company that gives time to work on FOSS projects (eg Google)
  • Many FOSS developers work on it in their free time

— Skylar