Creating software derivative works from open source

Question

This question has always been around my head.

Can someone create a new product based on an existing open source project?

Say you want to create an "Apaxe webserver" that is basically Apache with your some extra plugins ( say support for ASP or something similar )

Is this possible?

Would you be able to create a closed source product ( either free or licensed )

As for GPL seems clear it is not possible because the source should be open. But what about Apache license, BSD and others "corporate friendly"

Are the price ( free for most of the project ) , bug fixes and counting with the core development team the only thing that prevent from others to commercialize those OS products?

What about: Khrome a commercial product based on Chrome with ActiveX support ( who would dare to do such a thing :P )

EDIT

Thank you all you all for your answers.

So, again

What prevents from similar ( clone ) products from appearing in the market?

:)

NOTE: I know we are not lawyers, and we could read every OSS license here http://www.opensource.org/licenses.

Answer 1

Isn't that essentially what red hat does? Even though they have fedora, they are charging money for their linux distribution. Granted, they've written a lot of code for it, it's still based on open source-stuff.

Answer 2

Here's my 10,000 foot view of open source licenses:

"Real" open source licenses (eg: MIT, BSD, Apache I think, etc.): You can do whatever you want with licensing derived works. It can be closed, open, etc. The license places no restrictions on your licensing of derived works.

"Restricted" open source licenses (eg: GPL, LGPL): Derived works must include specific license restrictions; for example, the GPL requires derived works to be GPL-ed. Essentially your rights are restricted for derived works.

Charging for products is separate from either of these; neither type restricts charging for products, although some licenses place restrictions on the rights you can retain and/or must convey to receivers of your software (ie: the "Restricted" licenses).

Hope this helps.

Edit: Changed by original "DRM" term for GPL type licenses to "Restricted", cause some people attach negative connotations to DRM, and/or cannot grasp how the GPL restricts your rights for derived works in an almost identical way to any other type of DRM (ie: controlling what you can do with it). Seriously, you can be a FSF supporter and still grok the concept that the GPL is more restrictive than "real" open source licenses. The question is not about which type is right or wrong, it's about what the difference is.

Answer 3

Red Hat (and most of the other Linux vendors) charge for support, not for their software - which is primarily how companies can make money off of code that is GPL licensed.

Answer 4

It really depends on the license the open source project uses.

Disclaimer: I am not a lawyer; you should always read the license for full details.

If a project is under the GPL, then anything you derive from it must also be released under the GPL (or a compatible license, and if it is released at all). You're still allowed to charge money for it, but anyone who buys it has to be provided with the full source, and you can't prevent them also selling it, or giving it away for free.

If a project is under the BSD license, you can do pretty much anything with it including incorporate it into a proprietary closed source product. There is BSD code inside Windows!

Other licenses fall somewhere in between.

Answer 5

Generally, my read of the licenses is:

1. You can make a derivative work of any project based on one of the popular licenses (i.e. GPL, LGPL, Apache, MIT, BSD).
2. You may charge money for at least the distribution & packaging of your derivative work.
3. Depending on the license, you may also have to distribute your modifications in source form and/or include notices in your distribution.

So to your question about Apaxe: yes, you can do this as far as I know. I believe that the Oracle HTTPD server is actually derived from Apache, and it's definitely not free!

Answer 6

Nothing prevents clone products appearing on the market. Look at all the various linux distributions, for example. The X.org project was forked from XFree86. And so on.

It happens relatively infrequently, though, for a couple of reasons:

• The original project has the first-to-market advantage
• The original is usually being given away free

So unless your version is significantly better than the original, you're not going to get much uptake or make much money out of it. If your version is significantly better, then go ahead!

From the original developer's point of view, the power of the GPL is that it forces such clones to share any improvements with the rest of the world, so they can be incorporated back into the original.

Answer 7

look at MyEclipse, its really just eclipse+free plugins+myeclipse's plugins and it cost some money.

Answer 8

What prevents from similar ( clone ) products from appearing in the market?

Nothing. The real question is: How can a similar cloned product get more popular than the original product?

Some cases where somebody might clone/fork a project:

• Picking up a dead open source project and continuing its development. If the new derived product is maintained regularly and it gets more updates than the original version, then people will start using the new version. This is one of the big benefits of open source - good software does not need to die, just because the original developers stop developing it, but someone else can continue from where they were left. One example of such a project (which I've used) is that the development of Turck MMCache had died out in 2003, so eAccelerator forked it and continued its development in 2004. I'm sure there are lots of other examples.

• There is a disagreement in the developer community of an open source project, and the project splits into two. That's why it's best to strive for a common understanding in open source projects, so that the community would not be split needlessly. If a project is split, the projects may continue living if they managed to attract enough developers and users, but otherwise they may slowly die. In general, splitting should be avoided, because it makes the community more fragmented and weaker. IIRC, in the video presentations of Producing Open Source Software (good stuff!) they mentioned a case where the original developer of some project wanted to take a completely new direction in the development, but the community of other developers wanted to keep the old direction. The result was that the original developer was kicked out of the project, so he created a fork of the project, while the rest of the community continued the development of the original project.

• A commercial closed source derivative of an open source project which was released under a permissive license (for example BSD). The derived product would need to be considerably better in features or in support than the original product. Otherwise people will prefer using the original open and free product.