Knowing how to fix my wife's computer, or my parents' computers, or my brother's.
Actually, while it's rather frustrating for them, it's not so bad for me ;-)
Actually, someone did, changing the name to "Glimpse". They announced it as an explicit fork that would continue development under the new name.
As far as I know, that's as far as they got.
What cowards we are.
Because post is more than just letters, it's parcels too. Canada Post is infrastructure that ties the whole country together, not just the denser, more profitable cities. Imagine if there were only for-profit postal services in the country. What would it cost to send a parcel to 100 Mile House, or Baker Lake, or whole swathes of the country that only speak French? Think of all the things that go out by post, like Carbon tax rebate cheques and voting information. It'd introduce a massive disparity in service and access to basic services, and so we socialise that cost across the country.
There are always ways to improve of course, but you asked specifically about why the system was socialised.
That's a fair point. So long as it's addressed from a position of "is the community being served well" and not "this should be run like a business". Canada Post has a difficult (and expensive) mandate: to service all of the country, no matter how remote, and the knee-jerk reaction to such headlines is often to privatise which would change that mandate to "earn as much profit for investors as possible".
I'm living in the UK these days, with private post, and private water companies. Things have literally been enshitified, with raw sewage flowing down the river Thames, so I'm concerned when I see such headlines.
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.]
Can anyone else confirm this? As a long time user and champion of Gitlab, this is a deal-breaker for me.
It's not "lifestyle creep".
When I moved from Canada to the Netherlands, my salary stayed roughly the same, but the amount I saved every month exploded. The Netherlands has much higher income taxes, but it should be noted that I also enjoyed some pretty sweet tax incentives as a skilled expat.
The relevant differences between the two environments were:
- In Canada, paycheques come every two weeks. In the Netherlands it's every month, so you have to lean to pace yourself.
- In the Netherlands, your paycheque isn't 1/12th of your salary after taxes. Instead they actually withhold around 12% your salary and pay it out to you in a lump sum partially in December and again in May. You're still getting the same amount, but you're forced to budget on a lower monthly amount, while enjoying bonuses twice a year. I used the bonuses to pay down my Canadian debt.
- The Dutch don't live off of credit cards the way North Americans do. While in Canada you're taught to "build up your credit rating" by using a credit card, in the Netherlands, many people don't even have a credit card. Purchases are typically made with debit cards instead. Unlike Canada, these cards don't apply a fee to your purchase either.
- They also don't really care about credit ratings. Instead, there are laws that restrict you from buying or mortgaging at a monthly cost higher than x% of your monthly income.
- Car ownership is drastically reduced there. While in North America people flip out at the idea of 15min cities and refuse to believe it's possible to live without a car, people do it every day there.
- Finally, and this one may be more specific to me, going out for a meal is a bigger deal there and typically more expensive. Dutch culture expects lunch to be a home made ham sandwich or just a piece of bread, chocolate sprinkles and some buttermilk. Meanwhile I was used to blowing $20/day on eating out for lunch and often went out for dinner too. The amazing quality of food you find at their grocery stores meant that we often collectively bought groceries for office lunch every day, and I cooked at home.
In the space of 2-3 years, I paid off my credit cards (~$10k) and what was left on my student loan (~$12k). Inside of 5 years, I had tens of thousands of Euros in my bank account.
I don't know. I posted it here because CicleCI is a popular tool for Open source projects.
It's absolutely infuriating that a statement like that would lead to demands for an apology.
It's been almost 100 fucking years and yet this is still relevant.
danielquinn
joined 2 years ago
Desktop
Phone