Not to discount the feelings of others, but in a sense I only wish I could have these problems.
Not to discount the feelings of others, but in a sense I only wish I could have these problems.
I don't care about monetization or $BIG_CORP's fascination with it. I developed this thing to stay open. It's not up for grabs.
xGPL family of licenses force contribution back of improvements, and rightfully, it's not about developer freedom, but user freedom.
Most commercial products just write some useless statement like "this software may use open source components" or include a generic MIT license without the original copyright holder statement inside.
Who is telling these companies they are doing it wrong?
Very rare when someone ever does.
These kind of things take several months of efforts by deep expert, when it is done by normal open source developers who think they know about licenses and compliance, it tends to result in poor results even if the output looks "big" from a surface view.
Nor requires them to give anything back.
Putting your code in MIT license is basically slogan "take all of it and give nothing back". Which is why so many corporate developers push for it, no lawyer to talk to when you take MIT-licensed code to use in your project.
> much unlike open-core GNU licenses that promote CLA-s and thwart any competition.
There are no "open core GNU licenses". It is just perversion of the idea and abusing the fact some of them are not restrictive enough that you can still have paid parts that are closed source
The copyleft licenses don't require to give anything back either, they only require to give source code forward to downstream users, who may or may not contribute back upstream to the original project.
If your stuff is complex enough, then it should be easy to outcompete any improvements made by organizations. SQLite, for example, has multiple proprietary tests [1]. Corporations can try to improve on SQLite, but without these tests and the knowledge of Richard Hipp on their side, it will most likely fail.
Deploy if you dare: https://github.com/readthedocs/readthedocs.org
To maintain open source over a long period of time, some durable competitive advantage is probably required yes. With such a moat, competitors can be beaten. Luckily, being open source is also a small moat since it avoids vendor lock-in and some businesses need vendor lock-in to survive (I'm looking at your SAP).
> If Richard gets hit by a bus, and the community tries to keep the project alive according to free and open-source principles, then they’re going to face all the same barriers that a corporation would :/
The project sits inside Richard's company and the company has some other engineers working there.
Personally I go the (A)GPL way all the time.
Yes.
> There is nothing inherently wrong in both positions.
Also, yes.
Hope more people understand this clearly.
> Personally I go the (A)GPL way all the time.
Me, too.
As a developer and end user I cannot use a lot of software because it's compiled into closed source stuff or in locked down devices, thanks to MIT.
On top of that such software and devices are even spying on me. While I'm busy contributing to FOSS for free.
Making the code anything but MIT just means it’s not used at all, not that companies will suddenly start publishing their source code.
The "commercial entities" built 99% on stuff that they got for free ?
How about they keep their 1% of the stuff that was made wholly by them, but give back the 1% of the code they changed in 99% they took ?
No. But GPL at least gives me the ability not the be a cow to be milked and then butchered.
> Making the code anything but MIT just means it’s not used at all, not that companies will suddenly start publishing their source code.
If freeloaders don't use my software it's still better than nothing.
Also bugs due to "I didn't bother to read the documentation".
Also legitimate bugs with the attitude of "my production env is down because of this, so fix it at once".
The entitlement is strong.
But for larger, more complex projects that have significant skill -- projects that might take man-months to man-years for someone else to replicate -- I tend to want to use copyleft licenses.
And its unsustainable model of development. You need contributions and developers willing to help with maintenance and development otherwise your project will stagnate and no one will use it(xfree86).
I see only one case for permissive licence use, a reference implementation of something. Where it's purpose is for people to take it and incorporate it into their codebase without any changes(or minimal). It have problems with vendors taking source and extending it with their secret sauce(Unix wars, Kerberos(?)) but advantages are greater than potential abuse.
Maybe also a case when you drop code and run in other direction(with no or minimal maintenance). It's not great development process either.
>Right now, 99% of what I write ends up MIT because I just want the shortest and most permissive license for others to use what I create without bothering me.
You still need a lawyer evaluate any licence even short ones. Short ones have problem that they leave more to interpretation/relie more heavily on copyright law/patent law/their interpretation can widely differ based on jurisdiction etc.. So while they can be shorter, interpretation can be as hard as long ones. Especially if copyright owner is hostile.
> Not to discount the feelings of others, but in a sense I only wish I could have these problems.
You started comment with desire for others to use your software. But people won't use it if it's stagnating, lacks features or is unreliable. Especially if proprietary fork covers this problems. To stay relevant you need contributions and development time. And getting contributions can be hard if licence doesn't enforces giving back.
On the other hand, if they take my code and make some changes to it, and then sell access over a network, I want those changes to be brought back upstream.
So to me, something like ALGPL (does that exist?) or A-MPLv2 would be ideal. Then again, I mostly write computer vision pipelines, which are very much on the library side.
When people refer to "MIT License" they usually mean the Expat License:
> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
So ... I must include the license code when I redistribute the binary of the software?