"I released source code under the MIT license and people are now using it to their financial benefit. Who could have possibly seen this coming?"

Why does this keep happening? Why are so may developers blind to this obvious outcome?

▲

dewey 6 days ago | parent | next [-]

MIT was always the easy default that every project used, you just select it from the GitHub dropdown and you are done when setting up a new project. I think you can't really blame people for using it.

Especially when your project is new it's also not often clear that this project will become something more serious later where you have to worry about such things as people cloning your project.

▲

360MustangScope 6 days ago | parent [-]

How would GPL change the outcome?

A lot of people say that it can prevent these situations but from working for large enterprises, a lot of the offerings that are created literally don’t even change the code. Thus they have nothing to contribute and have no obligation to release any source code.

GPL also does not prevent the corporation from building software in front of whatever GPL service it is. Kind of like the Linux kernel, why bother changing the kernel when you can build software in front of it and not change anything and thus have nothing to release.

	▲	redman25 6 days ago \| parent [-]
		Did you reply to the wrong comment? The posters above never mention GPL.

▲

jotaen 6 days ago | parent | prev | next [-]

Why would this be surprising? The MIT license explicitly allows to relicense a project at any point. In this case, the Bear maintainer decided to start off with a permissive license and now exercised their rights to change to a more restrictive license due to changing requirements. To me, this seems actually quite reasonable.

▲

4ad 5 days ago | parent [-]

The copyright holder (the author) is solely responsible for choosing how they want their work to be distributed, and is not bound by any other sort of constraint. They can choose any license at any time, and change their mind however often, and it whatever direction they want. Any previous licenses used (MIT here) bear no effect whatsoever. There is no license in the world (and cannot be) that would prohibit the copyright owner from changing it. It makes no sense, the license terms only apply to the licensee, not to the licensor.

Of course, the author cannot retroactively change the license of any previously distributed work. Anyone is free to fork off Bear from its last MIT code and do whatever they want with it.

So no, the MIT license does not "explicitly allow to relicense a project at any point" (emphasis mine). The MIT license allows licensees to license their derived work however they see fit, it has no effect on the relicensing by the licensor (the copyright holder).

▲

jotaen 5 days ago | parent [-]

Yeah, sorry if my terminology was unclear here: by “relicense” I colloquially meant to say “assign a different license to the project that is applicable for any work from that point onwards”.

> Any previous licenses used (MIT here) bear no effect whatsoever. There is no license in the world (and cannot be) that would prohibit the copyright owner from changing it.

I don’t think it’s that simple. The Bear project appears to have accepted external contributions under the original license, so the project is subject to that license as long as those contributions remain.

It may not be a big practical issue in this case, due to the MIT license being quite permissive, but if the project was e.g. GPL-licensed, the maintainer wouldn’t trivially be able to change the license in “whatever direction they want”. (And by “trivial” I mean without e.g. rewriting or discarding the external contributions.)

	▲	4ad 5 days ago \| parent [-]
		It appears that Bear does not accept contributions[1] and the very few contributors it had in the past only contributed a trivial amount of code[2]. But you're right, relicensing requires the approval of all copyright holders, and in general there can be many. Of course many projects require the prospecting contributor sign a CLA where they relinquish their rights to the project in order to be able to contribute. Personally while I have signed some CLAs, such as the Go one where I retained my rights, I'd never sign one which required me to give away my copyright rights, precisely so they wouldn't be able to do a rugpull on me. I believe that copyright law is the biggest weapon one has against open source rugpulls and one should not give it away. [1] https://github.com/HermanMartinus/bearblog/blob/master/CONTR... [2] https://github.com/HermanMartinus/bearblog/graphs/contributo...

▲

darkwater 6 days ago | parent | prev [-]

Because between 15 and 20 years ago the BSD zealots won that culture war. I would really love to see a simulation where GNU licenses won that culture war and which landscape we would have today.

▲

sunshowers 6 days ago | parent | next [-]

There are good reasons the so-called "BSD zealots" won the so-called "culture war", such as the definition of a derived work being largely uncharted territory. Did you know that there's a compelling legal argument that the GPL attaches to programs talking to each other via JSON data structures?

I think MPL 2.0 is the ideal kind of copyleft, because of its scope being very clear.

▲

lmm 6 days ago | parent | next [-]

> Did you know that there's a compelling legal argument that the GPL attaches to programs talking to each other via JSON data structures?

The GPL attaches to programs that are legally derivative works. So does any other license that doesn't explicitly grant the right to prepare and distribute derivative works, such as the overwhelming majority of commercial/proprietary licenses. The issue is with the overall copyright/legal system, not with the GPL specifically, and given that most entities are comfortable using at least some non-BSD programs it doesn't seem to worry people in practice.

▲

sunshowers 6 days ago | parent [-]

Right, as mentioned in https://news.ycombinator.com/item?id=45096736, simply running GPL programs is probably fine. Input/output that doesn't establish "intimate communication" probably doesn't create a combined work, but "shipping complex data structures back and forth" does, according to the FSF.

There isn't a similar degree of legal risk with MPL 2.0, nor with non-copyleft licenses (which is the subject of this subthread, not proprietary licenses) -- whether or not a plugin counts as a combined work, there are no requirements on you.

▲

lmm 6 days ago | parent [-]

> There isn't a similar degree of legal risk with MPL 2.0, nor with non-copyleft licenses (which is the subject of this subthread, not proprietary licenses)

There is a similar degree of legal risk with the overwhelming majority of licenses in use. Yes, using exclusively permissively-licensed software would let you avoid this particular risk - but given that essentially no-one (BSD advocates are, if anything, less scrupulous about avoiding proprietary software than GPL advocates - you rarely hear of BSD-land pushing firmware into a separate nonfree repository or the like) does that, it's clearly not a risk many people care much about.

▲

sunshowers 5 days ago | parent [-]

Is your position that the FSF is wrong? If so, why trust the licenses that the same FSF wrote?

In general, businesses acquire commercial licenses for proprietary software, which is a kind of derisking.

	▲	lmm 5 days ago \| parent [-]
		> Is your position that the FSF is wrong? If so, why trust the licenses that the same FSF wrote? The FSF says a program that exchanges complex data structures with the covered program "can" be something that requires a license; they don't claim that it always or usually is. My position is that they're correct that it's possible (at least in some jurisdictions) but the risk is low in cases where you're not trying to do a technological end run around something you obviously need a license for. > In general, businesses acquire commercial licenses for proprietary software, which is a kind of derisking. Only if the license grants permission to do the thing you're doing! Otherwise you're no better off than if you had no license (and you're worse off than under the GPL, which at least permits you to prepare derivative works freely, only putting conditions on distributing them). Almost every commercial/proprietary license I've seen has a blanket prohibition on preparing or distributing derivative works.

▲

kstrauser 6 days ago | parent | prev [-]

There is no such compelling legal argument. That’s an extraordinary idea with zero precedent or support.

▲

sunshowers 6 days ago | parent [-]

https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins

> When is a program and its plug-ins considered a single combined program?

> It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.

JSON data sent over the wire, particularly data with nested arrays and maps, and especially a bidirectional communication protocol, can reasonably count as "intimate communication" with "complex data structures" shipped "back and forth".

This is nonbinding guidance, but it is from the FSF, and it is legally untested afaik (not a lawyer). There's sufficient legal risk here that I'd be wary of using rich communication protocols with GPL programs, particularly if there isn't an explicit exception for that protocol.

▲

kstrauser 6 days ago | parent [-]

"Intimate communication" here almost certainly refers to shared memory. No one is claiming passing JSON over the wire is the same as linking, or else a GPL webserver could insist that browsers be licensed under the GPL.

▲

sunshowers 6 days ago | parent [-]

> "Intimate communication" here almost certainly refers to shared memory.

No, shared memory is addressed later within the same answer.

> Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.

The first part of the answer clearly includes programs sending each other "complex data structures", including nested JSON data, over pipes.

	▲	darkwater 4 days ago \| parent [-]
		And the first part of your quote starts with > If the main program uses fork and exec to invoke plug-ins Which limits a lot the relationship between the original program and the "plug-in" concept. I mean, we literally have binary proprietary blobs used as kernel drivers...

▲

orthoxerox 6 days ago | parent | prev [-]

GPL wouldn't have changed anything. Or even AGPL, if you had been running an unmodified Bear instance.