Systemd is a critical part of the Linux userland, and is now the standard Linux init system.
If you opt to run Linux without systemd, expect various userland things to break.
If you opt to run Linux without systemd, expect various userland things to break.
Systemd takes the cool stuff that's been getting into Linux under the hood and makes actually usable to everyday users and administrators.
And it's far easier to write a systemd unit than a startup script for any other init system (except DJB's daemontools, perhaps).
I'm all for opinionated design, but I hope we don't end up with a "Linux userland" in the sense we have a GNU userland -- that would be going towards too tight coupling of things that really shouldn't be coupled at all.
"Choice" just means you are stuck coding for the lowest common denominator.
The Unix Philosophy is based on building well-factored parts that fit together with small, knowable interfaces (e.g., simple text protocols communicating over pipes or sockets). Yet, the success of Mac OS X as the only relevant Unix on the desktop goes to show that whole, well-integrated systems are much more valuable than well-factored parts.
GNU/Linux needs to become a whole, integrated system. A platform for applications, not a framework for parts. Systemd is an essential part of that vision.
In short, everybody needs to suck it up because this is how things are done in Linux now.
Certainly not as clearly as the success of Linux in the server world shows the opposite.
> Linux needs to become a whole, integrated system.
If the priority for Linux is to capture a bigger share of the dying desktop market at the expense of the server market, sure.
On the server side, the whole "framework for parts assembled ad hoc by a recipe for a task" model is becoming more, not less viable.
RHEL's next release will come with systemd. The server market is not threatened by systemd, and the growth market in personal devices -- mobile -- will benefit from its power-management features.
> On the server side, the whole "framework for parts assembled ad hoc by a recipe for a task" model is becoming more, not less viable.
systemd units are much easier to write than init scripts.
Regarding API license: Just ask systemd mailing list. They will tell you that API doesn't have a license, only the code.