Should OpenSolaris Use the GPLv3 License? The Q&A

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

[FYI: the following is a very long exploration of issues relating to the GPLv3 and OpenSolaris; if you’re not a follower of either of those subjects, this is one to skip – sog]

If you’re of a historical mindset, you might trace the roots to this particular discussion back to an exchange between Jonathan Schwartz, Sun’s CEO, and Rich Green, EVP Software for Sun. That’s led to all sorts of interesting messaging issues, including the (mistaken) impression held by some that OpenSolaris has already been released under the GPL.

But in practical terms, that was mere kindling. The real fuel for the fire was provided on Tuesday of last week, when Sun’s Stephen Harpster openly solicited the community’s input on the possibility of dual licensing OpenSolaris under the GPLv3 in addition to the CDDL. As could probably have been anticipated, opinions were forthcoming. And then some. The resulting explosion of dissent and concern has generated several hundred emails – many of them more than slightly agitated – and spawned perhaps a half a dozen conversational sub-threads.

Given that I have a different perspective on the prospects of a GPLv3 licensed OpenSolaris than some of the community members, I thought it might be useful to explore some of the issues and concerns in a Q&A.

Q: To begin, how about the usual disclaimers?
A: Sun, the organization that spawned the OpenSolaris project, is a RedMonk client. Several commercial vendors that have substantial interests in Linux, such as IBM, are RedMonk clients. With respect to the Solaris technologies, I’ve been both complimentary and critical.

Q: Are you a member of the OpenSolaris community?
A: As an observer, perhaps. I subscribe to the main open-solaris discuss list, have popped my head in there a time or two before, and attend user group meetings when I’m not travelling every (damn) week. Further, I was around when OpenSolaris was born, and am fortunate enough to know many of the engineers that work on it personally. I do not, however, contribute any code to the platform, nor do I run it extensively. So my opinion is just that of an interested observer; I would not presume to instruct the community on what’s best for it, because I’m not engaged to the degree that many of the list participants are.

Q: It’s safe to assume then that you believe this decision should be made by the community, not Sun?
A: Yes. If, like MySQL, you run a project that’s not structured around accepting outside contributions, you preserve the ability to make unilateral decisions around project specifics. OpenSolaris is not, however, such a project. Although the process for contributing to the codebase is still far more complex that most would like it to be, the project is intended to be open from a participatory standpoint. This being the case, it would not be appropriate – IMO – to try and enforce a licensing preference on an unpersuaded community. No taxation without representation, and so on.

Q: What would the outcome be if Sun did indeed try to impose the GPLv3 on the OpenSolaris community?
A: Poor. In a worst case scenario, it could do irreparable damage to the relationships Sun has built with its sapling of a community, not to mention its much repaired open source reputation. The folks at Sun, I’m sure, are aware of this which is why I think it unlikely that they would pursue this course of action.

Q: How do you think the community would vote with respect to the GPLv3 if polled right now?
A: It’s difficult to say with any degree of accuracy, because the vast majority of the community has so far been silent on the issue. But certainly the majority of the vocal participants in the discussion are against the idea – some violently so.

Q: Before we get to those objections, how about a little history: why was the CDDL license chosen originally?
A: Well, there are two different versions of this particular story which are too involved to cover here. Suffice it to say that on the one side we have the contention that the license was selected purely for its merits, and on the other we have the assertion that it was chosen at least in part for its incompatibility with the GPLv2. Regardless of which side is correct, I’m of the opinion that the license chosen at the time was a necessary choice to ensure its survival. With no one convinced at the time that OpenSolaris would survive as an open source project, I think the GPLv2 compatibility would have allowed Linux to cherry-pick from technical differentiating features like DTrace and leave the project for dead. I’ve said positive things about the CDDL license in the past, and have no problem with it now. The question I’m asking is whether or not the OpenSolaris project should have the same concern about being strip mined that I believe it needed to have at its inception, and my belief is that it does not.

Q: So you believe that the OpenSolaris project shouldn’t be concerned with the GPLv3?
A: No. First, we don’t know in final terms what the license will look like, although we do have a pretty good idea. Second, there are always concerns with respect to licensing – what are the encumbrances, conflicts, and so on. What I am saying instead is that I don’t think applying the GPLv3 license alongside of the CDDL would harm OpenSolaris as a technology.

Q: Why?
A: Three main reasons. One, the project is established. Although I certainly do not subscribe to Paul Murphy’s prediction that the OpenSolaris community is poised to eclipse the Linux community in either size or activity, I certainly believe that the community has established itself and has been very successful – and take public exception when I’ve seen claims to the contrary. The very furor that this discussion has caused, as someone pointed out to me the other day, should be proof enough that OpenSolaris has a passionate and engaged community.

Two, from what I’m led to believe from conversations with engineers on both the Linux and Solaris kernels, the effort required to port some of the differentiating technologies from Solaris to Linux or another is decidedly non-trivial. So as much as I’d like to see ZFS in Linux, and that’s clearly possible, it’s not an overnight effort.

Three, the Sun folks asked about GPLv3, not GPLv2. Linux is licensed under the latter, and if Linus has his way, it’s not likely to be relicensed any time soon as he’s not terribly impressed with the revision. Nor am I, for that matter, but that’s a discussion for another time, and I’ve got folks working to persuade me that I’m wrong.

Q: What about the objections you’ve seen on list? Are there legitimate questions being asked?
A: There are, absolutely, very legitimate questions being asked on list. If you distill them down, most of the objections into the following categories:

  1. I don’t like/respect/* the FSF/GPL/Linux/*
  2. I don’t like the thought of Sun making this decision for us
  3. This doesn’t solve real, existing problems that we have. optional clauses – a. creates new problems, b. detracts/distracts from efforts to solve the existing ones
  4. I don’t see the point/benefit/etc, or the existing license is fine, let’s not fix what isn’t broken

Q: Let’s take those in order: how about the folks in the first bucket?
A: We’ll simply have to agree to disagree. I’m (far) more of a pragmatist with respect to open source than the folks at the FSF would approve of, and I don’t necessarily subscribe to their views on freedom, but I cannot have anything but respect for the work of that organization. They’re a group that can legitimately say that they’ve changed the world. There aren’t many of those around, and that deserves respect, IMO.

Likewise, Linux has been frequently disparaged over the course of the thread, but very little recognition has been paid to its success. Irrespective of what you think of its technical merits, again, this is a project that has changed the face of software. I’d hope that OpenSolaris community members would not try to argue that there’s nothing that they could learn from the success that Linux has enjoyed.

As for the license, at least they’re not alone. There’s a great deal of fear, uncertainty and doubt surrounding the GPL still; many enterprises are terrified of it. That said, two of the most successful open source projects around use the current version (Linux and MySQL), another prominent project has pledged to go to the new version (Samba), and it’s been the preffered license of choice for open source projects on Sourceforge for some time. Were some of the reactions from the GPL community to the CDDL out of line? Yes. Which is why it’s a shame to see the same license ignorance and mudslinging repeated.

Q: And the folks in the second bucket?
A: Given the history behind this question, it’s a legitimate concern. But that makes the flamewar aspect to this thread all the more puzzling. While Stephen’s original email is a little Sun-centric, it’s also soliciting input and thoughts. Given the fears here, I would have thought a surfacing of the subject for discussion would be welcomed, but that’s not the reaction in the majority of the responses I’ve seen.

Q: How about the third: those who feel like it doesn’t solve existing problems, makes them worse, or creates new ones?
A: There’s quite a bit of truth in many of the responses that fall into this category. It’s absolutely true, for example, that dual licensing does nothing to remedy issues currently gating contributions back to Solaris. It’s also true that dual licensing is likely to create new issues; some bad, but some good. I’m not convinced, however, that the resourcing questions are quite as zero sum as they’re made out to be. In other words, I find it difficult to believe that dual license would necessitate the removal of resources from existing problems such as the barriers to entry. Are the lawyers that would presumably be involved, as an example, really the same folks that would address the current governance issues?

That said, neither am I as close to the resourcing for the project as some of the thread’s participants: it would be very useful, I think, for the community to have some estimation of the effort required to more precisely judge the potential impact.

Q: And how about the last category of objection? Those who don’t see the benefits, or are comfortable with their current growth?
A: Although I’ve conflated them above, these are in fact two separate objections. Let’s look at the comfortable folks first. Much of the objection here, I believe, is fueled by a natural tendency on the part of many of us – myself included – to resist change. Why change, after all, when the community has been successful to date? Apart from the fact that I believe many of the fears are somewhat overblown – if you don’t like the GPL, after all, you’re not forced to use it – I think this is a potentially dangerous line of thinking.

The rebirth of Solaris as an open source project is a perfect example. The easy path would have been to market Solaris solely towards Sun’s language of choice – Java. Instead, the Solaris engineers took what was the right path, in my opinion, and tried to build bridges to other communities like Mono, PHP, and Ruby. That was a change, and a beneficial one from where I sit.

So before concluding that the current trajectory of the project is sufficient, the OpenSolaris community might want to consider whether or not a license change could open even more doors for you. You can never have enough friends in the software world. Which leads me back to the folks that don’t necessarily see the upside to the risk.

Q: Yes – how would the project benefit from an application of the GPLv3?
A: Several ways. First, it would engage a wider community of developers – those that prefer the GPL. Whether or not you share their viewpoint shouldn’t be the issue, IMO; attracting the widest possible audience should. There was a sizable contingent of developers at the Sun BOF at OSCON that expressed a strong preference for a GPL licensed Solaris. If you can bring those types of developers into the fold without jeopardizing the project itself, I think you’d have to consider doing so.

Second, while I’ve defended the CDDL as mentioned above, as has Bryan in this thread, the fact is that the license does not have much traction. I speak with a great many project maintainers and commiters, and very few of them are considering the CDDL. This does not, of course, mean that the license itself is not suitable or appropriate, merely that the lack of acceptance mitigates its utility to mainstream audiences.

Perhaps most importantly, it allows for simpler and more straightforward recombination of projects. The CDDL license is, as previously discussed, incompatible with the GPL. This has protected the project to a degree, but also throttled its ability to embrace complimentary technologies. For example, the package management functionality from Debian. No, a dual CDDL/GPLv3 license wouldn’t address this specific case, unless Debian were to move to v3 as well, but it’s an excellent example of how cross-pollination could potentially benefit OpenSolaris. While many in the community don’t think so, I’m personally of the belief that Solaris could benefit strongly from GNU userland. GPLv3 would theoretically make such mashups possible, while the CDDL is less ideal from this standpoint.

Q: So, to sum up, you think OpenSolaris would benefit from a dual license?
A: Well, decisions of this magnitude have to be made on a cost/benefit basis, and I don’t think anyone – myself certainly included – has a full picture of what the precise costs would be. But I’d say that of the objections I’ve seen, most are solvable, and the upside is potentially significant. To reiterate, I would not presume to instruct the community here or elsewhere, but my initial opinion – subject to review – is that the GPLv3 would be a substantial boon to the project.


  1. CDDL could be compatible with GPL license,however GPL is only compatible with itself.This is a big limitation.There is a proof around a port without problems of Dtrace and ZFS to BSD system.CDDL can give and take code covered with other Open license (and not only these) perfectly.CDDL has not protected the project.

  2. Giacomo: well, the distinction re: the licenses i think is mostly a matter of semantics. what’s germane here is that the two licenses in question cannot be combined. i respectfully disagree that CDDL has not protected the project; while DTrace has, as you note, been ported to other projects at least as a POC it has not, and cannot, be ported to Linux according to the licenses (although Jonathan did give his verbal ok at OSCON).

    given that Linux is one of the more significant competitive threats that Solaris faces, i think that’s significant, and an indication that the CDDL has in fact shielded Solaris.

  3. Stephen,
    in the thread, Stephen Harpster pointed out not to use the pure GPLv3, but a GPLv3 with an “assembly exception”, whatever that’s meant to be.
    How is this going to convince and win anyone over?
    All I can do is explain to fellow coders why the CDDL is a good license and why Sun chose it for OpenSolaris, and, of course, use CDDL for some of my own creations.
    IMHO, if Sun wanted to get the foot in the door to the GPL devs they should make it known that the Sun Compilers are free now. I haven’t met a single person not being an OpenSolaris user in some way that knew about them being free of charge, and of course being available for Linux x86/x64. Once the foot is in the door, the technical merits of OpenSolaris could outshine the bad feelings of not using “Free Software”.
    You wrote, that you are “more of a pragmatist” and people fond of GNU software seem to be more the religious kind.

  4. Thorough piece, as always. But I think you’re not accurately capturing the major objection that many of us have to dual licensing: dual licensing allows for license-based forks that become unresolvable. That is, if I take OpenSolaris today, and make changes to some file (which, under the CDDL, I am required to release should I distribute a binary that incorporates those changes), the changes can always be pulled straight into any OpenSolaris-based distro. Under a dual license, however, I could make the changes in a file that has stripped one of the licenses — and this change would not be able to be reincorporated into any OpenSolaris distro that retains the dual license, because the (re)addition of the second license would require my explicit consent. This is the fundamental objection that many of us have to dual licensing, and it has nothing to do with the GPLv3 per se.

    Also, one point of technical clarification: it is the GPL that is incompatible with the CDDL, not the other way around. Unlike the GPL, the CDDL does not assert the license of any larger work that incorporates CDDL-based technology. The CDDL is therefore only incompatible with licenses that deliberately assert their own incompatibility — which is exactly what the GPLv2 does.

  5. One thing about developers that prefer a GPL-licensed Solaris (some of which you encountered): the pro-GPLv3 argument is that it would bring more developers to OpenSolaris. However, there is a difference between preferring that OpenSolaris was released under GPL(v2), and actually *switching* to OpenSolaris if GPLv3 was added as a license. I think that the number of people who would switch to OpenSolaris (or would start contributing to it in addition) from Linux would not be significant, or at least not significant enough to offset the risks, some of which you include in your summary, and the important one that Bryan points out.

    We need to be careful to make the distinction between liking GPLv2 better than the CCDL and actually picking an OS because of GPLv3, when looking at the potential number of extra people it might bring to OpenSolaris.

  6. Bryan has captured my concerns exactly – that dual-licensing opens up the possibility of incompatibly-licensed forks. I’m far more concerned by the consequences of dual-licensing than I am by a move to just GPLv3.

  7. patrick: the notion of an exception within the license actually has precedent; both Java and the GCJ employ one. so i don’t believe that would preclude the relicensed OpenSolaris from consideration from free and open source developers.

    as for evangelizing the CDDL, that approach hasn’t been terribly successful to date. it’s possible that it would be in future, but no guarantees.

    on the compiler front, yes, i think it’s important that news of that be wider spread but that doesn’t necessarily attract and build the OpenSolaris community, which should be the goal.

    Bryan: you’re correct. as someone IM’d me yesterday, that major objection was omitted. and candidly, is that a risk? yes. but here’s why i’m less concerned about that.

    as i understand it, for some of the economic reasons you’ve pointed out on list, at the current time nearly everyone who understands the technology well enough to patch it with something you’d want either a.) works for Sun, b.) works for Apple, or c.) is a member of the OpenSolaris community. members of those groups, i’d suspect, would be most inclined to patch upstream. so that’s not a risk.

    eventually, of course, that may not be the case, and some entity may have both the ability and inclination to patch downstream just under the terms of the GPLv3. at which point you have several options: a.) reimplement the patch/feature in upstream, which is inefficient but certainly possible, b.) migrate to the traditional dual license approach, which is GPL/commerical license (the latter of which would permit the relationship, as an example, that you currently have with Apple), c.) respectfully request that the patch be resubmitted back upstream, d.) live without the patch/contribution.

    given the reality of the distribution of Solaris at the moment, i honestly believe this problem is a ways out. even in a worst case scenario, however, it’s useful to remember that Linux has survived – even thrived – despite having multiple incompatible distributions. not, perhaps, at the kernel level but certainly within userland implementations of features like package management. and these forks have not been created out of license incompatibilities, but are rather the result both of organizational politics and different preferred technical approaches.

    in other words, i think the potential issue of a fork is a longer term concern, and one that i wouldn’t lose much sleep over in any event.

    as for the note on GPLv2, as mentioned above i feel this is ultimately a question of semantics, but the distinction seems important to CDDL advocates, so i’ll note that yes, it is the reciprocal provision within the GPL that makes it incompatible with the CDDL. it may be worth noting at the same time, however, that the GPL is not incompatible with BSD style licenses.

    Frank: respectfully disagree, and here’s why. i don’t imagine that a great many people are going to “switch” wholesale from Linux to OpenSolaris even were you to apply the GPLv2. but what *is* possible, i believe, is that you’d encourage a whole new set of developers to test it out, to deploy it alongside their existing Linux machines. there’s a sizable number of people that i speak with that are not open to OpenSolaris simply b/c of the licensing choice; whether you agree or disagree with their decision is ultimately unimportant – what’s important is that they represent potential adopters of the OpenSolaris technology.

    in other words, the CDDL license – for better or worse – is an inhibitor to adoption within certain communities. removing it would remove that throttle. throw in the possibility of incorporating some interesting tools from GNU userland and the potential value goes up even further.

    Alan: tackled this one above, i think, but just to reiterate, i agree that dual-licensing presents risks. i’m simply of the opinion that the risks are less dire than they might first appear, and are outweighed by the potential upside of the move.

    plenty of room for disagreement, however.

  8. Since it’s GPLv3 (with an exception)
    rather than GPLv2 that’s being
    proposed, I wonder what projects
    will actually be using GPLv3 early on?

    I’d suppose that the GNU tools would,
    but they’re not a problem now; the
    lack of GPL on Solaris doesn’t prevent
    them from being distributed with

    Linux won’t, perhaps can’t without
    getting agreement from its contributors,
    switch quickly to GPLv3. So immediate
    porting of a bunch of x86 drivers
    (the most obvious potential benefit)
    is out, and in many cases wouldn’t
    be immediate anyway due to
    how much of a rewrite they’d need
    to work with different interfaces.

    So unless there’s something else,
    it sure looks like _some_ cost and
    _some_ risk for what, a PR gain?
    If that, with the assembly exception,
    which would hardly please those with a
    strong ideological preference for GPL.

    Of course, it’s certainly worthwhile
    to remain open to the possibility,
    and to be aware of the uptake of
    GPLv3. Should that gain some
    momentum among projects likely
    to offer cross-pollinating of either
    code or community (or better, both),
    there would be much stronger
    arguments to be made in favor of
    dual licensing.

  9. R. Hamilton: the question of which projects will move to GPLv3 is a legitimate one, and the answer is we don’t know yet. certainly some – like Samba – will, even if Linux does not. i’d be very surprised, in addition, if the number of public GPLv3 projects did not outnumber the number of CDDL projects in the near future.

    you’re also correct in asserting that there is both cost and risk in this move, and those – as always – need to be weighed against the potential gains. i’d submit, however, that by referring to the potential boost as a mere “PR” gain, you’re doing a disservice to both the size and passion of the community that is aligned with the GPL. forget the PR goodwill that would accumulate to the project for the move; i’m far more interested in the developer goodwill that would likely result. that’s far more important, and far more relevant. and not to be discounted, IMO.

  10. I believe that the risk of a license-induced fork is actually a serious risk because it’s such a permanent decision: should the economics ever shift — should one company ever cease to dominate OpenSolaris development — a license-based fork may be viewed as a way of incorporating the technology while exerting new-found control over it.

    Or to give a not-completely-impossible scenario: let’s say that several years down the track, a major competitor to Sun in the server space decides that, much to their regret, OpenSolaris is an option that they must not just provide, but also extend and develop. But the competitor doesn’t want to outsource its OS development to Sun — they just want to hijack OpenSolaris. Dual-licensing allows for a devious plan: they could take the source, strip the CDDL, and announce that their “GPLv3-only” OpenSolaris was open to all comers. For good measure, they might find some of the major pain points for non-Sun contributors to OpenSolaris and rectify them — by either hiring those contributors, or establishing great developer resources, or offering services based on their GPLv3-only variant. The optics are good (the competitor positions themselves as “liberating” OpenSolaris, perhaps even joyfully expressing as much in a 101 billboard or two), they get the technology, and they steal the momentum — albeit at a terrible, terrible cost to the OpenSolaris community.

    And before you blow off the above as impossible: both the AT&T/Berkeley wars in the 1980s and the Linux/proprietary wars in the 1990s contain significant elements of the above scenario. It is our responsibility in the OpenSolaris community to not just reflect today’s economics, but understand tomorrow’s possibilities — and to have a license that protects our community from the internecine feuds that have destroyed or hindered so many software efforts.

  11. While the source code could be distributed under the GPL, any serious distribution of OpenSolaris will have to be distributed under the CDDL for exactly the same reason some people are promoting the GPL: drivers. Sun doesn’t own the source to some of the Solaris drivers it distributes, and anyone trying to distribute a GPL OpenSolaris distribution with those binary drivers (which are very likely to be derived works of Solaris) would get an immediate smackdown.

  12. Bryan, with respect, the code that gets built should never really be about whether economics shift, it should be about the technology. It’s a real sad state of affairs if we start to worry too much about the former because that’s something that we can’t possibly predict. OpenSolaris will only ever be as good as the technology (and people) involved.

  13. Permissive exceptions to the GPL go back to more than a decade in libgcc. They are part of the GPL canon, even though they are not particularly well known outside the GPL community.

  14. Economics, commerce and greed will always destroy superior technology and intelligence. To think that an economic shift could not destroy the OpenSolaris community is childlike naivetรฉ. Digital was swallowed whole by Compaq. HP swallowed Compaq. The DEC Alpha was a vastly superior processor at the time and it has been simply “vanished” from commercial existence. SGI barely has a pulse anymore. The OS/2 operating system was superior to Window 3.1 and perhaps even Windows NT. Solaris is superior to Linux in many ways. None of these fine technology examples will save OpenSolaris from an economic shift. Certainly not when an open invitation to destruction is stamped on every file.

  15. Glynn, that’s exactly my point. My assertion is that Stephen’s argument for dual-licensing is substantially weakened by its dependence on today’s economic realities. You’re exactly right in that we can’t possibly predict tomorrow’s economics — which is why we must have a licensing scheme that can deal with an arbitrary future.

    On an unrelated note, I love the AJAX’d spellchecker for comment submission here — even if it doesn’t like words like “AJAX’d” and “spellchecker”… ๐Ÿ˜‰

  16. Bryan: interesting. i take it from your comment that you’re of the opinion that a single company *should* always dominate OpenSolaris development? i’m not sure i’d subscribe to that notion, at least from a long term perspective.

    in the short to medium term, i accept as a given that Sun will dominate development, if only because they employ the overwhelming majority of the people who know the codebase well enough to fork it.

    there’s also, as a couple of folks have brought up, the question of the assembly exception, which may prohibit some of the types of forks you appear to be concerned about. but given that that’s not been finalized as yet, let’s ignore just for the sake of argument, and consider a “worst case” forking scenario.

    on the subject of “stealing” contributors, i’m not convinced. if a competitor can come along, rectify the pain points for contributors, improve developer resources, and make the OpenSolaris experience better, than they may well be deserving of the developers attention. i’m not contending, please note, that Sun doesn’t have good reason to open the project slowly, and gate contributions to ensure quality, but eventually you should be open to the degree that a competitor would be.

    and while we’re on the subject of competitors, let’s consider that possibility, given that we’ve seen almost this precise scenario play out within the Linux world. when Oracle chose to enter the Linux game, they chose to clone – rather than fork – Red Hat. why? ISVs. they were acutely aware of the fact that they would be unlikely to attract significant interest in a forked version of Linux, both because some would doubt Oracle’s long term commitment and because the costs from an ISV perspective of supporting yet another operating system are immense.

    all of the above factors, IMO, would strongly disincent the type of worst case forking scenario you outline. what incentive would a competitor have to create a forked distribution of Solaris that a.) did not employ the vast majority of experienced kernel programmers, and b.) was extremely unlikely to be supported officially by a critical mass of commercial ISVs?

    or maybe the worst, worst case scenario is that Sun either a.) goes out of business or b.) decommits from Solaris, jeopardizing the critical mass component to the above argument. at that point i’d simply say: let the best distribution win, and compete on its merits.

    in short, i’m not blowing the scenario off as impossible, i just think the consequences would be far less dire than many fear.

    Glynn: precisely. that’s exactly the argument that i made when Oracle acquired InnoDB and many folks in the MySQL ecosystem felt completely panicked.

    Dalibor: exactly right. thanks for the reminder.

    Dennis: naive i may very well be, but i don’t think i’ve contended that an economic shift could not destroy OpenSolaris. any of the major operating systems – Linux and Windows included – could be undone by unforeseen changes to the marketplace landscape. Solaris is no exception.

    but to me that’s akin to saying that California could slide into the Pacific if the San Andreas Fault acts up, or that the Western half of the United States could be obliterated by the supervolcano under Yellowstone. these are similarly possible. i just wouldn’t use them as planning assumptions.

    you and i, i suspect, will merely have to disagree that a GPLv3 stamp is an “open invitation to destruction.”

    Bryan: respectfully disagree. it can certainly be argued that dual-licensing poses challenges given an arbitrary, as you so eloquently put it, future. but i’m not sure how it’s not equally true that a single license, CDDL only, could not similarly fall victim to unforeseen future events.

    none of us know, of couse, what the future holds. and i agree with Bryan, that the licensing scheme must be able to deal with an arbitrary future. where we differ, i believe, in what that licensing scheme is. i’m of the opinion that an OpenSolaris that is more open to GPLv3 projects than it is today is – in theory – better equipped to handle what lies ahead simply by virtue of being easier to integrate with. reasonable minds may disagree, of course, but i remain unconvinced of the likelihood of some of the crisis scenarios described both here and on-list.

    the fact is that forking is a risk for both parties, and not terribly common as a result of that.

    ultimately, i think everyone in the OpenSolaris community needs to answer three questions for themselves:

    1. do i think a fork is likely, given both current conditions and hypothetical future scenarios?
    2. should a fork occur, what is the probable impact to OpenSolaris?
    3. considering 1 and 2, how do the potential benefits of a dual license look in comparison?

    it should be obvious where i stand on the above, but again, my voice is not the important one here.

    p.s. we have AJAX spellchecking? cool, didn’t even know. ๐Ÿ™‚

  17. Your inference that I would want one company to dominate OpenSolaris development misses my point: the question is not should one company dominate, but rather what are the risks if one company doesn’t? So when you ask if “a fork is likely”, the question is really: is a fork possible? Or to take your Oracle example: if Oracle could introduce a license-based fork, would they? We cannot know the answer to this question because Linux is not dual-licensed — a license-based fork is impossible. But given Oracle’s long history of, um, pushing the boundaries (TPC-A, anyone?), it would be difficult to argue that the answer is an unequivocal “no.” Finally, note that in your questions to the OpenSolaris community, you are conflating a code-based fork (which is a good and healthy thing, and is always legally resolvable) with a license-based fork (which is antithetical to open source and is always toxic to the underlying code and community). The objection here is not with a code-based fork, and it is not with the GPLv3 — the objection is to the risk of a license-based fork that dual-licensing uniquely allows.

    As for your AJAX spellchecking: it’s very cool, I just wish it knew about OpenSolaris. ๐Ÿ˜‰

  18. Bryan: apologies for the conflation. we’re in full agreement that with most every common open source license, code forking is possible. even the GPL, whose reciprocal provision acts to limit forks, can be forked. it’s merely that any changes to resulted derivative work must be shared back under the same terms and license. we’re on the same page here.

    what i think you’re asking, then, is not “is a fork possible” – the answer is clearly yes. the question instead, i think, is this: is a license-fork possible? and the answer, again, is yes. the logical question from there? does dual licensing, as has been proposed, present new risks? yet again, the answer is yes, of course it does. a downstream GPLv3 only fork would introduce code that – in theory – could not be recombined with the parent distribution, due to the dual license.

    while i think there are a number of mechanisms that act to mitigate the risk, be they economic (cost of acquiring/poaching enough talent to indefinitely sustain the fork), licensing (assembly exception), or pragmatic (ISV division is in no one’s best interests), a fork is – and always will be – a possibility.

    the question is whether or not it’s likely; likely enough to ignore the potential upside to the move. my answer, of course, is no.

    as to your specific example of Oracle, neither i nor anyone this side of Larry Ellison could answer that question. i think the economics, however, are even less compelling for a license fork of OpenSolaris than they are for their fork/not-a-fork clone of RHEL. which is why i would not be substantially concerned, were i a decision maker for the OpenSolaris community.

    but let’s assume for the sake of argument that it did happen; that the much-feared license-fork occurs, and future economics and conditions have changed enough to make it at least potentially sustainable. would this be the end of the world? i don’t think so, but even if that were the case, the option would always be there for opensolaris to relicense (AFAIK this should be possible b/c of the JCA) its code as a single license, under the GPLv3 – dropping the CDDL.

    this is an unattractive option for reasons you’ve already covered in detail. but it does exist, and would – in theory – allow the OpenSolaris project to defuse the potential threat that a theoretical license-fork would pose. in other words, as i see it, we have an unlikely worst-case scenario that could be countered effectively by a painful but possible change.

    i guess it all comes down to your appetite for risk. mine’s usually pretty low, and i’m still comfortable with the possibility of the GPLv3. but again, reasonable minds may disagree.

    p.s. i can’t even figure which plugin is delivering the Ajax spellcheck, so getting OpenSolaris into its dictionary is going to take a little while ๐Ÿ˜‰

  19. Spellchecking – are you sure it’s not Firefox 2’s built-in spellcheck?

  20. Apologies — James is right, it is Firefox 2’s built-in spellchecker. I guess the only blogs I comment on are at RedMonk, so I would have no way of knowing the difference. ๐Ÿ˜‰

    In terms of risk appetite, here’s the problem: when planning in perpetuity, one has to assume that every event with a non-zero probability will ultimately happen, assigning weights to those events, and assess that against the rewards. Over my career, I have seen our industry suffering from multiple, prolonged, disjoint, license-based Unix wars; it would thus be naive of me to assume that they are unlikely, and willfully ignorant to maintain that they are benign.

    Does dual-licensing under GPLv3 have upside? Surely. But the risks of dual-licensing are (in my opinion, and in the opinion of many others that have seen decades of Unix-based license conflict) simply too great without having a more concrete notion of what that upside might be.

  21. I think the interesting question is, assuming it was dual licensed, and assuming there was an unfriendly fork … which license would it pick?

    Assuming the assembly exception is on the table, then we have three licensing options for such a fork: CDDL only, GPLv3+assembly exception only, or GPLv3 only. Of those, the first one is still easy to integrate back into the main tree (or at least no different than the current situation), which would remain dual licensed CDDL/GPLv3+AE, save for the pure CDDL parts. The second one would seem to have the same effect: the code would be available under similarly liberal terms like CDDL (as far as my understanding of the GPLv3+AE combination goes), so it could be treated similarly.

    The last option is the nuclear one, I guess, but it suffers from one major drawback: such a GPLv3-only fork would not be usable with any binary blobs / CDDL only code that exists in OpenSolaris, i.e. would need to be rewritten from scratch.

    For example, a CDDL licensed libc on top of a GPLv3+AE/CDDL licensed kernel could be a sufficient detraction to keep trivial ‘GPL-purity’ forks away, I guess, as anyone wanting to ship a pure GPLv3 OpenSolaris fork would need to invest into rewriting the Sun libc first. Not that I think anyone would seriously want to maintain such a fork, anyway.

  22. Indeed, the risk of a license-based fork once we dual license is not only non-zero, but very large. Any enthusiast with enough time can create a code-based fork, and license-based fork (if we make it possible) costs nothing more. And we’ve seen a number of *BSD forks, and there are enough enthusiasts out there to make this risk pretty darn high, close to one over the next few years.

    Once a GPLv3-only license-based fork of OpenSolaris exists Sun’s competitors can gang up on it and either force Sun to abandon the CDDL or force Sun out of the OpenSolaris support market. You might find such an eventuality palatable, but I don’t (and not merely because Sun pays my salary).

  23. Hi Stephen —

    Having been on vacation and away from the internet last week, I desperately needed a hyper-distilled way to grok the pros/cons of the dual-licensing debate. I found exactly that by reading this entry — and especially the comments section.

    Which means I now think the debate boils down to just this:

    a. How big would the community gain be…


    b. How likely and damaging would a license-based fork be…

    Regarding b, I think it is very likely and extremely severe.

    Regarding a, I think the potential for community gain is a big fat red herring. Why? Despite widespread noise to the contrary, the vast majority (i.e. >95%) of Linux and *BSD professionals and other users are simply too practical to be license zealots. (The problem is their numbers are hard to measure because they don’t blog, slashdot, etc. about their non-zealotry. Why should they?)

    In other words, almost all computer professionals and students, except a tiny loud minority, are _not_ anti-CDDL. So I think community gain would be much smaller than you think it will be.

  24. Thanks Steve for your well-thought-out essay and responses.

    It was interesting to me to read your comments the same evening as http://eskar.dk/andreas/blog/?p=183 “Debian as the research library of Free Software.” I ran Debian for a long time but now it’s Ubuntu for many of the reasons Andreas referred to. I agree that a Debian base makes a good foundation for many integration projects.

    If OpenSolaris could “get past” the stigma it has from the CDDL it could well fit into my future plans. Yes, I’m one individual who is currently inhibited from OpenSolaris but can envision that status changing. If the project added GPL or similarly suitable license then I would certainly take another look and encourage others to do so as well.


  25. >GPL is not incompatible with BSD style licenses

    Surely it IS incompatible. The work incorporating the BSD code essentially relicenses them under the GPL. The result is no longer BSD licensed – its had its license changed (perhaps additively, but the result is code that has different licensing provisions and can’t be combined with other works in the same way as the original – and nor can bug fixes and enhancements be available to users of the original: its a fork).

    I don’t understand that way that the examples for GPLd code that we want to work with are primarily user-space – even the Samba daemon. While there may be a good case for making the libc and other fundamental user-space libraries dual-licensed, I can’t see how any argument for this translates to the core kernel.

    I also don’t see why we care what licence developers choose for their own projects. Surely what matters is how the license affects what can be delivered to *users* both by the community and by ISVs that enrich the choice for users.

    One of the curses of the Linux licencing model has long been the ‘discussion’ over the legality of binary modules and the (childish and selfish, IMO) way that the kernel devs act in relation to them – do you want to go there with Solaris? Or do you want Solaris to be the system that sweeps this pro-dev and anti-user approach aside and puts a big flag in the ground to champion the end user – and provides a solid base on which ISVs can service those users?

    The relationship between the Linux dev community and ISVs has always been somewhat unclear and ambivalent. As Linux has matured even some of the pro-open leaders have started to recognise that a more mature basis for this is necessary. Solaris starts from a good base here, so lets not allow anything that will mess it up. Its very hard to make business cases for R&D that is then opened with the only income being support based – Sun has a hardware and service business it can leverage here but small ISVs can’t and we need to at least consider the affects of licencing on business models that could bring innovation to the platform as a whole even if it is not freely licenced – because users will often care about expensive vs affordable, and not care too much about affordable vs free. I know I don’t. Please, let’s make OpenSolaris the best platform for ISVs of all types, and make sure that the license reflects that.

  26. […] It would appear that the debate, begun a little more than a week ago, is now effectively ended – at least for the better part of a year. For those of you who aren’t inclined to follow the links, the short version is that the OpenSolaris CAB/OGB has decided that “there is little, if any, benefit to dual-licensing OpenSolaris” and directs that “any option related to GPLv3 dual licensing be re-assessed no sooner than 6 months after the GPLv3 has been published and approved.” What’s more, “discussion on GPL* is merely a diversion and distraction that should be discouraged.” […]

  27. Bryan/Nico/Eric: thanks much for the input. as is probably well known by now, the OGB has issued a position paper that mirrors your stated opinions, and closed the issue for further debate. whether or not that pertains to me remains to be seen ;), but i did want to acknowledge your concerns despite the fact that i don’t share them – at least to the degree that you do.

    Dalibor: agreed, and thanks for laying it out so clearly.

    James S: appreciate the input, as i suspect there’s a substantial population of individuals that are in similar positions. i hope that eventually the OpenSolaris community recognizes the needs of folks such as yourself and caters to them as best it can.

    James M: everyone i’ve spoken with has maintained that permissive, BSD style licenses can in fact be integrated into the GPL. here’s what Wikipedia says on the subject: “Code licensed under the BSD license can be relicensed under the GPL (is “GPL-compatible”) without securing the consent of all original authors.

    i’m also having a tough time buying the argument that the CDDL is somehow championing users, while the GPL is pro-dev / anti-user. the very popularity of Linux and MySQL would seem to undermine that claim significantly.

  28. […] [For other discussion see Stephen Oโ€™Grady here and here.] […]

  29. […] this (as well as being the guy in charge of keeping it up to date), write this, am working to make this happen, talk about this and this and am working to become one of these. Oh, and I totally get […]

  30. […] Should OpenSolaris Use the GPLv3 License? The Q&A, tecosystems, Stephen O’Grady (Blog) […]

  31. […] is licensed under the CDDL, which is incompatible with the GPL and thus with Linux. As I’ve said before, I believe the choice made sense at the time: Suffice it to say that on the one side we have the […]

Leave a Reply

Your email address will not be published. Required fields are marked *