4 ms·

Is there anything specific you can point to that would explain what you mean here? Or are you referring to thing such as the Mir, Unity, etc. controveries?

sho_hn 13y ago
Let me report a specific example I've witnessed from the sidelines. Some time ago, Canonical collaborated with others in the desktop space, among them the KDE community, on a specification to make system tray menus work over the D-Bus IPC system. The upshot is that it allows menus to be rendered by the shell implementation you're running instead of by the app backing the icon, improving visual consistency and giving the shell more control to e.g. tune the menu for a particular form factor. This specification was implemented for a number of toolkits, and the Qt implementation, used by KDE, was set up as a Canonical project, with code contributions from both within and outside of Canonical. Then Canonical decided to require signing a copyright assignment contract before contributing to their projects and decided to retroactively apply this to codebases already in flight, such as the library in question. Copyright assignment is a hotly debated topic in the community and there is a widespread belief that mandatory copyright assignment is a Bad Thing in general, but in this particular case the contract they ran with was very badly crafted and deemed unacceptable by many, including a KDE developer who had contributed to the library. Canonical therefore decided to kick out the bugfixes he had contributed -- and then Ubuntu ended up shipping them anyway in the form of patches to their package, with the packagers exploiting the loophole that Canonical doesn't require holding the copyright for such patches. Other distributions were left duplicating the same work on their end. A repository on Gitorious.org was set up as a staging area outside of Canonical to have a convenient place to host the fixed version of the library, but making this repository the new canonical (heh, sorry, pun unintended) upstream was deemed not an option because the Canonical-employed developer who had written most of the library would be unable to get approval from his employer. Eventually, if memory serves right, said employee ended up independently rewriting the KDE developer's patches to yield the same bug fixes (which, given knowledge of the original patches, sounds potentially legally sketchy to me, but IANAL) for a second round of needlessly duplicated work. Episodes like this one are why there's not a whole lot of appetite left for collaborating with Canonical or relying on projects they steward. There's just no trust for Canonical to display any regard for the needs of their partners, or perform well in a governance role.
- synchronise 13y ago
  To be fair, the KDE team knew that they were dealing with a corporate entity that would want to retain some sort of control over how software it creates and distributes is licensed. Signing a CLA is nothing new, in fact the FSF do exactly the same thing so they can shunt their projects to the next GPL without having to contact developers. If developers have an issue with such an arrangement, then they shouldn't be contributing to those companies and organisations in the first place.
  - sho_hn 13y ago
    Note the point about starting to apply a CLA after the fact to an existing project. KDE certainly consciously took a risk when deciding to try and collaborate with a corporate entity, but that doesn't mean the community can't be disappointed at the outcome. Nobody is complaining about a CLA they knew of in advance - because they did not. And personally I don't think a CLA makes sense for the specific code in question, which is purposefully designed as an interoperability solution and so implicitly multi-stakeholder.
DannyBee 13y ago
No, sadly. This involves a number of private companies, and legal issues. Let's just say that in private, canonical has taken an interesting view of the rights it has in the open source software that makes up ubuntu, and this view is, IMHO, not particularly in line with what are likely the broader expectations of the open source community. These views are not simply restricted to trademark issues.

sho_hn 13y ago

Let me report a specific example I've witnessed from the sidelines. Some time ago, Canonical collaborated with others in the desktop space, among them the KDE community, on a specification to make system tray menus work over the D-Bus IPC system. The upshot is that it allows menus to be rendered by the shell implementation you're running instead of by the app backing the icon, improving visual consistency and giving the shell more control to e.g. tune the menu for a particular form factor. This specification was implemented for a number of toolkits, and the Qt implementation, used by KDE, was set up as a Canonical project, with code contributions from both within and outside of Canonical. Then Canonical decided to require signing a copyright assignment contract before contributing to their projects and decided to retroactively apply this to codebases already in flight, such as the library in question. Copyright assignment is a hotly debated topic in the community and there is a widespread belief that mandatory copyright assignment is a Bad Thing in general, but in this particular case the contract they ran with was very badly crafted and deemed unacceptable by many, including a KDE developer who had contributed to the library. Canonical therefore decided to kick out the bugfixes he had contributed -- and then Ubuntu ended up shipping them anyway in the form of patches to their package, with the packagers exploiting the loophole that Canonical doesn't require holding the copyright for such patches. Other distributions were left duplicating the same work on their end. A repository on Gitorious.org was set up as a staging area outside of Canonical to have a convenient place to host the fixed version of the library, but making this repository the new canonical (heh, sorry, pun unintended) upstream was deemed not an option because the Canonical-employed developer who had written most of the library would be unable to get approval from his employer. Eventually, if memory serves right, said employee ended up independently rewriting the KDE developer's patches to yield the same bug fixes (which, given knowledge of the original patches, sounds potentially legally sketchy to me, but IANAL) for a second round of needlessly duplicated work. Episodes like this one are why there's not a whole lot of appetite left for collaborating with Canonical or relying on projects they steward. There's just no trust for Canonical to display any regard for the needs of their partners, or perform well in a governance role.

synchronise 13y ago
To be fair, the KDE team knew that they were dealing with a corporate entity that would want to retain some sort of control over how software it creates and distributes is licensed. Signing a CLA is nothing new, in fact the FSF do exactly the same thing so they can shunt their projects to the next GPL without having to contact developers. If developers have an issue with such an arrangement, then they shouldn't be contributing to those companies and organisations in the first place.
- sho_hn 13y ago
  Note the point about starting to apply a CLA after the fact to an existing project. KDE certainly consciously took a risk when deciding to try and collaborate with a corporate entity, but that doesn't mean the community can't be disappointed at the outcome. Nobody is complaining about a CLA they knew of in advance - because they did not. And personally I don't think a CLA makes sense for the specific code in question, which is purposefully designed as an interoperability solution and so implicitly multi-stakeholder.

DannyBee 13y ago

No, sadly. This involves a number of private companies, and legal issues. Let's just say that in private, canonical has taken an interesting view of the rights it has in the open source software that makes up ubuntu, and this view is, IMHO, not particularly in line with what are likely the broader expectations of the open source community. These views are not simply restricted to trademark issues.