Upstart adoption continues
A complete surprise to me, from slides of today’s OSiM Maemo Developer Session it appears that Maemo (the Nokia open source Internet Tablet platform) has adopted Upstart. Does anyone know whether they are using native jobs or still using SysV compatibility?
Half-half, last I checked.
We’d like to adopt Upstart for PLD too but we’ve been holding back due to 0.4 being outdated and 0.5 being broken for us :/ (https://bugs.launchpad.net/pld-linux/+bug/259801)
While we’re on the subject, is *Ubuntu* using native Upstart scripts yet, or is it still mostly SysV compatibility?
Hey Scott,
They just announced they will use it, but outsiders can’t tell how far it is.
Usually, Nokia developers the next ITOS, then releases a beta for it, then you discover about its functionalities and check how it’s done. The fundamental change in this iteration is that they announced in advance what they will do, and they also decided they will feed the community with regular alphas (perhaps one per week IIUC), in the form of SDKs as an OMAP3 web tablet wont be readily available for people to test on it.
Nokia did quite some large-ish changes to the base OS in previous ITOS releases, so I wouldn’t be surprized if they don’t use SysV at all anymore.
Cheers,
Just out of curiousity – why the need for copyright assignment for Upstart? Is there interest for a version of Upstart in completely proprietary systems or something?
Not that I mind – it just seems like a little speedbump to contributing patches.
@nona: absolutely not! In fact, if you read the Upstart copyright assignment document (which is the same as bzr’s) http://upstart.ubuntu.com/wiki/CopyrightAssignment you’ll note that clause #6 actually prohibits Canonical from ever doing this.
The reason it’s asked for is to avoid the situation that other projects, such as (most recently) D-Bus have got into where they’ve wanted to change their licence from one open source licence to a better one (in D-Bus’s case, a more permissive one!) and been unable to contact copyright contributors.
“clause #6 actually prohibits Canonical from ever doing this”
Errr? Not that I care one way or the other about this particular issue… But this:
“Canonical may also make the Assigned Contributions available under other license terms.”
seems to contradict what you just said. That the assigned contributions always will be available under a “Free Software License” is an entirely different matter. It doesn’t prevent Canonical from doing whatever it sees fit with those contributions.
IANAL and I don’t really care. I just happened to stumble upon your comment.
@Scott: in that case, wouldn’t it be enough to ask outside contributors to either do the copyright assignment, or alternatively, provide patches in one of the most liberal licenses out there like MIT/X or BSD? All the code provided by Canonical could then stay GPL for the time being, until that time you decide you want to go LGPL, GPL3, MIT, BSD, whatever.
That way external contributors could keep their copyright (/attribution?), and don’t have to deal with unnecessary paperwork.
Just a thought.
nona:
The patch contains the GPLed code as context so it can’t be licensed under anything else than the original license.
The “Newly adopted technologies:” and the “New contributions to the open source community:” lists are certainly amusing.
@nona: none of the liberal licences permit relicencing; even if the changes were submitted as MIT, we couldn’t relicence the codebase to GPL3, for example – those changes would remain MIT.
There’s no real unnecessary paperwork to signing a document with a GPG key
@Martin: my understanding is that it’s a “may also” on the back of a “will” – so Canonical always has to release as open source, even if it does anything else as well (e.g. if a partner asks us to licence with additional terms).
Yes, and those license terms can be _anything_. Hence, “clause #6 actually prohibits Canonical from ever doing this” is false. It’s the exact opposite. Canonical can e.g. license Upstart under terms that allows the licensee to do whatever he wants with the code. Or maybe license it under terms that require the user to send in a banana every time an event is fired.
That the original code also must be available under a FOSS license _does not matter_.
I don’t see why this is needed though since earlier paragraphs already state that the contributor must hand over the Copyright to his/her contributions. Which effectively means Canonical can do whatever it wants with the code.
In fact, it’s a bit strange.
1. Hand over copyright so we can do whatever we want.
2. We promise to only do this though.
3. But we reserve the right to do whatever we want.
Anyway, that’s how I read it.
(And no, don’t think it’s Canonical’s intention to be evil. I can understand assigning copyright to ease a license transition. And I don’t think that Upstart is particularly large or complex (it’s no OpenOffice
and not that many companies is involved etc that it matters much. But personally, I would never hand over copyright to any large contribution if I don’t completely trust the entity I hand it over to… Especially if I’m another company. It shifts the balance inherent in the GPL. See e.g. the Sun/Novell OpenOffice brouhaha.)
Revolution OS, Bruce Perens, quoted approx from memory: “Basically Free Software means you don’t have to have a lot of lawyers involved, just to work on software. We just want to have all software free”
Basically, anything outside the mainlines of F/OSS is a distruption: New, minority share F/OSS Licenses, EULAS and copyright assignments. We build a Free Software society where one of the pillars is the GPL. Anything outside of this is something new, a “disruption” using my own words.
The Canonical copyright assignment means:
the developer has to read and understand a new legal document
the developer has to take a stance and trust a new entity (Canonical)
the developer has to wonder why going with the mainline (plain model GPL) is not enough.
I want all software simply to be free, without having to have a lot of lawyers involved. (I notice we all had to go through all of the steps above once already for established parties like GPL and GNU; but this is as noted above now the pillar of the F/OSS community)
This is obnoxious, but not as obnoxious as the Mozilla Firefox EULA thing.
Scott: ‘none of the liberal licences permit relicencing’ – IANAL, but I don’t believe it’s true. We at CiviCRM are in the same situation as Canonical (we want to have the ability to re-licence our codebase under future AGPL licences, for example), and so we either ask people to hand over the copyright to us or licence their code under the Academic Free License *to CiviCRM*. This way (a) the original contributor keeps the copyright and (b) we (but nobody else!) can re-licence the code under future open source licences.
@Scott: I didn’t realise you could GPG-sign the document, that makes it a lot easier indeed. I still feel it’s a small annoyance, a speedbump in the way of getting contributions.
As for liberal licences: you can just leave those bits of code BSD/MIT, right? If you want to upgrade the license of the bulk of the canonical code to the GPL3 for instance, those few BSD/MIT bits would not interfere or get in the way, would they?
Even so, it’s not a big deal – I don’t want to imply that Canonical has sinister plans or anything like that – far from it. I’m just hoping upstart gets adopted far and wide, because I do believe it’s the most interesting design of all the init replacements. Wide adoption can only help with the upstart tasks etc.
On a side note: do you have any idea what’s happening with upstart in Debian?
Will somebody please write some documentation for this thing. Frankly, I don’t have the time to relearn how init works, I have tons of machines to manage, upgrades to perform. The last thing I need is to install a new system (Fedora9 today) and discover that the 5 minutes of editing i usually do in /etc/inittab has now turned into an all-day learning experience about a new piece of technology so I can just complete the upgrades I have scheduled.
I don’t care if it’s better or worse. Mysterious undocumented technology running as PID #1 represents a huge security threat. It is useless and even dangerous until it is documented well enough so that ‘man init’ or ‘man upstart’ tells us what we need to know to do the things we need to do, and allows us to use it confidently without taking a “fun learning journey” through websites and tutorials and “here is an example” postings that leave us guessing just where some of those example options came from and what they do.
Clear, definitive man pages which represent the exact features and syntax supported on the version that is currently installed are essential for /sbin/init.
gary: your rant makes a lot of sense. The community around Upstart does not seem to be there, the main dev is dormant and nothing is happening. Is the conclusion that Fedora is even more of a playground, that shouldn’t be used for situations like yours (reliability)?
+1 on the “documentation please” issue, especially for older versions (like 3.9, used in hardy) which are actually in use. At the moment, all I can do is look over some blog posts about what upstart is meant to be able to do when perfect, and try to work out through trial and error what actually works