Open Source

31236 readers

433 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Posts must be relevant to the open source ideology
No NSFW content
No hate speech, bigotry, etc

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago

MODERATORS

[email protected]

Adding license after some time with no license? (lemmy.ml)

submitted 7 months ago by [email protected] to c/[email protected]

18 comments fedilink hide all child comments

I have previously written a lot of code that is hosted on a public repo on GitHub, but it never had a license. It was written as part of my work while working for a non-commercial academic entity, and I would like to add a license before the link to the repo will be included in something that will be made public, potentially attracting one or two visitors.

This leaves me with a couple of questions:

Can I just add a license after the fact and it will be valid for all prior work?
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).
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?

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 2 points 7 months ago (3 children)

Either you misunderstand or the person you are responding to is. If you retroactively add a license to the current state of the code (for example by committing a new LICENSE file and adding the new license to the top of each file), or course that applies to the entire state of that code as of that commit. What is more difficult is that earlier commits won't have that license explicitly unless you rewrite git history to make that happen (which is possible but tedious).

You can always relicense code you own the rights to. You can even dual license it, or continue to use it commercially in terms contradicting the license you open sourced it as, as long as you have the permission of every contributor.

The idea that a license added would only apply to code added after the license change is very funny.

[–] [email protected] 2 points 7 months ago* (last edited 7 months ago)

Either you misunderstand or the person

Yeah to be clear, I wasn’t suggesting you can’t change the license at all, or it requires code changes or whatever.

You are completely free to apply whatever license, and use that going forward without changing the code at all.

And like you have correctly pointed out, you could rewrite git history, or even just remove all prior versions of the code.

I am of course happy to be wrong or have misunderstood something- I am absolutely not an expert and would like to be corrected if I am wrong!

[–] [email protected] 1 points 7 months ago

unless you rewrite git history to make that happen

Or just write an external document saying that all files in all previous revisions are available under whatever licence. There is nothing magical about a licence notice at the top of a file. It is just helpful documentation of the license. But you can document a licence anywhere as long as you are the owner of that code.

[–] [email protected] 1 points 7 months ago

The idea that a license added would only apply to code added after the license change is very funny.

I suppose it makes sense if it originally had a license, and you then change the license to be less permissive.

What is more difficult is that earlier commits won’t have that license explicitly unless you rewrite git history to make that happen (which is possible but tedious).

I will probably not do that, but I guess it factors into my second question: That I in that case should make sure to include it in all branches (which are not treated as branches in the common sense, but rather as forks within the repo - they will never be merged to the main branch).