3 ms·

No it isn’t. Firstly: they weren’t the originators of systemd, they simply hired the guy who first developed it to continue developing it. Secondly: it: being o

by qubex 7y ago

No it isn’t. Firstly: they weren’t the originators of systemd, they simply hired the guy who first developed it to continue developing it. Secondly: it: being open source and GPL, anybody can use it or fork it and not be due anything to Red Hat. Thirdly, it isn’t extinguishing anything as a business strategy; it’s just out-competing alternatives in the “mindshare” arena.

elygre 7y ago
Without having much opinion on systemd, hiring the developer sounds very much like “embrace”. Continuing developing sounds like “extend”.
- majewsky 7y ago
  By that logic, every company that funds open source development is eeeeeevil.
- robin_reala 7y ago
  Embrace in the EEE metaphor specifically refers to an existing standard or pseudostandard.
labawi 7y ago
While not arguing IBM/RH is actually doing EEE. > they simply hired the guy who first developed it If so, they aren't the originators, but it doesn't preclude them from using systemd to do EEE. > open source and GPL, anybody can fork While being OSS and GPL limits attainable power, controlling the development on ever changing software with increasing scope does yield quite significant power and makes practical forking quite hard if you with to remain compatible. > out-competing alternatives I remember distributions being forced to use systemd due to software dependencies and ensuing debacles. I think this might be classified as extend and extinguish.
pdkl95 7y ago
> it being open source and GPL, anybody can use it or fork it The entire point of the EEE strategy is to capture protocols or standards, such as software developed by other companies or free software developed under the GPL. Forking isn't a relevant option, because the other parties software is not changed (it's expected to not be able to change). From Microsoft employee Ronald Alepin's sworn expert testimony[1] in Comes v. Microsoft: Q. Okay. And now, again, for the Jury, what does embrace mean in this context as used by Microsoft employees? A. It's used to indicate a strategy where Microsoft will embrace the standards or the specifications and interfaces of another company's software. Q. Okay. And what does extend refer to? A. Once the specifications have been embraced, then Microsoft will extend them and add additional interfaces proprietary to Microsoft. Q. Okay. When you say add additional proprietary interfaces that are Microsoft's, what impact does that have technologically to other ISVs and OEMs? A. Well, the result is or the impact is that what was once sort of community development property, the work of the industry and industry participants is appropriated essentially, is taken over by Microsoft. And then Microsoft takes it and with its proprietary extensions, makes it essentially unavailable on a going-forward basis to the industry participants who were responsible for first developing the specifications and the standards. Q. Okay. And when Microsoft makes those APIs unavailable to certain ISVs and OEMs, what's the impact to those ISVs and OEMs of their ability technologically to create products? A. It reduces their ability to create products, especially products that will interoperate with Microsoft's products. Examples of this strategy include Mirosoft's attempts to capture the Kerberos protocol and Java. In both examples Microsoft first embraced existing software outside their control by writing their own implementation, then added non-standard features that were only available in their implementation and a clause in their EULA that forbid anybody that used their implementation from re-implementing the features in other (original) software. The GPL doesn't help here, because Microsoft never touched the original free/open implementation, which continued to exist but was now incompatible with Microsoft's software. While the systemd situation is a little different (it isn't trying to take over "another company's" software, systemd de facto IS somewhat similar to the EEE strategy. They initially embraced existing open standards common in Linux distros, and then extended various parts of their implementation intentionally[2] incompatible changes that had the de facto effect of "reduc[ing] [the] ability to create [non-systemd distros], especially [distros] that will interoperate with [systemd]"[3]. It's not exactly EEE, but there are strong similarities with new features used as a barrier to interoperability. [1] http://www.groklaw.net/articlebasic.php?story=20070108020408557 http://www.groklaw.net/articlebasic.php?story=20070108020408... [2] e.g. GNOME depending on the systemd-specific version of existing features that made running GNOME without systemd very difficult.
- youdontknowtho 7y ago
  Adding group SID's to an optional field in Kerberos was them using a standard to support their own system. It was never incompatible with MIT or Heimdal. Those systems didn't use the group information in the optional field, but you could kinit and get a Kerberos ticket from a DC. I know I'm not going to change your mind, but Kerberos isn't a good example.

by qubex 7y ago

elygre 7y ago

Without having much opinion on systemd, hiring the developer sounds very much like “embrace”. Continuing developing sounds like “extend”.

majewsky 7y ago
By that logic, every company that funds open source development is eeeeeevil.
robin_reala 7y ago
Embrace in the EEE metaphor specifically refers to an existing standard or pseudostandard.

labawi 7y ago

While not arguing IBM/RH is actually doing EEE. > they simply hired the guy who first developed it If so, they aren't the originators, but it doesn't preclude them from using systemd to do EEE. > open source and GPL, anybody can fork While being OSS and GPL limits attainable power, controlling the development on ever changing software with increasing scope does yield quite significant power and makes practical forking quite hard if you with to remain compatible. > out-competing alternatives I remember distributions being forced to use systemd due to software dependencies and ensuing debacles. I think this might be classified as extend and extinguish.

pdkl95 7y ago

> it being open source and GPL, anybody can use it or fork it The entire point of the EEE strategy is to capture protocols or standards, such as software developed by other companies or free software developed under the GPL. Forking isn't a relevant option, because the other parties software is not changed (it's expected to not be able to change). From Microsoft employee Ronald Alepin's sworn expert testimony[1] in Comes v. Microsoft: Q. Okay. And now, again, for the Jury, what does embrace mean in this context as used by Microsoft employees? A. It's used to indicate a strategy where Microsoft will embrace the standards or the specifications and interfaces of another company's software. Q. Okay. And what does extend refer to? A. Once the specifications have been embraced, then Microsoft will extend them and add additional interfaces proprietary to Microsoft. Q. Okay. When you say add additional proprietary interfaces that are Microsoft's, what impact does that have technologically to other ISVs and OEMs? A. Well, the result is or the impact is that what was once sort of community development property, the work of the industry and industry participants is appropriated essentially, is taken over by Microsoft. And then Microsoft takes it and with its proprietary extensions, makes it essentially unavailable on a going-forward basis to the industry participants who were responsible for first developing the specifications and the standards. Q. Okay. And when Microsoft makes those APIs unavailable to certain ISVs and OEMs, what's the impact to those ISVs and OEMs of their ability technologically to create products? A. It reduces their ability to create products, especially products that will interoperate with Microsoft's products. Examples of this strategy include Mirosoft's attempts to capture the Kerberos protocol and Java. In both examples Microsoft first embraced existing software outside their control by writing their own implementation, then added non-standard features that were only available in their implementation and a clause in their EULA that forbid anybody that used their implementation from re-implementing the features in other (original) software. The GPL doesn't help here, because Microsoft never touched the original free/open implementation, which continued to exist but was now incompatible with Microsoft's software. While the systemd situation is a little different (it isn't trying to take over "another company's" software, systemd de facto IS somewhat similar to the EEE strategy. They initially embraced existing open standards common in Linux distros, and then extended various parts of their implementation intentionally[2] incompatible changes that had the de facto effect of "reduc[ing] [the] ability to create [non-systemd distros], especially [distros] that will interoperate with [systemd]"[3]. It's not exactly EEE, but there are strong similarities with new features used as a barrier to interoperability. [1] http://www.groklaw.net/articlebasic.php?story=20070108020408557 http://www.groklaw.net/articlebasic.php?story=20070108020408... [2] e.g. GNOME depending on the systemd-specific version of existing features that made running GNOME without systemd very difficult.

youdontknowtho 7y ago
Adding group SID's to an optional field in Kerberos was them using a standard to support their own system. It was never incompatible with MIT or Heimdal. Those systems didn't use the group information in the optional field, but you could kinit and get a Kerberos ticket from a DC. I know I'm not going to change your mind, but Kerberos isn't a good example.