« Building a Blog in 60 days | Main | Dual-licensing: revoking the GPL »

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Wes Felter

I disagree that dual-licensing is somehow unfair. Peer production and open source are orthogonal issues, and a company should be allowed to combine firm-based production (i.e. minimal or no community control) with open source licensing if they want. If a company bears most of the development cost of a project, it seems quite fair to me that they should be allowed to reap benefits through dual licensing. Of course, it is important for potential contributors to understand the implications of this model - they may choose not to contribute since it is so one-sided.

Also, I think "Dual-Licensing companies are controlling your contribution to other open source projects" is a strawman. The ASF CLA is a non-exclusive license, not a copyright assignment, so the author could license code to the ASF under the CLA and to another commmunity under a different license. AFAIK the FSF's copyright assignment grants back to the author the right to license under other terms (even proprietary). So if a company is using an evil copyright assignment contract that prevents code reuse, that company is being evil, but copyright assignments are not intrinsically problematic.

mtg

Wes, thanks for your post.

I agree that Apache and the FSF don't have evil copyright assignments but that's not the point: the post is about proprietary dual-licensing and as such about CLA FROM DL companies not from open source organizations.


Chris Lamb

Seriously, quit using the ancronym "IP". It makes me twitch.

mtg

Nowadays everything running on the IP layer has been approved by the IP lawyer :)

Chris Lamb

Oh, har har. I was not referring to the hash collision between Internet Protocol and "Interlectual Property", I was referring to your usage of the latter term.

Caleb Cushing

your entire argument is around IP, however IP is a false and bad term see url below.


http://www.dklevine.com/general/intellectual/against.htm

Once you submit your code to just about any project your code must then follow the licensing of that project, therefore your GPL-ed code can't be inserted into a BSD project. It doesn't matter whether it's a dual licenced project or not.

Also OpenOffice (SUN) has been known to not allow contributions due to people not wanting to give up their IP.

You have focused your perceived problem on the wrong thing. It is not Dual Licensing but Intellectual Monopoly that is your problem from the Sounds of it.

Guess what if you use BSD licensing corporations can use the source without contributing back or any such things. But, you know this already.

as far as dual licensing goes I think it is one of the few viable revenue options (besides support) for an open source company.

Mark Murphy

"In a dual model, all external contributors are required to re-assign all of their copyrights (and sometimes all of their IP rights) to the open source company."

False. See OpenOffice.org and NetBeans for projects that use multiple licenses and use a joint copyright assignment. And, you've neglected to provide a single example of a firm that runs an open source project and requires all contributions be wholly signed over as you set up with your straw man. The only organization I can think of off the top of my head that requires full copyright assignment, ironically, is the FSF, and that's more for GPL defense than for dual licensing.

"And it works because no developer is going to fork a new project just to incorporate his/her patch."

But you just said earlier that dual-licensed projects are supposedly immune to forking. Which is it? Of course, the answer is that forking is eminently possible, though that weakens your straw man case that much more.

"Good for business (see we are the only professional version) bad for the community."

If the community doesn't like it, the community forks it. Witness Ext JS, Joomla, and others.

"That’s why in this model, most key and/or respected developers are usually paid or employed by the company: a very strong disincentive to fork."

You gotta be kidding me. Forks happen despite the "key and/or respected developers" all the time. It usually happens when the key developers are no longer respected, or at least the firm they work for is no longer respected. See Ext JS and Joomla for recent examples.

"Any addition of proprietary code to the dual licensed code (and distributed through the proprietary license) is a de facto fork."

So is the addition of proprietary code to permissive-licensed code. In fact, the addition of proprietary code to *anything* creates a de facto fork that is unusable by the proponents of the base. This isn't a problem of dual licensing -- it's a side-effect of proprietary code.

"By controlling the key developers DL companies are diverting key resources from the open source community..."

In most nations of the world, slavery and servitude are no longer the norm. Furthermore, I rather doubt that the "key developers" are drugged, hypnotized, brainwashed, or blackmailed into continuing to work for the firm in question. Referring to this as "controlling the key developers" basically says those key developers have no free will, in which case they should not be considered very key.

"When distributing the code under the proprietary license MyCompany is never forced to contribute to the community while the open source community is always forced to contribute to both licenses"

False. You seem to feel that the only open source community contributions that are of merit are to the main source code of the project. The tens of thousands of Linux userland developers, thousands of Mozilla plug-in authors, hundreds of Rails plug-in creators, and the like might disagree with this assessment.

"Well, the key developers who have been so wisely hijacked by the company and who are now prevented to really contribute to the community."

Yes, I'm sure their families are held at gunpoint.

"MySQL for instance has a much less thriving community than that of PostgeSQL."

The relative traffic volumes on certain mailing lists is one metric of how thriving a community is. It is not the only one. It might not even be the best one.

Let's try Google hits: MySQL=236,000,000, Postgresql=25,300,000. Advantage MySQL by 10x.

Let's try books on Amazon (search hits in Computers and Internet book category): MySQL=2,903, Postgresql=968. Advantage MySQL by close to 3x.

I actually agree with bits of your premise: it is possible for firms with open source projects to mismanage them to the detriment to the community, and dual-licensing is one avenue for mismanagement. However, your post implies that all dual-licensing is subject to mismanagement, and you haven't even come remotely close to proving your case.

Thomas Hansen

So what do you feel are the alternatives...?
Should we all build BSD licensed software in the weekends while getting payed for doing "other stuff" at daytime and then after 25 years of contribution some big corporation (Apple and MSFT comes to mind) and steal the entire intellectual property and closes all source code down...?
You are free to not liking Dual Licensing companies, you are also free not to use their SW. However IF you like their SW and you want to use it then we're only asking you to do Quid Pro Quo meaning either you pay for a commercial license in which you can build closed source yourself or you obey by the GPL rules which have nothing to do with "patching" and "submissions"...
In fact Trolltech which probably is the worlds largest and most successful Dual License company have (virtually) not ONE line of code in Qt which is "submitted from the community". They simply cannot tolerate it from a legal perspective since it is too dangerous in cases of lawsuits for IP and such...
To say Dual License is "unfair" sounds like Stalin and Lenin to me. And before you try to make your living on "free beer" projects you have no right to use the word "unfair" and Dual Licensing in the same sentence.
PS!
I have (tried to make a living on BSD projects and "donations")
PS2!
Your logic about forking is NOT correct...!
Anyone can fork ANYTHING which is Open Source and if they cannot then it is not an OSI approved OSS license...
In fact Qt was forked. Their GPL version was forked and ported to Windows since they didn't have a GPL version for Windows. This again forced Trolltech to release also their Windows version as GPL which I think is a pretty strong statement in regards to "who's got the power" in Dual License companies...
But maybe you want to go back to EULA and MSFT...?
Quid Pro Quo dude, either contribute through license fees, obey by GPL or get out of our way...!
The "money is dirty" argument simply doesn't work today, South Korea is THAT way...!

Marck

The author is way off base here in my opinion. As a developer I can decide which projects to work on and if the trade-offs (including licensing) are worth it.

I may pass on a completely open source project in favor of a DL project simply because I like what the DL project is doing or how they are doing it.

The only way it would be unfair is to gain my contribution under one license and then try to switch it around later. As long as they are up front with their motives and rules then I can make my own choices.

Don't assume developers are somehow tricked into these projects. It isn't true, people know what they are getting into.

dv

I wonder if there is anything about economics people understand these days. We are removing the marketability of software. And, if the software market is removed what's next? Software developers!

bm

I think one place where dual license can potentially be a problem is reflected in Yahoo's purchase of Zimbra.

Do you realize that if Microsoft had purchased yahoo that they could have sinked Zimbra just like they did other opensource projects.

They major problems I find with them (DL's) is that it relies on the opensource friendliness of the developers. At some point most(or some) of these projects sells out to another company which may not feel the same and all your investment and time will be lost if they decide to kill the project or no longer DL new codes.

Even the person who deploys the software can have problems, again the hypothetical situation with MS/Yahoo/Zimbra.

Personally I think most companies DL not just for current revenues, but also because it gives them a bigger list of buyers to sell to in the future.

I do however understand when a company which originally had a proprietory project, when they opensource they use DL. I also understand when a company hire most of the people and pay most of the development cost. It is a middle ground for some developers who has not totally grasp the whole "opensource thing". Some times some of these developers actually becomes more comfortable in the future and GPL these projects.

The end user and project contributor, investing in the development just needs to remember the risk.

Personally I look for GPL solutions to my software needs first, then I look for other opensource license then I look at DL's then proprietory if they support linux.

Troy Hepfner

I'm not an open source developer, but I'd like to respond from the standpoint of a company. I'm small independent game developer, and I've looked into the possibility of open sourcing my code under a dual license scheme. Here's why I would use dual licensing if I did open my source:

First, it's my source code, and I can do what I want with it. I don't even have to open it if I don't want to. If I do choose to open it, I can choose any licensing scheme I want. I would certainly be up front about the licensing and the fact that contributors need to either assign me the copyright or otherwise give me permission to include their code contribution in the proprietary version of the game that I sell. Community members are free to choose whether or not they want to contribute under those terms - I'm not holding a gun to their head. But I must have control over the copyrights in order to be able to publish my game commercially. Publishers are funny that way.

Second, if I do choose to open it, I must do so in a way that protects my interests. I won't allow someone to take my hard work and produce a competing game, which they turn around and sell without giving me a dime. A dual licensing model protects my hard work and helps ensure that I will be compensated for it (assuming I decide to actually sell a commercial license to my source code).

Third, a dual licensing model is necessary because there are times that I have to integrate third-party libraries that are incompatible with GPL. For example, most online game portals (Real Arcade, Oberon, Shockwave, etc) will not distribute a game unless it is protected by a DRM wrapper, and sometimes the wrappers require integration at the source code level. I am contractually prevented from open sourcing that small part of my source code that integrates with DRM. A dual licensing model would allow me to release the bulk of my game code, but still protect the small proprietary piece that is necessary for me to publish my games.

Fourth, a computer game is not quite the same as a word processor or other application. It requires creative vision and direction. A dual licensing model helps ensure that I maintain control over the main code base, and thus my vision for my games. While I would welcome developer contributions for bug fixes or new features, I have to be careful about allowing design changes and modifications that would compromise the overall game design. For example, if I am designing a simple crossword game for kids, I'm not going to accept a code contribution that causes the letters to explode and drip blood. If someone wants to fork the code base and do that, they can go ahead and do so - but not in my games (for which I am liable, not the community).


I think the flaw in your premise is that a dual-licensed open source project is fundamentally different from other projects, for some of the reasons I've given above. Therefore, the community that builds around such a project is going to be different from other open source communities, and thus it will be managed differently. There just isn't any getting around it, which is what I think the goal of your article is. The business need that drives these conditions in a dual licensing model isn't likely to change. Certainly, the community can take any issues to the company and address them directly with the company. I think a lot of times, the two can work together to overcome any potential or perceived problems. Of course, your article seems to be based on an inherent distrust of the company and its intentions, and I guess it doesn't hurt to be cautious.

Personally, I think it's great when companies do open their source code for the benefit of the community, but the community developers have to understand what drives the company, why the company chose a dual licensing model, and what the side effects of the dual licensing model are. Based on the comments above, I think a lot of developers already understand that. If they are comfortable with that and they trust the company that manages the project, they'll contribute if they want to. If they don't, they won't. It's as simple as that. If the company betrays that trust, or they sell out to another company that doesn't share the same spirit of cooperation with FOSS, the community can take the GPL'd code (which will always stay GPL'd, by the way), fork it off, and setup a new project around it that is truly open by its own definition. Developers are always free to produce work in the best interest of the community. They can work with the company for as long as they feel it is in their best interest to do so, and they can fork off their own project at any time if they feel it is in their best interest to do that. So from my standpoint, I think you're addressing a non-issue. But as I said, I am not an open source developer, so maybe there is something else I'm missing in this picture...

Toby

"I wonder if there is anything about economics people understand these days. We are removing the marketability of software. And, if the software market is removed what's next? Software developers!"

Assuming dv is serious: That's the most boneheaded thing I've read all day :)

Ted Haeger

Pierre:
Apologies for arriving to the party late. I read through your article, and all of the follow-up comments, with keen interest. My take-away is that the points you make are not examined in enough depth to support you assertion that, "Dual-licensing is unfair and community debilitating."

"By controlling IP rights Dual-Licensing (DL) companies are controlling your contribution to other open source projects"
DL company cannot accept contributions unless they can maintain their copyright, and yes, that does require a contributor to forfeit his or her rights to the code he or she contributes. However, the phrasing you use sounds broader-reaching than it actually is. A developer only surrenders rights to the code that she contributes to the project. They can still participate as they wish in any other project. Your example under this headline makes sense, but it assumes a sizable contribution...which later you make clear is not likely to happen because the most significant developers are captured in the DL company anyway.

"By controlling the source tree DL companies are controlling the directions, the maturity and the crippleware-level of the code"
Is that really a DL issue? By design, maintainers exits to exert control and discretion over which fixes get accepted or rejected into a project, and more generally, in which direction a project goes. Don't Linus Torvalds and the kernel team reject many, many submissions? And hasn't Linus closely controlled which general direction the kernel will go? Whether or not a company uses dual licensing or not, if a OSS project is founded by and driven by a company (often that company being founded by the project's founder), why shouldn't the company be allowed to exercise the same type of control?

On your second point about the proprietary version getting fixes sooner than the OSS version, I agree that it's just bad form. The one exception may be a short-term security patch, which may need to get to paying customers quickly, before a more comprehensive patch is vetted by the community.

"By controlling the right to fork, DL companies are also depriving developers of their right to choose"
You *can* fork. There is nothing legal that prevents the community from forking a DL project. The GPL is the GPL. Forking a GPL-licensed project only binds the parties who make the fork to the same GPL terms as those under which they took the code in the first place.

"By controlling the key developers DL companies are diverting key resources from the open source community"
This assumes that those developers would be working on open source if they were not at the DL company. I don't think you can safely make that assumption. Overall, having developers make a living by contributing to open source diverts resource *to* open source.

However, the concern you cite is is that a DL company may only dual-license *a portion* of a project, leaving the Free version a type of crippleware. While it's possible, the record shows that this route really doesn't work out very well for the company. Is there a such a DL company that manages to attract much of a Free user base?


Overall, I guess I don't see much that is unfair or community debilitating in using a dual licensing model for offering software. Of course there are ways that companies can be bastards about the implementation (such as crippleware). But in general, most of the issues you cite are mistaken (such as the claim that you cannot fork) or overwrought (such as the claim about controlling the source tree).

What I think remains valid is that there is an imbalance in ownership:

"When distributing the code under the proprietary license MyCompany is never forced to contribute to the community while the open source community is always forced to contribute to both licenses (remember the IP assignment)."

To that I agree, but question whether it's really all that unfair. Having a company backing a project generally sustains the project for longer than unpaid volunteers can. (To be sure, SourceForge is a veritable graveyard of unfinished projects.) That seems like an overall gain for all members of the community. Perhaps the dual license model is how companies can sustain projects over the long term project, allowing the code to reach professional grade maturity. If so, then maybe what's really needed is a "Best Practices for Dual Licensing" guide. Discouraging practices like crippleware, delayed delivery to OSS, and maintaining internal forks could go right on the list.

Thanks,

--Ted

Ted Haeger

Pierre:
On further research, I have discovered that your assertion that "By controlling IP rights Dual-Licensing (DL) companies are controlling your contribution to other open source projects" is not correct.

The Sun Contributor License Agreement (http://forge.mysql.com/contribute/cla.php) now used by MySQL does not require a complete forfeiture of copyright. It requires that you allow Sun co-ownership of the copyright, and allowance for independent use.

This is far less draconian than forcing a contributor to "release his/her rights" altogether.

--Ted

The comments to this entry are closed.