5 ms·

I have to admit, I was dragged kicking and screaming into the new init world, and really didn't want to leave SysV init. I haven't used systemd, but I have bee

I have to admit, I was dragged kicking and screaming into the new init world, and really didn't want to leave SysV init. I haven't used systemd, but I have been using upstart and it's grown on me. After reading this post, I did look at: https://wiki.debian.org/Debate/initsystem/upstart https://wiki.debian.org/Debate/initsystem/upstart Which does spell out some reasonable pros and cons of both systems. I'd say the biggest problem with upstart (and possibly the deal breaker) is the licensing terms. Yes, it's open source, but no, I really don't want to have to fill out Canonical's contributer license agreement if I want to contribute. I'm not really sure why Canonical doesn't just GPL like everyone else and leave it at that. There are some tools out there for upstart, but one thing which would be really nice would be a built in command for visualizing the init graph in ascii. It doesn't have to be fancy, just enough to know where your init script is going to be called in the boot process.

hansjorg 13y ago
> I'm not really sure why Canonical doesn't just GPL like everyone else and leave it at that That is about copyright, not about the license. Organizations who requires this includes the FSF and Mozilla for example. See: http://www.gnu.org/licenses/why-assign.html http://www.gnu.org/licenses/why-assign.html
- bkor 13y ago
  But FSF/GNU contributions are guaranteed to stay under a Free Software license. Canonical is not similar. Not at all the same situation. Further, IMO FSF/GNU/Mozilla are also bad for requesting this.
- warp 13y ago
  The FSF doesn't require this for all GNU projects. Each GNU project can decide if they want to require a CLA or not.
andor 13y ago
I'd say the biggest problem with upstart (and possibly the deal breaker) is the licensing terms. Upstart isn't even a real solution for Ubuntu: they still use SysV init scripts for many daemons (I don't know why exactly). Because upstart cannot monitor daemons that it started through init scripts, it's not reliable for process monitoring... Also see: https://wiki.debian.org/Debate/initsystem/systemd#Upstart https://wiki.debian.org/Debate/initsystem/systemd#Upstart
chimeracoder 13y ago
> I'm not really sure why Canonical doesn't just GPL like everyone else and leave it at that. Because they want to be able to have the benefits of proprietary code for themselves (being able to provide their own software under a proprietary license to other parties), without allowing anybody else that same ability. If it were under the GPL and each contributor retained their copyright over their submission (as is the case with the Linux codebase), this wouldn't be an issue. But by having complete ownership over all the code in the codebase, Canonical is free to change the license at any time they choose.
- lvillani 13y ago
  > If it were under the GPL and each contributor retained their copyright over their submission DISCLAIMER: I'm not a lawyer, everything I say below may be totally wrong. As far as I know, this is exactly what happens. Canonical's Contributor License Agreements stipulates a form of joint copyright assignment where both Canonical and the author have ownership over the contribution, thereby creating two source trees: one on which Canonical has full control over, the other owned by the collective of individuals who contributed to the project (just like the Linux kernel). Even RedHat requires you to sign a similar CLA in order to accept contributions for Fedora, 389 Directory Server (LDAP), etc. The FSF does something similar for their project, so does Node, Apache, etc. Canonical's CLA used to be nasty but since they started using the Harmony Agreements I think their terms are reasonable. Personally, as long as they don't ask me to relinquish all and every right on my contribution and/or ask for unreasonable provisions, I'm fine with a CLA.
  - forgottenpass 13y ago
    The thing about CLAs, I always figured that if I'm working for a company (by giving them license to close-source my contribution to a not-BSD-flavor licensed codebase), I should be getting paid. OFC small changes or contributions to something like the FSF have to be judged differently, but thats the big picture.
  - richardfontana 13y ago
    This is incorrect. Canonical formerly used a (non-joint) copyright assignment agreement, which was widely criticized. It later sponsored the Harmony project which was an unsuccessful effort to popularize a standardized suite of contributor agreements. When the Harmony agreements were released in 2011, Canonical began using one of the Harmony CLAs. It doesn't stipulate copyright assignment; rather, the contributor grants Canonical a broad copyright license that is similar in effect to copyright assignment except that the contributor retains copyright ownership of the contribution. It is not dissimilar in policy to the widely-used Apache model of CLAs. I'm a strong critic of CLAs generally, particularly these types, but they ought to be described accurately. The effect of use of such CLAs by entities that will (by employment of a majority of developers, say) hold copyright over much of a relevant codebase is that you have little pieces of code that are owned by outside contributors but licensed in under maximally broad terms which basically give the inbound entity the ability to do whatever they want with the code, short of assigning copyright in it. > Even RedHat requires you to sign a similar CLA in order to accept contributions for Fedora, 389 Directory Server (LDAP), etc. No (with some legacy use of Apache-style CLAs basically confined to some JBoss projects and gradually being dismantled). I've been Red Hat's open source lawyer since 2008 so I think I can speak authoritatively on this. Red Hat does not use a similar CLA for contributions to Fedora (though at least nominally it used an Apache-style CLA prior to 2010). Since 2010 Fedora account holders agree to the Fedora Project Contributor Agreement (http://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement http://fedoraproject.org/wiki/Legal:Fedora_Project_Contribut...) which is a simple agreement that says code is licensed by default under the MIT license (and content under CC BY-SA) unless the contributor indicates otherwise. 389 basically followed the Fedora approach for reasons best understood as historical inertia (by coincidence I noticed last night there is some incorrect information about this on the 389 website). Red Hat starts up tons of open source projects, and most of them do not require contributor agreements. When I got to Red Hat in 2008 this was already the case, if only because of the nature of Red Hat's culture at the time. But the company was on the verge of applying a uniform (Apache-style) CLA requirement across all Red Hat-maintained projects -- much like so many companies do today. I very soon realized how problematic that would be and I think one of my big accomplishments was not only to stop that from happening but also to reverse it (the trend for that set of projects that used CLAs in the past has been to get rid of them), and to formulate a strong legal-policy basis for doing so, maybe best recorded in my two-part critique of the Harmony contributor agreement suite in 2011: http://opensource.com/law/11/7/trouble-harmony-part-1 http://opensource.com/law/11/7/trouble-harmony-part-1 . So please do not use Red Hat as evidence of support for use of broad contributee-friendly contributor agreements. Red Hat has been the leading company, maybe the only company, articulating an alternative viewpoint. [Edited to fix formatting and to tone down initial scorn slightly] [Edited to acknowledge JBoss situation] [Edited to note Harmony agreements unsuccessful in that few use them]

hansjorg 13y ago

> I'm not really sure why Canonical doesn't just GPL like everyone else and leave it at that That is about copyright, not about the license. Organizations who requires this includes the FSF and Mozilla for example. See: http://www.gnu.org/licenses/why-assign.html http://www.gnu.org/licenses/why-assign.html

bkor 13y ago
But FSF/GNU contributions are guaranteed to stay under a Free Software license. Canonical is not similar. Not at all the same situation. Further, IMO FSF/GNU/Mozilla are also bad for requesting this.
warp 13y ago
The FSF doesn't require this for all GNU projects. Each GNU project can decide if they want to require a CLA or not.

andor 13y ago

I'd say the biggest problem with upstart (and possibly the deal breaker) is the licensing terms. Upstart isn't even a real solution for Ubuntu: they still use SysV init scripts for many daemons (I don't know why exactly). Because upstart cannot monitor daemons that it started through init scripts, it's not reliable for process monitoring... Also see: https://wiki.debian.org/Debate/initsystem/systemd#Upstart https://wiki.debian.org/Debate/initsystem/systemd#Upstart

chimeracoder 13y ago

> I'm not really sure why Canonical doesn't just GPL like everyone else and leave it at that. Because they want to be able to have the benefits of proprietary code for themselves (being able to provide their own software under a proprietary license to other parties), without allowing anybody else that same ability. If it were under the GPL and each contributor retained their copyright over their submission (as is the case with the Linux codebase), this wouldn't be an issue. But by having complete ownership over all the code in the codebase, Canonical is free to change the license at any time they choose.

lvillani 13y ago
> If it were under the GPL and each contributor retained their copyright over their submission DISCLAIMER: I'm not a lawyer, everything I say below may be totally wrong. As far as I know, this is exactly what happens. Canonical's Contributor License Agreements stipulates a form of joint copyright assignment where both Canonical and the author have ownership over the contribution, thereby creating two source trees: one on which Canonical has full control over, the other owned by the collective of individuals who contributed to the project (just like the Linux kernel). Even RedHat requires you to sign a similar CLA in order to accept contributions for Fedora, 389 Directory Server (LDAP), etc. The FSF does something similar for their project, so does Node, Apache, etc. Canonical's CLA used to be nasty but since they started using the Harmony Agreements I think their terms are reasonable. Personally, as long as they don't ask me to relinquish all and every right on my contribution and/or ask for unreasonable provisions, I'm fine with a CLA.
- forgottenpass 13y ago
  The thing about CLAs, I always figured that if I'm working for a company (by giving them license to close-source my contribution to a not-BSD-flavor licensed codebase), I should be getting paid. OFC small changes or contributions to something like the FSF have to be judged differently, but thats the big picture.
- richardfontana 13y ago
  This is incorrect. Canonical formerly used a (non-joint) copyright assignment agreement, which was widely criticized. It later sponsored the Harmony project which was an unsuccessful effort to popularize a standardized suite of contributor agreements. When the Harmony agreements were released in 2011, Canonical began using one of the Harmony CLAs. It doesn't stipulate copyright assignment; rather, the contributor grants Canonical a broad copyright license that is similar in effect to copyright assignment except that the contributor retains copyright ownership of the contribution. It is not dissimilar in policy to the widely-used Apache model of CLAs. I'm a strong critic of CLAs generally, particularly these types, but they ought to be described accurately. The effect of use of such CLAs by entities that will (by employment of a majority of developers, say) hold copyright over much of a relevant codebase is that you have little pieces of code that are owned by outside contributors but licensed in under maximally broad terms which basically give the inbound entity the ability to do whatever they want with the code, short of assigning copyright in it. > Even RedHat requires you to sign a similar CLA in order to accept contributions for Fedora, 389 Directory Server (LDAP), etc. No (with some legacy use of Apache-style CLAs basically confined to some JBoss projects and gradually being dismantled). I've been Red Hat's open source lawyer since 2008 so I think I can speak authoritatively on this. Red Hat does not use a similar CLA for contributions to Fedora (though at least nominally it used an Apache-style CLA prior to 2010). Since 2010 Fedora account holders agree to the Fedora Project Contributor Agreement (http://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement http://fedoraproject.org/wiki/Legal:Fedora_Project_Contribut...) which is a simple agreement that says code is licensed by default under the MIT license (and content under CC BY-SA) unless the contributor indicates otherwise. 389 basically followed the Fedora approach for reasons best understood as historical inertia (by coincidence I noticed last night there is some incorrect information about this on the 389 website). Red Hat starts up tons of open source projects, and most of them do not require contributor agreements. When I got to Red Hat in 2008 this was already the case, if only because of the nature of Red Hat's culture at the time. But the company was on the verge of applying a uniform (Apache-style) CLA requirement across all Red Hat-maintained projects -- much like so many companies do today. I very soon realized how problematic that would be and I think one of my big accomplishments was not only to stop that from happening but also to reverse it (the trend for that set of projects that used CLAs in the past has been to get rid of them), and to formulate a strong legal-policy basis for doing so, maybe best recorded in my two-part critique of the Harmony contributor agreement suite in 2011: http://opensource.com/law/11/7/trouble-harmony-part-1 http://opensource.com/law/11/7/trouble-harmony-part-1 . So please do not use Red Hat as evidence of support for use of broad contributee-friendly contributor agreements. Red Hat has been the leading company, maybe the only company, articulating an alternative viewpoint. [Edited to fix formatting and to tone down initial scorn slightly] [Edited to acknowledge JBoss situation] [Edited to note Harmony agreements unsuccessful in that few use them]