Do you ever think.. I wish I was a legally smart in fact I wish there was a tool to just describe my project and get the right license. Anyway, do ...
For further actions, you may consider blocking this person and/or reporting abuse
I have recently started to study licenses and pretty much end up choosing AGPL for serious projects and MIT for others.
This Tool always helps me ufal.github.io/public-license-sele...
Also have a look at tldrlegal.com/
Another great suggestion thank you so much!
For Java libraries/frameworks Apache License, Version 2.0 is practically a default standard. Rarely there are some MIT-licensed libraries (usually small ones). GPL-derivatives didn't get any sensible attention since they are not commercial use friendly.
That's very useful to know thank you, I will look into the Apache License and see what projects it might suit me.
With dev.to (now named forem for the underlying software, soon to be reflected more officially), we believed pretty strongly that AGPL accomplished what we wanted in terms of encouraging and enforcing transparency across the network. According to our license, you can't make changes that you don't inform the end users of.
This means if you wanted to sneak in any extra tracking or anything you have to publish the new stuff. No way around it without expressly breaking a widely-used and established software license.
In this sense we want clear restrictions in place. However, we've pledged to make any smaller libraries we release MIT unless something else is specifically needed—because that's just the less onerous approach. It would certainly make our lives more difficult if all the Ruby Gems and npm packages we tried to import had restrictive or complicated licenses.
Thank you Ben that is very useful info as a potential strategy, I like the explicit requirement to notify the copywrite owner. Could you refuse a change, I would imagine so, what about prevent a forem client from using your software?
It's interesting, something that's always been an afterthought to me could have huge implimentation if I choose poorly. Kind of like that iniana Jones movie.
We can't force someone not to modify the software (that would not fly in open source land very well), but by ensuring they publish changes (copyleft), we can try and ensure a healthy open source ecosystem and transparency to the end user.
Because they need to publish changes, we could deem that an individual forem is not appropriately compatible or aligned with our values such that we could make the choice to not offer support.
In general we hope our software is useful as is and if someone needs a change they're able to commit back upstream, but we'll see how things shake out.
Sorry I tend to talk in extremes. I have to admit I'm really just getting into the true meaning of open source and what it means to foster an open source community.
For me, I'd like to have a license that allows anyone to modify my software but not be able to sell it unless credit was given. That kind of leads into, how do licenses get created in the first place, could I just write one on the back of a napkin?
There are licenses that would restrict commercial use or restrict use on really any terms. An yes—licenses are essentially created on the back of a napkin. You can create them out of thin air. The questions tend to be around are they legally enforceable? And in that regard it's nice if they've been around long enough to stand up to scrutiny or evolve based on challenges.
Not all legal documents are truly enforceable, and you never really know until you wind up in court. But this is why people tend to try and choose licenses that a bunch of other people are also relying on. It's sort of like strength in numbers. If the whole world decided on a shared understanding of something and nobody really challenged that for a while, it holds a lot more weight than if you whip something up out of thin air and say this is the way things are.
Soooo you probably don't want to go totally on your own, but if you poke around you can find a license for pretty much any use case and you're best off picking stuff that other people are using for a bit of strength in numbers.
A bit off topic but when you react to my posts I tend to get floods of reactions, do you have super admin powers? I'm not licensed to know I guess. Thank you for taking the time, I have certainly got some jumping off points and I hope this helps other people too, great answer.
Well as a mod, I can send an extra "thumbsup" which gives the post more visibility. Most likely has to do with that?
Ah yes I can do that too. Thanks for clarifying.
And as a super admin, when I or other folks take these actions, they have more impact. It's a complicated system, but you can see in general how it works in the code 😄
The other thing to consider is the impact of your license has on build your community and adoption by business. I’ve worked with open source on the enterprise side for over 15 years and licenses matter to them so if adoption and usage by that segment is important to you tread carefully. It’s just one of the many reasons choosing an OSI license helps as increasingly business understand and trust those licenses. Rolling your own just ends up becoming a blocker.
I’ve seen this be a real issue for some small companies that built up their IP and where the exit strategy was to be acquired only for the due diligence to kill that acquisition because of poor license choices.
So think hard about what you want to do as a business, what your current and long term business plan is and then decide.
I have had so many fantastic responses, thank you for taking part. I suppose the first thing I will do is review all my repositories and take them case by case.
There is a default???
I know that
npm init -yandyarn init -ydefaulted toISCandMITrespectively, though. But I don't think GitHub has default, unless you explicitly create one.Indeed from what little attention I have paid to this subject it seems GitHub and npm default to MIT which got me thinking why is this default and what does it all mean?
When in doubt start with a license with the highest protections/restrictions (i.e. GPL or AGPL). When accepting contributions do it under the condition that you can change the license in the future to a lesser restricted open source license (e.g. Apache, MIT, BSD, LGPL, ...).
That's another wonderful perspective, I had fears this might be a turnoff or maybe not. I wonder if it is possible to be analytical about this topic. success (adoption rate) / license?
Licenses are so confusing for me since I am not, at all, able to read legal documents. I usually go to choosealicense.com/ to help me make an informed decision. It makes some quick summary notes on different licenses. Really helps break down what they do and how they are used, for my purposes. I would recommend it if you are trying to choose the right open source license.
Snap, that's great advice thank you!
So I just read about the MIT license, it says that a project could be forked and closed sourced and even sold... I'm not super happy about that.
I believe pretty strongly in MIT licensing; I use libraries all the time that would be impossible to consider under any kind of restrictive non-commercial or copyleft provision.
I pretty much always release software as MIT or closed source proprietary.
If there's a chance I can make something available to the community, then I am super happy if someone uses that to help them make a living, they can do what they like with it. My Unity libraries ended up in thousands of projects, and that makes me glad to have given back something in exchange for the benefits I've had from open source. If it's the core IP of my work projects, then it won't be going public, but anything on the periphery is up for grabs.
That said, it makes total sense for full platforms like Forem to be licensed AGPL for the very compelling reasons Ben mentioned.
That said, my head of legal had a bit of a wobble when I pointed out we had included modules using the wtfpl.net/ but hey ho.
Yup, if you want to be restrictive at all, MIT is literally antithetical to that.
MIT, on the other hand, is kind of nice when it's Facebook releasing a project. In that case it's probably a good thing that there are no restrictions. React was first released with some onerous restrictions that Facebook's lawyers cooked up and public pressure forced them to go MIT with it.
But be aware that the MIT/BSD license does not contain a patent grant. Using a MIT/BSD licensed product can still result in you having to pay the company for using the library.
This problem does not exist with, for example, the GNU v3 licenses, or the Apache License v2.
As far as I care, there are 5 licenses:
with a side-note that GPL/LGPL allow you to re-integrate 3rd party improvements back into your code without issue. So for projects you intend to maintain and improve for a longer period of time it is probably better than MIT.
Sweating the differences between MIT, BSD3, etc. seems like a waste of time and sink for happiness. Worst case scenario, somebody uses something I made in a way I don't want them to, I don't have to let that affect me.
Excellent advise and breakdown thank you 👏
Is your software more like a library or more like an end-user application? You derived that probably already from all the other answers, but if you want some adoption, then the more low-level, the more liberal is probably a good rule of thumb.
Think of a 3D game, and all the textures, pulled in from numerous sources would require attribution. You could basically hire some person just to manage that list.
Sorry for my just tangential related examples, but I have a slightly different background here. Next example is blender. Everyone can download a blender build, swap logo and name, hide the GPL text as deep as possible in some folder and sell it. People actually do so now and then, but most likely this is not a very successfull business (there are no numbers about that, obviously).
Restricting commercial usage can be difficult. I am referring to the CC "no commercial" clause. It can be interpreted very strict in court. Like, when the website where to download contains ads, it is already commercial.
And use a default OSI-accepted license, no extra bells and whistles. This leaves a bad impression and people steer away from it because you create some uncertainty by doing so. Examples of how not to do it, are Defold Game Engine and NeoAxis Game Engine (recent examples).
I am totally amateur about that stuff, so please take everything with a grain of salt and collect more opinions.
One question at the end: Let's say you find a nice MIT-licensed lib on github and you are in evil mood and want to make money of it - Would you know how? Is it even reasonably possible? Could you steer traffic away from github to your own shop site, when people search for something-like-your-lib?
I tend to makes libs. I mostly never finish them so they often just sit around. I am pulling in more and more code from others to make my things work so I suppose, how much do I actually own. I guess only the glue code. Anyways I suspect you are correct, can you make money from free stuff?
Well I know an example of this which maybe doesn't fit our world. The fashion watch industry sells watches for 100s of (insert currency) but buy the watches from Alibaba for around 2% of the markup, all they do is brand them and resell them, I suppose that sort of thing goes on in our industry too, who knows. Anyway thanks for taking part in this discussion!
When I write for an ecosystem (e.g. a plugin for some tool, or a lib specific to a given toolkit/framework) and don't really care, I just adopt the same license as the thing I'm building upon/for.
For a Maven or Gradle plugin (and most Java projects) I pick up the Apache License, for a Go library the "New BSD 3-clause".
For bigger projects, I'd be more cautious. For Ozwillo and Ecometer (both applications), we selected the AGPL as it prevents others to "steal" your work and just resell it under another name. For iTowns (a library/toolkit), we selected the MIT (actually dual MIT and CeCILL-B, see below) as we wanted something very open that would specifically allow us to embed it within applications, including modified versions of it.
Also, in France, we have the CeCILL licenses. CeCILL, also called CeCILL-A, is pretty much like AGPL; CeCILL-B like BSD/MIT, and CeCILL-C like LGPL (as a mnemonic, I think of the C as standing for Component; so you have A-B-C ⇔ AGPL-BSD-Component). They're almost the same as those better-known license, except they're written with French laws in mind.
And in Europe, there's the EUPL which is similar to the AGPL (for EUPL 1.2, previous versions were GPL-alike).
Last, but not least, have a look at Contributor License Agreements in addition to licenses (most corps have one, the Apache Software Foundation and Eclipse Foundations have one, many other open source projects don't) :
Just go with GPL or LGPL - easy well known and understood.
If you actually to control what is going to happen to your software the only option it to keep it locked up on an encrypted drive buried under 2 metres of concrete (on a remote island). Anything else is just being hopeful that other people will do the right thing.
I only really cared for my small rust library. Decided to go with the same dual licensing as rust itself, MIT and a pop Apache. Unless you plan to make money with it, MIT seems a good choice.