- Home
- >
- Software Development
- >
- How OSS Devs Can Take Ethical Stances without License Changes – InApps Technology 2022
How OSS Devs Can Take Ethical Stances without License Changes – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn How OSS Devs Can Take Ethical Stances without License Changes – InApps Technology in today’s post !
Read more about How OSS Devs Can Take Ethical Stances without License Changes – InApps Technology at Wikipedia
You can find content about How OSS Devs Can Take Ethical Stances without License Changes – InApps Technology from the Wikipedia website
While the Open Source Initiative’s (OSI) definition of open source software is quite clear on the matter — there must be “no discrimination against persons or groups” and “no discrimination against fields of endeavor” — the issue of who should be allowed to use open source software, according to ethical considerations, has long been debated.
It is a global movement. One that builds bridges through collaboration that cross geopolitical borders. A movement disrupted by federalism. One that builds up the corpus of Free knowledge available to all humans everywhere.https://t.co/1QNPtcw6vz
— msw (@_msw_) March 18, 2022
Over the last month, this topic has again become a focus of debate as Russia’s invasion of Ukraine has led to developers calling for blanket bans by companies like GitHub and GitLab; and to some developers even taking action. Earlier this month, we wrote about how open source gateway Scarf began limiting access to open source packages for the Russian government and military entities, via its gateway.
As we noted at the time, there was a primary distinction made when Scarf took this action: distribution of open source software is separate from the licensing of it. Those points of the OSI definition pertain to the licensing, not to some entity actively providing the software to others.
Since then, discussions around these ideas have continued, and this week an essay by Bradley M. Kuhn, a policy fellow and hacker-in-residence at the Software Freedom Conservancy, argues that copyleft won’t solve all problems, just some of them.
The essay specifically takes to task the idea that open source software can effectively affect change by way of licensing limitations. He spent nearly 3,000 words on the topic, before pointedly addressing the issue of Russia — with a similar conclusion to the one reached by Scarf earlier this month. Kuhn argues that “FOSS licenses are not an effective tool to advance social justice causes other than software freedom” and that, instead, developers have a moral obligation to take stances by way of other methods.
“For example, FOSS developers should refuse to work specifically on bug reports from companies who don’t pay their workers a living wage,” Kuhn offers in an example.
Regarding Russia specifically, Kuhn again points to distribution as an avenue of protest, while still remaining in line with the principles of free and open source software.
“Every FOSS license in existence permits capricious distribution; software freedom guarantees the right to refuse to distribute new versions of the software. (i.e., Copyleft does not require that you publish all your software on the Internet for everyone, or that you give equal access to everyone — rather, it merely requires that those whom you chose to give legitimate access to the software also receive CCS). FOSS projects should thus avoid providing Putin easy access to updates to their FOSS,” writes Kuhn.
So, for you open source maintainers out there who want to take an ethical stand, perhaps let Kuhn’s extensive essay offer you an argument to keep your conscience clean, as you ignore a pull request or two or deny distribution — all in moral protest.
there are some extremely brittle taboos holding the entire world of software licensing and free software together into a shape that vaguely supports the status quo while extracting as much free labor as possible for corporate benefit
— fruit goes beep (@scanlime) March 17, 2022
This Week in Programming
- Go 1.18 Gets Generics and More: The change that we’ve been writing about since the very first iterations of this column, and which has been discussed by the Go community for far longer, is finally here. With the release of Go 1.18, the language finally has support for generic code using parameterized types, which has been the most requested feature for over a decade now. Alongside that, Go 1.18 becomes “the first major language with fuzzing fully integrated into its standard toolchain” and the addition of a new Go workspace mode, which makes it simple to work with multiple modules, not to mention a performance improvement of “up to 20% due to the expansion of Go 1.17’s register ABI calling convention to these architectures.” We’d write more on this topic, but Darryl Taft here at InApps Technology already dug deep into this story with his interview with Steve Francia, Google Cloud’s Product & Strategic Lead for Go, who called this release “monumental,” so we’d direct you there for more detail instead.
- Docker Desktop Boasts 98% Speed Increase for Mac: Docker Desktop users on macOS have a big speed boost achievement to look forward to with the release of Docker Desktop for Mac 4.6. Docker says that the release “contains a number of changes that drastically improve file sharing performance for macOS users,” such as the “new experimental file-sharing implementation called virtiofs” and the “way that files are synced between the macOS host and Docker VM.” With these changes, the company says that it has seen a reduction in “the time taken to complete filesystem operations by up to 98%.” Mac users need to enable virtiofs, which is available to all users including Docker Personal free users.
‘I Think I Can Take On A New Coding Side Project,’ Says Woman Who Can’t Keep Succulents Alive
— ReductRs (@reduct_rs) March 17, 2022
- GitHub Intros Partial Re-Runs for Actions: We’ve all been there: you’re running a build process of some sort, watching each action complete successfully, until one fails and you have to restart the entire process over again. Such has been the way with GitHub Actions, but now GitHub has added the ability to perform partial re-runs, which allows you to re-run only the failed jobs or a single job. Alongside this new feature, GitHub says it has also “made navigation improvements that enable you to see the full results of previous runs.” The company also notes that, “as a bonus, if you use GitHub-hosted runners, you can save money by reducing billable minutes.” The ability to do a partial re-run is available via a new drop-down menu, as well as directly from the logs view, and each re-run will offer a confirmation dialog that lists all the jobs that will be re-run, including all jobs that are downstream dependencies. If you’re not using GitHub via the website, partial re-runs are also available via the GitHub REST API and command-line tools.
- A Progressive Web App Crash Course: If you’ve heard of progressive web apps (PWAs) but have yet to take to plunge, Microsoft has offered a way to learn progressive web apps in 30 days with its 30 Days of PWA series. The series starts off by looking at what a PWA is before exploring the fundamental building blocks (HTTPS, service workers, and web app manifests) and then going deeper into how to make a PWA installable, reliable, work offline, and capable. The series just completed this past week and is summed up fully in the blog post, so head on over to try out what some see as the potential future for building cross-platform mobile applications. Buyer beware, there is a bit of an issue with Apple’s lack of support for PWAs, but the Open Web Advocacy group is on the case.
“Typescript is silly because it just gets turned back into typeless code when you hit compile” oh man do I have some upsetting news about C++ for you
— Jules Glegg ️⚧️ (@heyjulesfern) March 16, 2022
InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: scarf.sh, Docker.
Source: InApps.net
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.