This is great news. It's great that the bigger players in container runtimes are working together more, it makes me hopeful for the future. This is great for users and developers.
There definitely was never any money in basic container runtimes, but this move is more like Docker playing nice after Red Hat & Google threatened to burn it down. And I guess rkt got thrown in for FOMO.
What is up with the use of the term "donated" when in comes to transfering control of open source code to a standards body? There is no legal transfer taking place, and politically, there if there is a power transfer, the power transfer happens in the form of the "doner" gaining more power over the "receiver". In the real world of serious standard bodies, the standard body does not "receive a donation of a standard" but works on choosing and developing the best standard possible based on technical merits.
There absolutely is a legal transfer. the donation assigns copyright, and normally includes the intellectual property rights of the trademark and logo.
In theory, the recipient could choose to relicense.
In these particular cases I would expect there would be no assignment of copyright (however I would assume you're right about trademarks).
Despite the fact that there most likely is some transfer of intellectual property contemplated here, I do think the term "donation" is a little odd when describing stewardship transfer of open source projects to nonprofits -- though it's fairly well established (I associate it mainly with the Apache Software Foundation).
To me "donation", based on its ordinary usage in English, suggests "here's something I don't need anymore; you can have it, I won't have any further involvement in it." That does fit certain situations (an example that comes to mind is Oracle's transfer of OpenOffice to the ASF).
Hi, Richard. You're correct that CNCF requires projects to provide the trademark, but we don't need copyright, because the ASLv2 license the code is already under is sufficient. "Contribute" might be better word than "donate".
But it all a very open-source-oriented, metaphysical concept, in that by giving up some control over a project, the company that originated it is hopefully going to bring in many more contributors and ultimately increase both the total value of the project and the value to them. A core CNCF value proposition to projects [0] is that: "A neutral home for your project increases the willingness of developers from other companies and independent developers to collaborate, contribute, and become committers."
Solomon made a useful analogy [1] that "rough comparison: Docker EE=RHEL, CE=Fedora, containerd=Linux".
Disclosure: I'm the executive director of CNCF and have been working with Docker on their contribution of containerd and with CoreOS on their contribution of rkt.
But there is no transfer taking place. The only transfer going on is a transfer of responsibility. If anything, CNCF is the doner, promising to maintain and endorse an existing peice of open source software.
Please see https://news.ycombinator.com/item?id=13885437 . Docker and CoreOS are contributing the trademark, as well as committing to an open governance process under the aegis of CNCF.
CNCF is not a standards body and can you explain this part: politically, the power transfer happens in the form of the "donor" gaining more power over the "receiver"
Yes, I can explain. Look at this issue https://github.com/opencontainers/image-spec/issues/24 and notice the belligerant and proprietary attitudes of the Docker employee. He thinks that because the standard is based on the Docker project, he somehow has more say in what will be decided than the other speakers. There is an implied ownership which is not translated when the donation takes place.
Well I see a CoreOS employee saying that the spec should remain compatible with Docker until after 1.0. The image spec was not "donated" to OCI, various people decided to make a spec for roughly what Docker was doing already, in order to formalise it, with an agreement to do a 1.0 quickly. It was not a standard to create an all new spec, at least initially. There are a lot of existing images out there, so incremental change and backward compatibility is important.
