this post was submitted on 01 Apr 2024
38 points (93.2% liked)
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
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Thanks for your answer.
OK, in that case it may not even make much sense to add a license. There will be no added code to this repo in the future, so there will nothing the new license would apply to.
Yes, you kind of answered this in question 1. Since it is not retroactively applied, it won't apply to the stale branches that only exist as snapshots of the code.
Good point. This is not included in any software that is distributed, it is only a smaller part of an internal codebase used for data analysis. Does that not change things? But to be on the safe side, it would probably make sense to make it as permissive as possible to avoid any issues here. But then again, if it is not applied retroactively then nothing of the code used will be subject to any license. But good thing to remember for the future.
Also not a lawyer, but you can also grant exceptions to the license (if you're the sole owner of the code), so you can license code one way and let a certain org use it another way.
Which is essentially already what's happening. The default "license" of something is that you have full ownership and no rights are given to anyone else. You've essentially give your company an exception to use it for that project.
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.
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!
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.
I suppose it makes sense if it originally had a license, and you then change the license to be less permissive.
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).