So, I want a t-shirt to show off love to open source. I need some org to buy it from (so my money counts). I also want it to have a clear message to regular people.
Daniel Quinn @ danielquinn @lemmy.ca Posts 12Comments 662Joined 2 yr. ago
Daniel Quinn @ danielquinn @lemmy.ca
Posts
12
Comments
662
Joined
2 yr. ago
Mozilla's VPN is just reselling Mullvad, so you can support Mozilla and use Mullvad at the same time if you like.
You might want to consider just Dockerising everything. That way, the underlying OS really doesn't matter to the applications running.
I've got a few Raspberry Pi's running Debian, and on top of that, they're running a kubernetes cluster with K3s. I host a bunch of different services, all in their own containers (effectively their own OS) and I don't have to care. If I want to change the underlying OS, the containers don't know either. It's pretty great.
Revealjs is a pretty great replacement for PowerPoint, but it does require rudimentary HTML skills.
yt-dlp is pretty much the authoritative solution for this these days.
What's a PPA?
Watch the video. The selection of bike infrastructure is done so in a frame of lowest cost with highest benefit, and this is couched in the explanation that there's no one thing to solve everything but rather a series of things that all must be done.
If you really want an app-like interface, you could make use of Epiphany's "Install as Web App" feature. Just open Epiphany, go to your Lemmy instance, login, and then select "Install as Web App" from the main menu. Like magic, you get a "Lemmy App" that you can bring up like any other app.
This is my experience in GNOME. Presumably though, it'd work with any desktop environment that respects the XDG standards.
That's a good question. I believe there is official text for "GPL-3 or later" that you can use, which should (I just asked the wife to be sure) then let you re-license the project to GPL-4 later. This is probably possible because the "or later" portion of the license text includes consent by contributors for the future change.
That's fair, though if you're looking for something more legally ironclad, I'm not sure I would want to depend on a declaration like that. But you're right, as the sole copyright holder, you can choose to apply your licence any way you like, so long as it's clear (for some value of clear) to the recipient that the software, what the license is.
Interesting. I wonder if this code would fall under the license of the publication then? The blurry line between documentation licenses and software licenses is usually when I stop and go ask my wife :-)
These are fun questions! There's a few other things you have to consider though before you can have some answers.
If the work was done for your employer (non-commercial, academic, or otherwise) you should be sure that your work for that organisation did not include the transfer of ownership of the work you create to said organisation. Most organisations that employ people to write software usually include a stipulation in your contract that anything you create "in the course of your employment" (this is a legal term meaning work you do for your job as well as work you might do related to you job as inspiration/necessity for your job etc) is owned by the employer. If that's the case for you, you can't simply re-license the software, even if it's already publicly viewable. You need to seek the consent of the copyright owner to either (a) transfer the ownership to you, or (b) agree to a new license.
Which brings me to the first thing people tend to forget about copyright: unless otherwise stipulated (like through the inclusion of a LICENSE file) all creative works are copyrighted and cannot be copied, imported, modified, distributed, etc. without the express consent of the copyright holder (usually through a licensing agreement).
So with that in mind, and assuming that you already have the copyright to this code, I'll answer your three questions:
1. Can I just add a license after the fact and it will be valid for all prior work?
This is fun question because it hinges on a silly technicality of software development. If you add a license to your repo today, the license applies to the code as of that point in the commit history. There's no official way to say (through the standard of including a file in the repo) that this license applies retroactively, but if you're the sole copyright holder (see notes on this below) of the work in its current state as well as everything that came before (ie. you didn't get PRs from other people thinking they were committing to a project under a proprietary license) then practically speaking, you can apply a Free license to all the old versions because you're the copyright holder -- you can do whatever you want. The problem is a practical one: without a LICENSE file, it's not clear that this software is Free.
Unless you've got a bunch of other people/teams/organisations working off of forks of your current codebase though, it's really just a thought experiment: no one will care because the latest version is Freely licensed. Someone could conceivably fork your repo from an earlier point in history, but without a LICENSE file in that fork, legally speaking that code is solely your property, so copying it would be illegal unless you made a copy for them with a LICENSE file included.
2. Do I have to make sure the license is included in all branches of the repo, or does this not matter? There are for instance a couple of branches that are used to freeze the state of code at a certain time for reproducibility’s sake (I know this could be solved in a better way, but that’s how it is).
There's a lot of overlap here with #1. Basically your old release branches will be copyrighted by you and not licensed Freely. If it's important to you that these releases also be under your new Free license, then yeah, you're going to have to include a new commit on each release branch with your LICENSE file. Personally though, I wouldn't bother. If anyone is using an old release, they'll get the Free version once they upgrade and that's usually good enough for most people.
3. I have myself reused some of the code in my current work for a commercial entity (internal analysis work, only distributed within the organization). Should this influence the type of license I choose? I am considering a GPL-license, but should I go with (what I believe to be) a more permissive license like MIT because of this?
So much of this centres around the current ownership of all code in the repo. If this were a personal project into which no one but you has ever committed any code and for which there's no existing contract stating that your-employer-not-you owns the code, then the answer is really simple: it's your work, you can do whatever you like.
For example, you can write a program, license it under the AGPL3, and post it on GitLab for all the world to see. Strangers from the other side of the planet can download it, modify it, and run it in their own projects so long as they adhere to the AGPL3 license. So long as you don't accept any merge requests from anyone else, you can also re-license the code (or a portion thereof) to a private company (your employer, a contract gig, whatever). Remember, it's your code, you can do with it as you like, so if you choose to give it to a company to build into their proprietary project, there's no problem.
The problem comes once you accept code from someone else. If I submit a merge request to your project that fixes a bug, I do so under the terms of that project's license. My code is AGPL3 because the project's license is AGPL3. You can't now take my bugfix and copy that into a private project because I didn't grant you that right. This is why re-licensing a Free software project, even from GPL-2 to GPL-3 can be really painful: you have to contact each contributor and acquire the right to change the license.
So, TL;DR: if it's 100% your code, you can make 10 copies, all under different licenses. Do whatever you want. If it's 99% your code, you're bound by the license in affect at the time those other contributions were made.
[Source: I'm a Free software nerd with a penchant for copyright, so much so that I married a copyright lawyer so we talk about this stuff a lot.]
When I stepped away from my own (mildly successful) Free software project, I had the same concerns: it's about the reputation.
The project had earned a decent amount of trust when I was running it, and presumably people were installing new updates without going over the changes. If I handed off the project to someone new, I wasn't just handing over the work, but that trust as well.
So rather than handing over the project to someone new, I archived it and someone else (thankfully someone not-evil) forked it. Anyone installing the fork immediately understood that the relationship was new. They'd have to decide whether to trust this new maintainer or not.
For my money, this is the way. If you're burning out, remember that your reputation is tied to your project name, and that it has considerable value. If you don't want to continue, the disruption of a fork is better/safer than the smooth-but-risky hand-off.
You can always just reset your git history:
$ git reset [your first commit hash]
$ git add .
$ got commit -m "Collapse git history"
$ git push -f
Why didn't this become a thing? Surely in 2024, we should be able to build packages from source and sign releases with a private key.
Not all of the EU. I understand Ireland is very vocal about doing the right thing.
Germany on the other hand seems wholly in capable of being on the right side of a genocide.
It's the tight coupling between the government and arms manufacturers. I used to work at UKTrade and nearly every decision there was rooted in how we can give more money to arms companies.
Are they refusing patches, or are you just expecting people to do what you want for free?
I rather like the FSFe for general Free software stuff, but you may find nicer-looking stuff if you visit merch store for specific projects, like GNOME, KDE, etc.