this post was submitted on 02 May 2025
87 points (97.8% liked)

Programming

19985 readers
225 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
snowe
Ategon
[email protected]
87
Licenses are boring but you really need one! (distractedmind.home.blog)
submitted 3 days ago by snaggen to c/programming
29 comments fedilink hide all child comments
 

It seems people have a hard time understanding the implications of licenses, so I have written a something to help with that.

top 29 comments
sorted by: hot top controversial new old
[–] JackbyDev 38 points 3 days ago (4 children)
  1. AGPL. Strictest. You want a strict license. Don't let people take advantage of you. I see no good reason to pick GPL when AGPL exists.
  2. LGPL. If you want people to be able to use it (but not modify it) without their code having to be FLOSS as well. Still quite strict relatively with everything below.
  3. Apache. Permissive license. If you really want a permissive license, this is the one to go for.
  4. MIT. Permissive but less explicit. Okay for super short code.

Avoid at all costs CC0. CC0 explicitly does not give patent rights. MIT implicitly does.

[–] [email protected] 10 points 3 days ago (3 children)

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.

[–] [email protected] 4 points 3 days ago* (last edited 3 days ago) (1 children)

you don’t care that much about the AGPL clauses (e.g. because your app isn’t a server).

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?

[–] JackbyDev 2 points 3 days ago

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.

[–] JackbyDev 3 points 3 days ago* (last edited 3 days ago) (1 children)

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

If you want to release your non-software work to the public domain, we recommend you use CC0. For works of software it is not recommended, as CC0 has a term expressly stating it does not grant you any patent licenses.

Because of this lack of patent grant, we encourage you to be careful about using software under this license; you should first consider whether the licensor might want to sue you for patent infringement. If the developer is refusing users patent licenses, the program is in effect a trap for users and users should avoid the program.

[–] [email protected] 1 points 3 days ago (1 children)

"just don't enforce it" probably isn't enough for most companies and projects

[–] JackbyDev 3 points 3 days ago* (last edited 3 days ago)

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.

[–] Colloidal 1 points 3 days ago (1 children)

AGPL and GPL v3 are explicitly compatible, IIRC. You can run into some trouble with v2.

[–] [email protected] 2 points 3 days ago (1 children)

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.

[–] Colloidal 1 points 3 days ago

You're right, the explicit permission is only the other way around.

[–] [email protected] 4 points 3 days ago (1 children)

LGPL

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.

[–] JackbyDev 2 points 3 days ago (1 children)

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

[–] [email protected] 2 points 3 days ago* (last edited 3 days ago) (1 children)

If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

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.

[–] JackbyDev 1 points 3 days ago

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.

[–] snaggen 3 points 3 days ago (1 children)

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.

[–] JackbyDev 2 points 3 days ago

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

[–] LeFantome -2 points 2 days ago (1 children)

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?

[–] JackbyDev 1 points 2 days ago* (last edited 2 days ago)

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.

[–] Colloidal 20 points 3 days ago

I like how you describe the Don't Care licenses, aka permissive licenses. A lot of people fall for the narrative that more strict licenses are a burden for other open source developers, and then regret their decision when Evil Corp does what they usually do.

[–] [email protected] 9 points 3 days ago (1 children)

About the part on SaaS, the outcry is solely because the licences used by those projects weren't approved neither by OSI or the FSF, they have clauses that specifically affect the economic aspect, and that can never fit in with either movement, but it is exactly that problem that the software authors want to tackle, preventing big corporations that already have the means to deliver a large scale service based on their software from making even more money than they already have, even if those corporations published possible modifications, the author would benefit little, because they most likely won't have the infrastructure to run it on at the same scale and profiting from it.

Hot take: the real issue there is that those authors clearly don't care for free software, because if they did, they'd have started off with AGPL or the like, instead they choose MIT exactly because of the possible economic prospect for themselves, when at some point they could implement vendor lock-in by baiting the users into believing that it was a community-run project at the start. Don't get me wrong, they deserve to be paid for what they do, and corporations dropping by to profit from all that hard work feels wrong (but not illegal, and so it is fair), but exploiting the visibility and help of the community to reach popularity and credibility and eventually going private is a major dick move

[–] [email protected] 3 points 3 days ago* (last edited 3 days ago) (1 children)

For your second part:

A lot of open source projects exist to make people's lives easier at work. The people developing these projects are often also people who have jobs as devs and have a use for the projects. It just so happens that it's easier to use these libraries at work and share them with others when they're more permissively licensed, and there are community benefits when people all contribute back to it.

There's nothing wrong with wanting to go the AGPL route and forcing everyone into open source, but that makes it much harder to use these tools at work, which often kills the motivation behind building them in the first place.

I tend to be of the opinion that community tools should be GPL/AGPL, while libraries can be anything. It works as a compromise for both - so devs can have an easier time at work while also forcing contributions back to community-developed tools.

Edit: I should also mention dual licensed AGPL/paid commercial. That model is probably my favorite, but unfortunately uncommon.

[–] [email protected] 2 points 2 days ago

Fully agreed, though I must say this, if you truly believe in the spirit of free software and, let's also be honest and add, can afford not to bend for the convenience of others (maybe you get funded through donations and/or grants), then you have the opportunity to make a piece of software so good, be it application or library, that it'll be hard for competition to come up with something better and proprietary, that's how it is for those instances where companies were sued for using them and not providing the source, e.g. Linux and John Deere is the last I remember.
It is that nature of copyleft that the more it spreads, the more it will enable for a culture shift, when people are faced with the inevitable conflict of the idea of keeping everything behind closed doors and not being allowed to if they want to take the easy way out, they might give it an actual thought or they'll try to be unfair and use without giving back, showing their true greedy colours. I'm not a purist by any means, as much as I'd like to, but that is the kind of world I'd like to live in

[–] onlinepersona 6 points 3 days ago* (last edited 3 days ago) (2 children)

I've been thinking about using business source license for my projects. Fuck MAGAF and other companies for taking advantage of opensource devs, making billions and not wanting to contribute back or even support the dev.

Once the Post-Open license is finalised, there's a good chance it'll become my default instead of AGPL or BSL.

Anti Commercial-AI license

[–] [email protected] 1 points 3 days ago* (last edited 3 days ago)

Oh, interesting. Bruce Perens (co-founder of the Open Source Initiative) was involved BUSL (BSL) and Post-Open.

[–] [email protected] 1 points 3 days ago

TIL about Post-Open license. I've also been looking at BSL and FUTO's Source First license.

[–] Kissaki 4 points 3 days ago (1 children)

https://choosealicense.com/

[–] snaggen 2 points 3 days ago (1 children)

These are good in a more hands on way, but it is hard there to understand the conceptual difference between MIT and EUPL. So, I deliberately didn't go in to the details, since there are a lot of tools for that. I aimed for a higher level, since I find people often have missed that.

[–] Kissaki 3 points 3 days ago

I just wanted to add an additional resource related to the topic.

[–] Kissaki 3 points 3 days ago* (last edited 3 days ago)

There's a lot more variance in the specifics, but I think for an overview like this it's certainly missing dual-licensing and "business-open" licenses like "readable but limited now, but free software two years from now".

But I guess with the specific target audience of this post the reduction for simplicity is a good thing.