Linux Club @ UMD

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Potentially useful video: https://www.youtube.com/watch?v=UMIG4KnM8xw

We are not lawyers, but could consult one to help us out! $$$

The key thing I want to provide is an understanding of your options. Secondary to that is the ethical and economical implications. They are important, but in my opinion the most helpful version of this presentation would be short, understandable, and have everyone leave with a confident understanding of their options for licensing and possibly an idea of which they would lean towards.
I don't want people making things public without a full understanding of what that means. I don't want people regretting choosing MIT/BSD license. I don't want people regretting choosing GPL.

--- Jeffrey Fisher

EDIT: For Bitcamp we want to aim for 30 minutes, with time for questions. We will likely need to cut majority of ethical/economical stuff. IMO the main thing is to avoid people publishing code or artifacts without a license. Doubt we will have time to cover how to make money off the stuff you make. Should probably mention some ideas briefly or at least "making money off of FOSS is a challenging problem".

--- Jeffrey Fisher

    * Probably mention what rights you grant to GitHub and other GitHub users when you make something public without a license.
        * Both pros and cons on this side. If you accidentally make it public there are some rights granted, and people will be able to download and use, and use it even illegally, but not much you can do in most cases. If you make it public and want people to be able to use it, but don't publish under an appropriate license, people won't be able to legally use it.
        * Important to mention that if you upload code to GitHub, it will be used to train GitHub Copilot (their AI code-writing service). There are ongoing lawsuits about the license compatibility of the training code and the code that Copilot produces. Many users have protested by moving their software to other forges such as Gitlab or Codeberg, but that does not answer the legal questions posed by Copilot and related AIs. As FOSS licenses have been rarely challenged in court before, this is an important case to watch for all developers. --- Skylar
    *We will present pragmatic lessons and takeaways here to avoid flamewars from both sides (Richard Stallman and Steve Ballmer, for example), and to avoid devolving into conspiracy theories (for example, GPL or BSD license zealots. Or Embrace, Extend, and Extinguish, a valid criticism, but the extent to which it applies to licensing is debatable). --- Skylar
    *We will also not discuss Creative Commons. While related, CC licensing generally refers to creative works, not software.
=== Come up with more fun and attention-grabbing title ===
  * 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.
===== Why FOSS? =====
=== Ethics pros and cons ===
  * 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.
=== Utility/Economics pros and cons ===
  * "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.
===== Organizations dealing with FOSS licensing =====
  * 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
===== Licenses to cover =====
=== Open source / free software ===
Most free licenses are variants of the following.
== Permissive ==
  * MIT
  * BSD
  * Apache
== Restrictive / copyleft ==
  * GPL, LGPL, AGPL. Overview, then differences between them.
== Public domain ==
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?
=== ??? Nonfree licenses ===
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.
==== Other free software adjacent topics ====
== Trademarking ==
  * ??? 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.
== Signing away copyright ==
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
===== How to pick a license? =====
  * 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
===== Getting started with FOSS =====
  * 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
    * [[wiki:internships|Join internships dedicated to free software:]]
    * Ask your employer to work on free software

--- Skylar
===== Paying the bills with FOSS =====
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