I should have thought about GPL when I released the code.
But, that boat has sailed.
Could they change the license later on if it is initially GPL?
I'm thinking about the next project that I'll be doing so that I don't repeat the same mistake.
A huge part of that is how to structure an open source project so that it can't be taken from the community. Basically a combo of GPL and taking community contributions without having them assign copyright to you is the most full proof way to keep something open source.
To answer your question, if they own everything they can relicense it any way they see fit. Only by having your code mixed with others' that you don't own can you practically protect it from forced relicensing.
> Basically a combo of GPL and taking community contributions without having them assign copyright to you is the most full proof way to keep something open source.
The Wikipedia article about Contributor License Agreements cites this article by OSS Watch, http://oss-watch.ac.uk/resources/cla. This is the first time I’ve heard of OSS Watch, but they might be a helpful source of legal advice based on their About page, http://oss-watch.ac.uk/about/
Opinions differ on CLAs. There are certainly arguments for them as laid out in that article.
There are also arguments against them in many cases, including that they create friction for new contributors. "Oh, I have to sign this agreement which means talking to my company's legal staff? I think I'll just pass."
The parent is also probably right that GPL with no CLA makes it much harder to change a project's license. This actually came up when GPL v3 was released. As it turned out, Linux apparently didn't want to change Linux from a v2 to a v3 license. But there were also legal questions about whether he could do so by himself even had he wanted to. (Though Eben Moglen argued at the time that he maybe possibly could have for various arcane reasons.)
Your podcast is very good! I recommended the series to a friend who manages an open source project. Looking forward to your other interviews.
In the podcast episode, the guest does mention people are moving away from CLAs. He goes on to say projects are adopting a “Developer Certificate of Origin” model. I found an article that helped me start to understand differences in these models: “CLA vs. DCO: What's the difference?”, https://opensource.com/article/18/3/cla-vs-dco-whats-differe....
Thank you for the citation. I’ve added that episode (and the rest) to my listening queue & look forward to your other episodes too. Looks like a cool podcast!
A CLA isn't necessarily a copyright grant. The Apache one for instance doesn't have you assigning copyright to the Apache foundation. It's just signing that you actually own the works in question.
I have issues with the GNU assignment. It means that we're reliant on future owners of the GNU project to not ever relicense the codebase. A single owner is a single point of failure.
I've heard that sort of thing called a developer certificate of origin or something along those lines.
The FSF is arguably something a bit unique. But most of the point of a CLA is to give a company/organization ultimate control over a code base so that it can dual license, etc.
The copyright holder can change the go-forward license at any time. The license doesn’t restrict the copyright holder, it restricts everyone else.
Your employer isn’t seeking a copy of your Apache 2.0 code, which they already have, they’re seeking transfer of copyright ownership.
It really does sound like you’d learn a lot from talking with a lawyer, maybe one recommended by an open source foundation. Lots of lawyers have a first meeting is free policy, so schedule meetings with a few lawyers. Pick the one you like best, or pick none.
