On Sunday, January 04, 2015 11:45:30 PM Marc Deslauriers wrote:
> >>> I don't know how much of a problem Canonical's competitors claim the CLA
> >>> is. I can point to specific instances of it being problematic in the
> >>> areas of the project I'm involved in.
> >>
> >> I'm sure the alternative that was ultimately chosen will work out just
> >> fine.>
> >
> >
> > Ultimately, I'm sure your right. I think it would, however, have been
> > better for all concerned if non-technical barriers to contribution did
> > force two efforts where one would have done.
>
> Sorry, but I'm pretty sure some other barriers would have prevented
> contributions if a simple CLA was the first thing that was blamed. Do KDE
> developers not contribute to Qt? Or is Qt only used because there is no
> valid alternative?
Snipping down to just this since I think the discussion is largely at or past
the point of diminishing returns (we disagree on some stuff and I think that's
fine).
I think for KDE there is a particular history that causes Canonical to be
treated differently than whoever owns Qt at the moment. Here's the history
lesson for those that weren't around.
KDE/Canonical collaboration got started as part of the development effort for
Kubuntu Karmic (9.10) [1]. It was built around the idea of joint
collaboration. Canonical was contributing both to it's own repositories and
KDE upstream.
This later evolved into a joint effort on systray replacement [2]. This
evolved into libdbusmenu-qt which had a combination of Canonical and KDE
contributions. Then, later in the year, the day after one prominant KDE
contributor declined to sign the Canonical Contributor Agreement [3], without
notification, all of the KDE contributed code was removed [4] and development
was moved to Launchpad [5]. Since, as I've mentioned up-thread, the CA/CLA
have never been relevant to Ubuntu (the distro), in order to prevent
regressions with the new release, we added it all back as a distro patch [6]
and carried the patch until the code had been rewritten by Canonical [7].
The situation with Qt is far different. Note in this earlier post by the same
person the distinction [8]. Also, the objections weren't about the concept,
but about the specifics of the CA [9].
The CLA is clearly a great improvement over the original CA, but I think for a
number of people in KDE, Canonical is now in the once bitten, twice shy
category. "Hey, my agreement is better now and I promise I won't
retroactively change conditions on accepting contributions and throw away your
code again" is probably not going to sound attractive.
Which, at the end, gets us to the LightDM example where the CLA (with that
history behind it) ends up being the sole reason SDDM is selected instead
[10]. If LightDM/SDDM had been the first time this came up, I suspect it
wouldn't have been such an issue. It likely would have been manageable if the
CLA had just applied to the front end and not the back end as well since KDE
would have been using it's own front end, not covered by the CLA since it's
not Canonical developed.
Scott K
[1] http://skitterman.wordpress.com/2009/07/17/kubuntu_ayatana_has_arrived/
[2] http://aseigo.blogspot.com/2010/04/system-tray-progress.html
[3] aseigo.blogspot.com/2010/09/copyright-assignments-gone-wild-or-why.html
[4] http://bazaar.launchpad.net/~dbusmenu-team/libdbusmenu-qt/trunk/revision/177
[5] http://bazaar.launchpad.net/~dbusmenu-team/libdbusmenu-qt/trunk/revision/180
[6] https://launchpad.net/ubuntu/+source/libdbusmenu-qt/0.6.3-0ubuntu1
[7] https://launchpad.net/ubuntu/+source/libdbusmenu-qt/0.8.0-0ubuntu1
[8] http://aseigo.blogspot.com/2010/08/copyright-assignments-of-third-kind.html
[9] http://aseigo.blogspot.com/2010/09/copyright-assignments-gone-wild-or-why.html?showComment=1284586036043
[10] http://aseigo.blogspot.com/2013/03/logging-into-plasma-workspaces-2.html
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
