LWN: Comments on "Kuhn: Canonical, Ltd. Finally On Record: Seeking Open Core" https://lwn.net/Articles/410378/ This is a special feed containing comments posted to the individual LWN article titled "Kuhn: Canonical, Ltd. Finally On Record: Seeking Open Core". en-us Wed, 17 Sep 2025 11:38:03 +0000 Wed, 17 Sep 2025 11:38:03 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Dual Licencing and Central Copyright Holders. https://lwn.net/Articles/412603/ https://lwn.net/Articles/412603/ pboddie <blockquote>Someone at Nokia get's it.</blockquote> <p>I feel obliged to follow up to this. In fact, in turns out from some recent <a rel="nofollow" href="http://tsdgeos.blogspot.com/2010/10/qt-gitorious-merge-requests-and-open.html">blogging</a> that Nokia's contributor licence grants Nokia the opportunity to release contributed code under proprietary or permissive licences, so I guess Nokia doesn't get it after all.</p> Sun, 31 Oct 2010 18:50:53 +0000 Project Harmony https://lwn.net/Articles/411180/ https://lwn.net/Articles/411180/ anselm <p> This is like countries calling themselves »The Democratic People's Republic of Somewhere«. Chances are that such a place isn't in fact a republic (usually a dictatorship of sorts) and isn't particularly democratic, meaning that most people there don't get much of a say in what goes on, either. </p> Thu, 21 Oct 2010 23:38:25 +0000 Project Harmony https://lwn.net/Articles/411163/ https://lwn.net/Articles/411163/ nix <div class="FormattedComment"> Calling a project 'Harmony' is like calling a project 'Open*': a guarantee of acrimony. (Open* is also a guarantee of a considerable degree of closedness.)<br> <p> </div> Thu, 21 Oct 2010 21:37:06 +0000 Project Harmony https://lwn.net/Articles/410757/ https://lwn.net/Articles/410757/ foom <div class="FormattedComment"> Given how completely *unharmonious* Apache Harmony was (due to choosing a license that made it impossible to share code with the other already existing free Java class libraries), I'd be rather wary of copying its name at all. :)<br> </div> Wed, 20 Oct 2010 13:19:47 +0000 Project Harmony https://lwn.net/Articles/410741/ https://lwn.net/Articles/410741/ pboddie <blockquote>I don't find its sub-optimalability to be a reason for publishing a sensational hypothesis, the better and pragmatic approach is probably to try and actually do something about fixing it, constructively.</blockquote> <p>Well, it looks like an open-and-shut case to me: Canonical's position is that there's no other way that would work on a global basis, so that's the way it is. As for sensationalism, there's a single contributor agreement for a huge list of projects which, aside from various valid points made elsewhere about balancing project and contributor interests according to each project's specific profile, looks like quite a land grab at first glance.</p> <blockquote>If my recollection is correct, Canonical are underwriting just such an initiative, called (for want of a better name), "Project Harmony"—where the intent is not to discuss the perceived merits (or disadvantages) of Copyright assignment, but on how to make the process annoy the least number of people when it does crop up.</blockquote> <p>Sure, lots of projects usually decide to adopt some kind of contributor agreement, and it arguably makes sense to prevent "agreement proliferation", but the agreement in question isn't a great advertisement for the company leading such an initiative. And they could have waited until the eventual demise of Apache Harmony before stealing its name.</p> Wed, 20 Oct 2010 11:42:46 +0000 Project Harmony https://lwn.net/Articles/410655/ https://lwn.net/Articles/410655/ sladen <p>I (personally) find the <a href="http://www.canonical.com/contributors">Canonical Contributor agreement</a> to be sub-optimal in its current state (which is the reason why <em>I</em> have not signed it).</p> I don't find its sub-optimalability to be a reason for publishing a sensational hypothesis, the better and pragmatic approach is probably to try and actually <em>do something</em> about fixing it, constructively. <blockquote><i>"...seeking guidance about what is normal or typical around collaborating with others on such a basis."</i></blockquote> If my recollection is correct, Canonical are underwriting just such an initiative, called (for want of a better name), "<b>Project Harmony</b>"&mdash;where the intent is not to discuss the perceived merits (or disadvantages) of Copyright assignment, but on how to make the process annoy the least number of people when it does crop up. Wed, 20 Oct 2010 10:21:30 +0000 Kuhn: Canonical, Ltd. Finally On Record: Seeking Open Core https://lwn.net/Articles/410608/ https://lwn.net/Articles/410608/ nim-nim <div class="FormattedComment"> I'd be very surprised if Mark Shuttleworth hadn't though a lot about going open core (not saying he has actually decided to pass the Rubicon). Do read the numerous articles Matt Assay wrote before his hire by Canonical. They were an repeated apology of this model (and if you think Alfresco is anything but open core, show me the distribution that managed to package a working copy of it). There is no way anyone would have hired Matt Assay unless they were already leaning open-core side.<br> <p> <p> </div> Tue, 19 Oct 2010 20:17:15 +0000 Dual Licencing and Central Copyright Holders. https://lwn.net/Articles/410565/ https://lwn.net/Articles/410565/ jspaleta <div class="FormattedComment"> And the standard rebuttal to this train of thought is that the FSF makes a legally binding promise not to take any of the code it has copyright control over proprietary in the language of the copyright assignment contract you sign with the FSF. <br> <p> Such legally binding promises come in many forms. Granted, the FSF's promise-back is incompatible with proprietary dual licensing. But there are other "promise-back" forms which can be used by businesses who do want to engage in proprietary dual-licensing which still consider contributor interests and are not one-side landgrabs by a central authority. The FSF even proposes a clause that allows for proprietary dual-licensing that contributors can agree to. See this article:<br> <a href="http://www.fsf.org/blogs/rms/assigning-copyright">http://www.fsf.org/blogs/rms/assigning-copyright</a><br> <p> And as I've already written elsewhere a promise-back can take the form of a latching agreement between the central authority and a 3rd party which would provide for re-licensing that would open up the business opportunities to new parties if the central entity does something egregious such as shuttering the development of the open codebase. As is the case with the agreement between Trolltech and the Free KDE Free Qt Foundation.<br> <p> The devil is always in the details. And yes, on its face the idea of standardizing some of this legal language seems like a good idea, but it could also go very wrong. If Project Harmony ends up institutionalizing an effort to legitimize a blanket copyright assignment policy to a central authority..then I will consider to have been a failure. There must be a sincere effort to craft _standard_ contributor agreements that equitably balances the business interests and contributor interests. A blanket copyright assignment policy like the one Canonical is currently following does not balance those interests. <br> <p> -jef<br> </div> Tue, 19 Oct 2010 16:11:13 +0000 "A buzzword that has no agreed upon meaning" https://lwn.net/Articles/410519/ https://lwn.net/Articles/410519/ pboddie <blockquote>If a vague unknown new term "has no agreed upon meaning", why is it being used here—and for sensational ends? When a third-party undertakes such activities, the libre/open community quietly counter by pointing out this tactic is known as "FUD".</blockquote> <p>Only if they run out of other arguments first. See also "ad hominem".</p> <p>In any case, the article raises some interesting points which do not appear to be adequately addressed by a response whose final paragraph contains emphasised keywords and phrases, potentially to enliven prose which resembles something from a human resources handbook. It may be typical in the more micromanaged sections of the Ubuntu community to berate a critic for their impertinence, where dissent and criticism can be blunted or suppressed in the shadow of the ever-present "Code of Conduct", but there's definitely nothing inappropriate in applying scrutiny to the activities of a commercial entity that may serve as one of the first points of contact for anyone starting out in the realm of Free Software development, seeking guidance about what is normal or typical around collaborating with others on such a basis.</p> <p>Meanwhile, we are left with some legitimate questions:</p> <ul> <li>Why do people need to sign over copyright when even "permissive" projects like Python are happy with <a rel="nofollow" href="http://www.python.org/psf/contrib/contrib-form/">licence-based</a> contributions? (This is quite a normal approach, as I understand it.)</li> <li>Doesn't the lack of credibility of other organisations (such as Sun) in building viable external communities raise any concern in an organisation seeking to copy such efforts, or is the idea to downplay the efforts of external contributors?</li> </ul> <p>I've witnessed quite a few discussions about community-building and recognising/rewarding contributors, so I'm intrigued about the thinking going on behind the scenes. Maybe I should have read Jono Bacon's book...</p> Tue, 19 Oct 2010 13:53:36 +0000 "A buzzword that has no agreed upon meaning" https://lwn.net/Articles/410492/ https://lwn.net/Articles/410492/ sladen <p>If a vague unknown new term "<strong>has no agreed upon meaning</strong>", why is it being used <em>here</em>—and for <em>sensational</em> ends? When a third-party undertakes such activities, the libre/open community quietly counter by pointing out this <strong>tactic is known as "<a href="http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt">FUD</a>"</strong>.</p> <p>Licensing discussions (which I believe most FSF/SFLC-involvees are intimately familiar with) are successful when they gentle affairs, undertaken calmly, with solid facts in-hand (such as copies of wording of the GPL text). If spreading FUD was apparently <a href="http://www.gnu.org/philosophy/sco/subpoena.html">not acceptable when SCO did it</a>, why is it suddenly acceptable for a figurehead of the Software Freedom Conservancy?</p> <p>Input tends to be <strong>greatly valued</strong> when it arrives <strong>without sensation</strong> and based upon <strong>hard foundations</strong>. …Indeed, input <em>also</em> tends to be valued when it is <em>either</em> non-sensational <em>or</em> concrete in nature. By failing (IMHO) to provide either, I fear that this piece has probably missed its intended target.</p> Tue, 19 Oct 2010 12:18:55 +0000 Dual Licencing and Central Copyright Holders. https://lwn.net/Articles/410496/ https://lwn.net/Articles/410496/ pboddie <blockquote>The standard reply to this train of thought is: the Free Software Foundation also thinks copyright assignment is a good idea.</blockquote> <p>Which is mentioned in the article as a means to divert criticism of a particular form of copyright assignment by claiming that others doing something similar are actually doing the same thing if you squint hard enough. The crucial difference is what the people wanting your copyright promise (or don't promise) to do once they have it.</p> <blockquote>Surely sensible things can be said about the pros and cons of copyright assignment, or lack thereof, especially in the bigger scheme of things -- but contributing code to a project you didn't start without reading the conditions that govern code contribution is just as silly as accepting any contribution to a project you did start without checking its license and copyright.</blockquote> <p>Sure, which is why people quite often take their ball away and start their own game somewhere else, as the experiences of Sun Microsystems can surely attest.</p> Tue, 19 Oct 2010 12:10:59 +0000 Dual Licencing and Central Copyright Holders. https://lwn.net/Articles/410486/ https://lwn.net/Articles/410486/ hppnq The standard reply to this train of thought is: the Free Software Foundation also thinks copyright assignment is a good idea. And the FSF are the good/bad [*] guys. <p> Surely sensible things can be said about the pros and cons of copyright assignment, or lack thereof, especially in the bigger scheme of things -- but contributing code to a project you didn't start without reading the conditions that govern code contribution is just as silly as accepting any contribution to a project you did start without checking its license and copyright. <p> [*] Pick one. Tue, 19 Oct 2010 11:44:57 +0000 Kuhn: Canonical, Ltd. Finally On Record: Seeking Open Core https://lwn.net/Articles/410468/ https://lwn.net/Articles/410468/ mjthayer <div class="FormattedComment"> <font class="QuotedText">&gt; [...] Nokia/TrollTech's lesson learned [was]: “don't do an Open-Core-style contributor agreement, you'll regret it”.</font><br> <p> I might venture a different interpretation of this change of heart (this is just my guess, as I have never been employed by Nokia or Trolltech). The way I see it, Nokia and Trolltech have/had very different business models. Trolltech's income was dependent on people purchasing non-FLOSS licences for Qt. If they hadn't had the rights to sell these licences they would either have had to find a new business model or go out of business (along with all their contributions to FLOSS I might add). I assume that their main benefit from the GPLed version (aside from the good feeling that developers get from doing FLOSS software and getting paid for it) was the advertising that it got them for their proprietary licenced version, and obviously they decided, rightly or wrongly, that the additional contributions they would have got from being fully free were not worth the risk to their revenue.<br> <p> On the other hand, Nokia makes its money from selling hardware, and they need software to do that, not for its own sake. Presumably for them any external contribution of note to Qt is money that they don't have to put into it themselves, and the former Qt licencing model is sufficiently different from their own business model for the additional distraction not to be worth the extra revenue (or the loss of contributions).<br> </div> Tue, 19 Oct 2010 09:27:14 +0000 Kuhn: Canonical, Ltd. Finally On Record: Seeking Open Core https://lwn.net/Articles/410464/ https://lwn.net/Articles/410464/ mjthayer <div class="FormattedComment"> <font class="QuotedText">&gt; Here's a non-exhaustive list of projects that Canonical feels copyright assignment is necessary for:</font><br> &gt;<br> <font class="QuotedText">&gt; <a href="http://www.canonical.com/contributors">http://www.canonical.com/contributors</a></font><br> &gt;<br> <font class="QuotedText">&gt; Add to that much of the utouch stack (gies, grail, ginn, grope, etc...) and the new font.</font><br> <p> Most of those don't look very interesting for dual licencing (which I think is mainly good for software libraries that might be useful for non-free software - Qt being a prime example), with a possible big exception for the utouch stack. I can see though that some might be good for open core (e.g. plugins to use Bazaar in combination with some proprietary systems that don't interest FLOSS developers enough for them to produce free alternatives, or integrating some of the infrastructure tools into semi-proprietary phone OSes).<br> <p> Personally I wish Canonical success in pulling that off and still keep the juicy bits FLOSS.<br> </div> Tue, 19 Oct 2010 08:32:48 +0000 Open Core and proprietary relicensing https://lwn.net/Articles/410446/ https://lwn.net/Articles/410446/ kripkenstein <div class="FormattedComment"> <font class="QuotedText">&gt; I tend to use proprietary relicensing and “Open Core” somewhat interchangeably because they typically have the same outcome.</font><br> <p> That's debatable. In any case, 'open core' and 'dual licensing' are very different in terms of what they actually are, regardless of their outcome. <br> <p> Anyhow, ignoring the terms we use, Canonical appears to support giving the option to purchase a non-FOSS license for FOSS code. There are upsides and downsides here. Like RMS, I tend to not see a huge problem, it depends on the situation.<br> <p> Were Canonical going to, instead, start selling proprietary code, I (and RMS) would strongly disapprove.<br> </div> Tue, 19 Oct 2010 00:19:29 +0000 Dual Licencing and Central Copyright Holders. https://lwn.net/Articles/410444/ https://lwn.net/Articles/410444/ pboddie <blockquote>2009: Nokia drops copyright-assignment completely on Qt and moves to a contributor agreement that is a based on a license from the external contributor to Nokia.</blockquote> <p>I think this highlights a very serious objection to copyright assignment obligations: that contributors who may well have a firm opinion on the licensing of their own work must relinquish control (to the party requesting copyright assignment) over how such work is licensed. Although this doesn't matter too much to people who apply permissive licences to their work - you can read the "but you can still make your own code available yourself" defence familiar from permissive licence advocacy in Canonical's agreement - it has the effect of taking works that are (or would otherwise be) available under, say, copyleft terms and effectively making them permissively licensed (or worse).</p> <p>Thus, such "agreements" are like saying, "Well, we know that the project in question is GPL-licensed and that you feel that this is most appropriate for your contributions, but we want the ability to disregard all that, because we might not share your concerns or even respect your views after all." At least contributions based on licensing preserve a decent level of transparency and respect for all involved.</p> Mon, 18 Oct 2010 23:10:09 +0000 Kuhn: Canonical, Ltd. Finally On Record: Seeking Open Core https://lwn.net/Articles/410440/ https://lwn.net/Articles/410440/ jspaleta <div class="FormattedComment"> Here's a non-exhaustive list of projects that Canonical feels copyright assignment is necessary for:<br> <p> <a href="http://www.canonical.com/contributors">http://www.canonical.com/contributors</a><br> <p> Add to that much of the utouch stack (gies, grail, ginn, grope, etc...) and the new font.<br> <p> <p> -jef<br> </div> Mon, 18 Oct 2010 22:27:18 +0000 Kuhn: Canonical, Ltd. Finally On Record: Seeking Open Core https://lwn.net/Articles/410439/ https://lwn.net/Articles/410439/ mjthayer <div class="FormattedComment"> I don't quite get what this is all about. I thought that dual licencing (or open core for that matter) was only useful if you have an important code base to which you exclusively own the copyrights (or have them assigned). And in that situation there is a certain quid pro quo for the copyright assignment in that the owner of the code base makes it available under a FLOSS licence in the first place. What code base does Canonical own though that is of such interest to the rest of the world?<br> </div> Mon, 18 Oct 2010 22:15:25 +0000 Don't like to change too much once it's up. https://lwn.net/Articles/410434/ https://lwn.net/Articles/410434/ davide.del.vento <div class="FormattedComment"> Sorry I wasn't clear (to partially vindicate myself: I'm not an English native speaker).<br> <p> What I meant was a completely new "follow-up" post, much shorter, with a different title, taking into account from the beginning what you wrote in the postface. You should link the new post right at the beginning of the "old" one.<br> <p> But as I said, I completely agree with you, so that new post would only be useful to others who haven't read (and/or discussed and/or fully understood your points).<br> </div> Mon, 18 Oct 2010 21:56:33 +0000 Open Core and proprietary relicensing https://lwn.net/Articles/410433/ https://lwn.net/Articles/410433/ bkuhn <p>I tend to use proprietary relicensing and &ldquo;Open Core&rdquo; somewhat interchangeably because they typically have the same outcome. &ldquo;Open Core&rdquo; is a buzzword that has no agreed upon meeting. I define what I mean by it <a href="http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html">elsewhere in my blog</a> and that post was linked to from the blog post in question, too.</p> <p>I'm planning another post next week to discuss this question of whether there is a real difference between &ldquo;Open Core&rdquo; and proprietary relicensing.</p> <p>As for <q>dual licensing</q>, that's a term that is highly confusing, because Perl's license is also a dual license, but that's not the same was what people mean by the stuff we're talking about here.</p> Mon, 18 Oct 2010 21:52:11 +0000 Don't like to change too much once it's up. https://lwn.net/Articles/410431/ https://lwn.net/Articles/410431/ bkuhn <p>It seems disingenuous to me to change anything other than grammar/typos of the original post after the fact, that's why I added things at the end. People have already commented on the original and making it go away seems like playing revisionist history to me. The title was a poor choice; I've been convinced of that, but changing it now seems like an attempt to take back what's already been said.</p> Mon, 18 Oct 2010 21:47:22 +0000 Open Core != Dual Licensing https://lwn.net/Articles/410420/ https://lwn.net/Articles/410420/ kripkenstein <div class="FormattedComment"> The author mixes up 'open core' with 'dual licensing' (specifically dual licensing with FOSS and proprietary options).<br> <p> 'Open core' is having some FOSS product, and selling additions to it, that are not FOSS. Open core tends to be problematic since the motivation is to keep the open core limited, so you can sell additions to it. But the community can fix those limitations by writing FOSS code. So there is tension there.<br> <p> 'Dual licensing' is having a single codebase, and making it available under several options. One approach there is to offer a FOSS version, typically GPL, alongside a proprietary license. So you can use it under the GPL, or you can pay for a license and use it without opening up your own code.<br> <p> Obviously there are some similarities between 'open core' and 'dual licensing'. But the main problem with 'open core', mentioned above (the tension between keeping the core limited, and the community's desire to improve it) does not exist with dual licensing.<br> <p> I'm not saying dual licensing is great. It has downsides as well. But the author talks about these two very different things as if they were one.<br> <p> It looks like Canonical is positive about dual licensing. I don't see much a problem with that personally. If they were going to do open core, I'd be very annoyed.<br> <p> Note that dual licensing is also separate from requiring copyright assignment (which Canonical does). Copyright assignment can help with dual licensing, as you own the code, and can offer additional licenses of it. But, there are other ways. You can allow community members to submit code under a permissive license which is compatible with the copyleft one. That doesn't stop you from offering a proprietary license to the code you own.<br> <p> </div> Mon, 18 Oct 2010 19:09:56 +0000 Dual Licencing and Central Copyright Holders. https://lwn.net/Articles/410407/ https://lwn.net/Articles/410407/ jspaleta <div class="FormattedComment"> There are many ways to provide a legal construct that protects the interests of the unpaid contributor when copyright assignment is desired when there are business interests involved in any sort of dual license business model that may involve the option of proprietary licensing. <br> <p> Shuttleworth's choice of Qt as an example of blanket copyright assignment is remarkable in its irony. When you really look at the history of it, its says the exact opposite of what Shuttleworth wants.<br> <p> 1998!!!!!! TrollTech enters into an agreement with the KDE Free Qt Foundation which gives the foundation the ability to relicense the Qt codebase as BSD if TrollTech stops development of the open version. <br> <br> <a href="http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php">http://www.kde.org/community/whatiskde/kdefreeqtfoundatio...</a><br> <p> Let me make this very clear. In 1998 TrollTech agrees to an escape hatch clause which would pretty much destroy a for-pay licensing scheme by making a BSD licensed Qt available for anyone to bundle into a proprietary application if they ever walked away from the open codebase. That is a very strong, legally binding, statement of TrollTech's commitment to the external contributors. From the date of that original agreement onward, it's no longer a naked blanket assignment. Because of that escape-hatch agreement, some of the most egregious potentially damaging actions TrollTech could take are mitigated. It may not be an ideal solution for some, but as a compromise that tries to weight both business and contributor interests its extremely instructive. <br> <p> 2009: Nokia drops copyright-assignment completely on Qt and moves to a contributor agreement that is a based on a license from the external contributor to Nokia.<br> <p> <a href="http://labs.qt.nokia.com/2009/05/11/qt-public-repository-launched/">http://labs.qt.nokia.com/2009/05/11/qt-public-repository-...</a><br> <p> This is a good read. To quote:<br> "Granted, our releases have been open source, but our development model has not."<br> ...<br> "Our goal with the new site is to make this process as simple and welcoming as possible, and that’s why we will no longer ask for copyright assignment."<br> <p> Someone at Nokia get's it. And I'm very sure that there are people inside Canonical that get it as well. Unfortunately, those people aren't Shuttleworth and have near zero say in setting corporate policy with regard to equitably crafting copyright assignment. <br> <p> -jef<br> </div> Mon, 18 Oct 2010 17:11:55 +0000 Yes, title is exaggeration, but danger is there. https://lwn.net/Articles/410409/ https://lwn.net/Articles/410409/ davide.del.vento <div class="FormattedComment"> I agree with you. I think that you would have made a better point with a shorter post on your blog, which would have included your final clarification from the beginning - so I recommend that you re-write it. But I see your points, and I completely agree with you: I don't like where Canonical is driving Ubuntu at all.<br> </div> Mon, 18 Oct 2010 17:11:42 +0000 Yes, title is exaggeration, but danger is there. https://lwn.net/Articles/410406/ https://lwn.net/Articles/410406/ bkuhn <p>I agree my title was a bit of an exaggeration. I'd change it, but I am not sure that would clarify things, and probably would look strange. Based on feedback, I did add a note at the bottom of the post making it clear that this reading of these events is my opinion, not fact. The only thing that's absolutely true here is that Canonical, Ltd. is &ldquo;leaving its options open&rdquo; for &ldquo;Open Core&rdquo; and/or proprietary relicensing as a possibility.</p> <p>As for the distinction between Open Core and proprietary relicensing, I think there are some subtle distinctions there. However, I have yet to see a company implement a pure <a href="http://www.fsf.org/blogs/rms/assigning-copyright">&ldquo;exception selling&rdquo; model as RMS has proposed</a>. Every example I've seen has never been purely that. Even if it starts that way, it moves toward an &ldquo;Open Core&rdquo; style over time. Based on the feedback of this blog post, I'm planning to write a more comprehensive post about this particular part of the issue.</p> Mon, 18 Oct 2010 16:34:12 +0000 Kuhn: Canonical, Ltd. Finally On Record: Seeking Open Core https://lwn.net/Articles/410383/ https://lwn.net/Articles/410383/ mfedyk <div class="FormattedComment"> "Should we just accept that proprietary network services like UbuntuOne, integrated on nearly every menu of the desktop, as reasonable merely because it might help Canonical, Ltd. make a few bucks? Do we think we should abandon copyleft's assurances of fair treatment to all, and hand over full proprietarization powers on GPL'd software to for-profit companies, merely so they can employ a few FLOSS developers to work primarily on non-upstream projects? integrated on nearly every menu of the desktop, as reasonable merely because it might help Canonical, Ltd. make a few bucks?"<br> <p> yes.<br> <p> as long as it offers the content in open formats like ogg vorbis and friends with an option for popular formats like mp3 (so you don't have to convert it again for players that don't support ogg).<br> <p> "Do we think we should abandon copyleft's assurances of fair treatment to all, and hand over full proprietarization powers on GPL'd software to for-profit companies, merely so they can employ a few FLOSS developers to work primarily on non- upstream projects?"<br> <p> no.<br> <p> because of the second quote above I am glad I switched away from ubuntu nearly two years ago. the reason at the time was a response to a string of low quality releases. (switched to centos5, even on the desktop. I use fedora for some bleeding edge experimental work, but anything that needs to work and stay working runs centos).<br> <p> I have no problem with canonical making money. I do have a problem if newer releases are not better than previous ones. I do have a problem if they want to distribute with different terms than what they received (copyright assignment)<br> <p> </div> Mon, 18 Oct 2010 14:42:33 +0000 Dual Licencing and Central Copyright Holders. https://lwn.net/Articles/410385/ https://lwn.net/Articles/410385/ gmatht <div class="FormattedComment"> Requiring copyright assignment can be a little controversial, as it creates a divide between the copyright holder who can monetize the other's work, and the others who basically have the right to work for free. I think this was an issue in the OO/LibreOffice fork.<br> <p> Prehaps when it is desired to sell non-free licenses but not desired to have such a split in the community, one could assign copyright to a not-for-profit that distributes the code under one of the GPLs, and sells licenses for non-GPL use. The money could possibly be used to pay development related expenses, distributed in some impartial way to the contributors or charities they support.<br> </div> Mon, 18 Oct 2010 14:25:48 +0000 Kuhn: Canonical, Ltd. Finally On Record: Seeking Open Core https://lwn.net/Articles/410382/ https://lwn.net/Articles/410382/ SEMW <div class="FormattedComment"> This is some strange usage of the words 'On Record' (by Kuhn) that I wasn't previously aware of? Whether or not you agree with his analysis of the Qt/Gtk answer as containing hidden hints that, if you read between the the lines, reveal that Canonical may be seeking an Open Core model, it certainly isn't Canonical going on record that they are.<br> <p> By the end of TFA, Kuhn's asserting things like that in the Qt/Gtk answer Shuttleworth "explains at great length how lucrative and important “Open Core” is". Which, if you actually read the transcript, is just nonsense.<br> <p> Personally, I don't see that Kuhn's analysis of the answer is correct anyway. It seems pretty clear to me that the reference to Trolltech having had "many options including proprietary licensing" is referring to them selling licenses for Qt to companies that wanted to make proprietary software with it and so that couldn't use the GPL'd version, back when it was GPL and not LGPL. That isn't an Open Core model, it's just dual-licensing (i.e. all of the software that is sold under a proprietary licence is also available under the GPL -- as opposed to the software available under an open license being a subset (the 'core') of that available under a proprietary license; which is the Open Core model as I understand it).<br> </div> Mon, 18 Oct 2010 14:03:12 +0000 Kuhn: Canonical, Ltd. Finally On Record: Seeking Open Core https://lwn.net/Articles/410379/ https://lwn.net/Articles/410379/ jdub There are already some vibrant discussion threads about this on <a href="http://identi.ca/conversation/55760715">identi.ca</a> and <a href="http://news.ycombinator.com/item?id=1800766">Hacker News</a>. Mon, 18 Oct 2010 13:47:52 +0000