presentations:introduction_to_software_licensing
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
presentations:introduction_to_software_licensing [2024/08/25 21:01] – created admin | presentations:introduction_to_software_licensing [2024/08/25 22:11] (current) – [Getting started with FOSS] admin | ||
---|---|---|---|
Line 38: | Line 38: | ||
* Can make money! https:// | * Can make money! https:// | ||
* This is a later item because it is rather important - we all need to put food on the table. | * 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:// | ||
+ | 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:// | ||
+ | A historic leader in free software, promoting the GPL and opposing the term " | ||
+ | * Open Source Initiative: https:// | ||
+ | Another historic leader in free software, focusing more on the pragmatism of free software. | ||
+ | * Software Conservancy: | ||
+ | A nonprofit supporting software freedom. They provide support for FOSS projects and work to enforce free software licenses. | ||
+ | * Software in the Public Interest: https:// | ||
+ | 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/ | ||
+ | * ??? Open source after a period of time? https:// | ||
+ | * 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/ | ||
+ | * Note that even if source code is leaked or reverse-engineered, | ||
+ | * Other variants of source available licenses include Apple' | ||
+ | * ??? 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 " | ||
+ | ==== 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' | ||
+ | == 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:// | ||
+ | * 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, | ||
+ | |||
+ | 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:// | ||
+ | |||
+ | --- 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:// | ||
+ | * 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: | ||
+ | * 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/ | ||
+ | * 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, | ||
+ | * 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 | ||
+ | |||
+ | |||
+ |
presentations/introduction_to_software_licensing.1724619674.txt.gz · Last modified: 2024/08/25 21:01 by admin