I wonder what would happen if Ladybird matures well to compete with Firefox and Chrome (hope so), and it's just forked away by some company and completely closed down in a whim, because BSD-2 allows that.
However, Konqueror/KHTML is now dead and we only have a closed source Safari.
I can't fathom your comments back to back.
As I've already stated, any company that may fork a similar project would actually cause more benefit than harm. KHTML died because the web started to get very complex very fast and KDE volounteers couldn't keep up with that pace, unlike Apple employees. Now that the web is a bit more stable, with less standards that are more thought-out (webassembly), it's a lot easier to maintain a web browser. So if tomorrow Microsoft hops in and announces it's intent to fork ladybird, then the latter would not only be fine, but it would probably recieve a new wave of contributors.
Also, its* not it's
Oh no no no. We don't need microsoft contributing anything into this. They will mess up everything and push their agenda.
Google was almost killing Go overnight because they wanted more user data from people using the language.
If your goal is browser diversity, this would take an ecosystem of 2 browser engines and turn it into an ecosystem of 4. That seems in-line with the goal of browser diversity.
Having 4 (or 3.5 more realistically) browser engines where 2 of them weaponized against its users doesn't change things.
Instead, we should have 3 (or 2.5) browser engines where only one of them is (and can be) weaponized against its users. This is what brings diversity and change.
That said, my point here was that realistically no company is going to fork ladybird since there's already chromium, plus even if ladybird was somehow forked by let's say microsoft and got popular, I don't think it would be detrimental to ladybird itself, if not even beneficial, since it would attract more users and, to a lesser extent, more contributors.
If one values the web being somewhat open/less monopolistic, an open source web browser would be more appealing.
I have faith in the Ladybird browser project to avoid such a situation though.
This is not even in the list of my concerns. I just don't like to see efforts of hundreds if not thousands of volunteers are rolled into a closed source application and distributed for the profit of a couple of people who pat themselves on the back because they got their next car/house/whatever for free.
This is why I prefer GPL over BSD/MIT.
When you put all this spectrum of views under a project, it becomes another thing to manage these expectations and what people want from the project in the end. When big shifts start to occur, people will react differently.
When it's a project people love and contribute with the expectation of keeping things the way it's, and the things change, people won't be happy. See: Go's opt-out by default telemetry proposal, HashiCorp's and Docker's license changes, Google's persistent push to block ad-blockers, Microsoft's breaking of VSCodium in subtle ways, etc.
So it's much more than you and your code, esp. in projects like these. I think licensing them with licenses allowing rug-pulls (esp. under community itself), is a red-flag in many cases.
I also put the code I develop myself out there for the betterment of all, but it's licensed with GPL, because I don't want someone take and run away with it for "betterment of themselves rather than everyone". Now, you might not agree with me, and I respect that, but that's the terms I put on my code. As I always say. If you like it that much, reimplement it. I don't care.
Conversely, I contribute to a project which allows no GPL code, because it's designed to be both open, and be customized and closed at the same time. We put it out very openly in the beginning, because that license is a requirement for the use case we (as in ~10 countries) have, and MIT is the best one for our use case.
...but, Ladybird is not that. The project tries to build an important, foundational commodity item. Allowing it to be taken private is a mistake, IMO.
1) Ladybird matures with a community around it.
2) A company actually cares enough to fork it.
3) Said fork becomes the dominant version.
4) Company closes down fork.
I did these assumptions because I saw potential in the project and witnessed the cycle enough times to worry about its future.
On the other hand, it's a food for thought. Just to play with and explore the possibilities.
Sadly, that's not how it works; opting out of the copyright game is a lot harder than it should be. "No license" means all rights reserved, and even a public domain dedication is invalid in certain countries.
Your best bet is to put your code in the PD and provide a fallback maximally permissive license in countries with insane legislation where that doesn't work (e.g. Germany). The Unlicense notably does this, though lawyers seem to hate it for various reasons.
Alternatively, you can use licenses like 0BSD/MIT-0 which are PD-equivalent, but you technically retain copyright, so it should work in aforementioned countries too.
And I don't see any problem with forking. Tons of browser bugs were found, reported and fixed exactly because companies forked them. And remember that Blink is forked from Webkit.
Ladybird might be added to this list. It's not impossible. It'll be a winding and hard road to go, but it is not a path with no end.
You don't need to fork a codebase to fix its bugs. It's GitHub's workflow (fork -> PR -> merge). What I meant, as noted in this thread, is a hard and closed fork propelled with money and corporate greed, which eclipses the open and primary version and drown it in the process.
EEE'ing it, basically. This is why I prefer GPL (preferably V3+). If you want to improve it, it's open. If you want to monetize and EEE it, then nah. It's not allowed.