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.
And so? Yes people (and companies) would fork your code, but the most realistic scenario would be that the original ladybird would still be the most relevant browser of it's family, just like firefox, so the problem kinda resolves by itself
Because apple themselves forked it. Only a handful of companies have the power to basically change the web browser market, and apple sure was one. Nowadays every company copies from chrome, so why would anyone bother forking ladybird?
Doesn't this contradict with what you said? According to your previous comment, even if Apple has forked KHTML, it shouldn't harm Konqueror, and it shall prevail as the most popular of its family.
However, Konqueror/KHTML is now dead and we only have a closed source Safari.
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.
Imagine if ladybird gets used regularly by ~1000 nerds, which is its current audience, then gets forked by microsoft and the current ME gets replaced by ladybird. Even if ladybird got over 9000 users, there's no competing with megacorps.
Well maybe they're ok with that? They want browser diversity. Getting Microsoft to use a new engine is better for diversity than if they just used chromium like now.
Getting Microsoft to use a new engine and contribute back to the original repository is better for diversity, but forking and running away with it is certainly not.
> Forking and running away with it is certainly not
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.
Currently we have an ecosystem of two browser engines, yes. One of them is weaponized against users by its designers, both in its open and closed form.
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.
Ideally, yes. Microsoft should stay away from this, but I wanted to highlight that adopting a technology doesn't automatically make it better for diversity.
Google was almost killing Go overnight because they wanted more user data from people using the language.
Sorry for my grammatical mistake, English is not my first language.
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.
> seeing your code being used by some guys you don’t like?
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.
That sounds no different from "code being used by some guys you don't like" to me, to be honest. If some company took my permissively licensed work and turned it into a commercial product, why would I take issue? I put my work out there for the betterment of all, and it is still bettering the world even in its new form. I have no complaints with that.
In fact, it's very different. You, as a single person might not care about a patch you contributed, or a small utility you have written. However, not everyone thinks like you (e.g.: Me, as Fig. 1a).
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.
Personally am asking myself what the benefits of the BSD clause compared to a more restrictive license are. The only reason I personally can see is that they want to have to option to close the browser themself in the future.
Yup. All licensing is about brokering control. The only license that grants true freedom is no license, i.e. public domain. Everything else is a “where’s the control” shell game.
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.
If you the amount of features in Chrome and Firefox (just those in the standard, nothing extra), you would know "mature well to compete" is a long way away, if not impossible.
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.
I have seen IE's rise and fall. Netscape's rise, burn and rebirth as Firefox, saw Safari as a fork of KHTML and rise of Chrome.
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.
