this post was submitted on 02 May 2025
87 points (97.8% liked)
Programming
20017 readers
244 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Avoid at all costs CC0. CC0 explicitly does not give patent rights. MIT implicitly does.
A good reason to pick GPL is if you want to allow GPL software to integrate yours and you don't care that much about the AGPL clauses (e.g. because your app isn't a server).
CC0 might be a good fit for trivial template repos where you don't want to burden downstream projects with having to include copyright notices.
I've been thinking about this recently... Let's say you develop some local CLI. You think it's not a server, so you license as GPL.
Later someone comes and offers your CLI as SaSS. They write the server piece that just calls your local CLI on their server and pipes the input and output between the user.
So... should you always prefer AGPL over GPL?
I have thought about this a lot and done some research on it. Bear in mind, I'm far from an expert, just a curious dev, but I've found no reasons to favor GPL over AGPL when AGPL exists. I personally see AGPL as closing a loophole GPL didn't think of.
One thing I'd wondered if if maybe AGPL hasn't been tested in court. It has. Not as much as GPL, and I don't remember if it specifically was the online part, but I definitely found at least one court case involving AGPL code.
Absolutely not! Avoid CC0! Stop spreading bad information. If you want a public domain dedication with fallback permissive license the best choice is (sadly) The Unlicense. It is the only public domain dedication with fallback permissive license approved by both FSF and OSI. It's unfortunate because The Unlicense is still a crayon license.
If you don't want to burden some stream projects with including copyright notices, just don't enforce it if you find people who forgot.
https://www.gnu.org/licenses/license-list.html#CC0
"just don't enforce it" probably isn't enough for most companies and projects
If your company won't let you use MIT licensed software I don't know what to tell ya. If your company won't let you use MIT code, which FSF and OSI endorse, but will let you use CC0 code, which FSF and OSI do not endorse, then I really don't know what to tell ya.
AGPL and GPL v3 are explicitly compatible, IIRC. You can run into some trouble with v2.
What I mean is that you (IIUC) can't use an AGPL library in a GPL app without relicensing the whole thing to AGPL. For many larger projects relicensing is a huge hassle and often a non-starter if there aren't very good reasons for it.
You're right, the explicit permission is only the other way around.
The license seems to be targeted towards languages like C/C++. On the other hand, languages like Go do a lot of static linking, so it may be impossible to comply with this license in Go.
MPL may be a good alternative here.
Nah, so long as the folks using the LGPL code provide everything necessary to use a different version of the LGPL part of the code, it doesn't actually matter if it's static or dynamic.
http://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
Yeah, I think this is the hard part with Go. I've never seen anyone do anything with objects in Go. Everything is compiled into 1 binary, often statically linked. I'm not sure it's possible to build a Go binary by using object files.
So, you could release the source but with the standard "all rights reserved" of copyright and let people compile it with a different version of the LGPL lib, but not let them modify or redistribute the proprietary Go code you've written to use it. It sounds counterintuitive because the source is "available" but this is how proprietary JavaScript code works in browsers to. It's there, you can read it, but it doesn't automatically mean you can "do" anything with it.
So yeah, distribute your Go binary with access to your Go code and instructio on how to compile it and you should be good, unless I'm missing something obvious.
Well, for specific licenses there are use cases for MPL, which is weak copy left. LGPL is trying to state that statical linking is not allowed, while MPL does. Also, EUPL have simmilar advantages over AGPL, plus that it have very clear defined legal juristiction. So, when it comes to specific licenses there are many reasons to use whatever licence you use. Just make sure you use a license that reflects your expectations.
You can statically link LGPL code so long as you provide the end user instructions on how to use a different version of the LGPL portion of your code.
http://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
MIT - only good for tiny weekend projects like Xorg, Wayland, Mesa, Godot, Jenkins, MUSL, Node.js, Angular, Vue.js, React, Rust, Julia, F#, Rails, PyPy, Redox, and the Haiku Operating System.
AGPL - good for serious projects that you want to be super successful. Widely used software that started off as AGPL includes………. uhh……..wait…….ummm……. lemmy and Mastadon I guess?
Oh, I'm so sorry I believe projects should use more explicit licences over short ones like MIT. Apache is just more explicit than MIT. The only benefit I see MIT having over Apache is if your code base is so tiny that the Apache license like doubles the file size.
I believe a lot of devs value MIT because it is simple, but that doesn't necessarily make it good. Sometimes code needs to be complex. Licences are the same way. Prefer explicit licenses written by lawyers over simplistic licenses and crayon licenses.