Ok, or they could keep them employed, and instruct them to develop the software in a way that slowly kills the product.
Your plan works in theory, but in reality they lose all the marketing steam they had before. Oracle would be able to string the commercial companies along for a while with MySQL or some Oracle offering, leading to slow adoption from the new company. The userbase would be fractured, disorganized, and incompatible for years.
The engines are both available under GPL or a commercial license.
However, as I pointed out, that still causes problems. In particular, the commercial MySQL licenses are required by anyone who adds MySQL support to their non-GPL application because the client libraries are GPL. And, since development of all of MySQL, BDB, and InnoDB are all centralized, it's easier for the development to be disrupted, and harder to restablish a development team for the forked version.
It could be done as a proof of concept at least. My point was that the tools are out there, and that building a transactional system is reinventing the wheel. How much of the wheel you want to reinvent is up to you.
You can't copy windows 100 times because copyright law prevents you, and the license doesn't specifically allow you to. Copyright law means the default is no copying or distribution or whatever you want to call it.
The GPL only permits copying if you follow a bunch of rules, some of which are in section 2b (which you left out), which requires that, for any whole or derived work, you must make it available under the terms of the GPL.
So, you can only give it to people on a "need to have" basis and hope it doesn't get out as GPL software. But any employee can legally then take it and redistribute it under the GPL license, whether you like it or not. You can't use an NDA to prevent the GPLed code from being released (otherwise you could do that with anyone's GPL code, just offer it for sale with an NDA so they can't distribute). So, it's only safe if you are the entire organization, or if you have very loyal employees.
Again, not exactly "free". More like "free but living in fear".
That was my point, is that none of those things will actually happen. That's why I said "By that time, it will all be irrelevant."
By that I meant, when hell freezes over, and all those things are rewritten or forked, Oracle will have already accomplished its goal of delaying MySQL's development and adoption, which will effectively kill it.
Although that still doesn't really explain your post. Nobody would need to rewrite BDB or InnoDB, they would just need to fork it. You still need someone who knows what they're doing, but it's not like the storage engine has to be written from scratch in a week.
And a transactional system isn't necessarily that complicated. Heck, build it on top of a transactional file system and a lot of the work is done (I know most transactional filesystems provide no isolation guarantee, but you at least have atomicity and durability).
because everything that makes it go is BSD licensed
And because the developers are physically spread around the globe, and spread among many companies. And the development model is already built in a distributed way.
That was brought to you by PostgreSQL, as with all other.org or.info lookups.
The fact is, there is a lot of heavy commercial use of both databases. With public involvement/use from companies like Fujitsu, Sun, the American Chemical Society, BASF, the National Weather Service, U.S. Dept. of State, and many more, PostgreSQL does not have anything to prove over MySQL any more.
By the time any of that happens, it will most likely be too late. Oracle is just buying time, but that's all they need right now while they're collecting huge license fees.
I'm sure some people really like MySQL and might want to take up development, but not me. I am a PostgreSQL user. There are no such restrictions on PostgreSQL, and it works better for everything that I need it to do. Why take MySQL's almost-free database when there are great -- and truly free -- database alternatives like PostgreSQL, FirebirdSQL, Ingres, &c. available?
I am mostly interested in this discussion because of the business aspects of it, and how that relates to F/OSS. We might be seeing an example of a business model that doesn't work (dual license + depend on other companies), and that's important to the whole F/OSS community.
Ok, fair complaint. The companies are gone now, a part of Oracle. So there's not much left to be mad at, except Oracle.
We could get really mad at the former owners, but it's not easy when most of the people here have their price as well. If you own a small, modestly successful enterprise and Oracle lays down some cash, most people would take it, and not ask questions.
Maybe get mad at the vendors who left themselves -- and therefore their customers -- so vulnerable? MySQL, in particular, who had the rug pulled out from under them.
That's a mighty fine line you're trying to draw. The way I understand it, the GPL kicks in anytime copyright law would, i.e., when you copy it and it's not covered by fair use. And copying windows 100 times in an office certainly isn't legally fair use.
The GPL can have 10 paragraphs on it, but the real question is what a judge will determine to be a derivative work in the court of law. Derivative works are determined by copyright law, not a license. If something is determined by copyright law (and a judge) not to be a derivative work of product X, you are 100% free from the requirement to license at all from the copyright holder(s) of product X. However, if it is determined to be a derivative work of product X, you are 100% bound by the terms of product X.
By your reasoning, any derivative code could be magically turned into non-derivative code by writing a wrapper in 5 lines of code. I think you can get away with that if your wrapper implements a real standard, because then you can distribute your product (which makes use of standard A), and the wrapper for use by any of N existing products (N > 1), then just distribute one of those existing products seperately. However, if your product makes use of something that isn't really a standard, and it entirely depends on some specific product, it's obvious that you're trying magically make your derivitive work into an independent work without actually doing the work yourself.
Truly free software doesn't require you to hide in a legal grey area, constantly in fear of being sued. And if someone did sue, it would have some merit at least, so it would cost you a bundle to defend yourself.
How many of those engines are distributed under a free license and have transactional support? Looks like both are owned by Oracle now. Oracle did that for a reason, and it's not because they like to collect database companies.
Many users of MySQL depend on one or more of: (1) the ability to license MySQL commercially with one of those engines cheaply (2) the continued development of those storage engines (3) the continued development of MySQL
Oracle can now stronly influence all of those things. #1 they can just raise the price or not license. #2 they can just lay off all the developers. Good luck getting an open sources devel team together before it's too late. #3, they can just refuse to license those backends, thereby preventing #1, which is also MySQL's source of revenue, leading indirectly to exactly the same case as #2.
I really think that using a more generic interface, such as JDBC/ODBC would effectively act as a GPL barrier
True. The difficulty there is that MySQL's version of SQL is substantially different from other dialects. Granted, the standard is not adhered to all that well by anyone. But there are definately a few MySQLisms that would stand out, and limit that argument. I don't know whether it would stand up or not, but it seems like a lawyer could make a reasonable argument that "hey, they're just using this as a workaround layer" if you're still using highly MySQL-specific SQL.
Furthermore, if you built from scratch a library that talked with the mysql server, you could give it a generic license.
Yes. I highly recommend that people interested in MySQL as an open source database do indeed implement a from-scratch LGPL version of the library. It may be necessary in the future, in a sudden way. Then, if the worst happened (development from MySQL AB, Innobase, and Sleepycat just stopped), you would at least have the commercial users still on board when you needed to organize some developers to fork the code. If you didn't have the LGPL library, the commercial MySQL licensees would just have to jump ship when that happened.
That's a pretty strong restriction, considering that organizations usually want to deploy many copies of an application, even if they are only using it internally. Particularly a database driven application.
You can also split hairs over whether you can use an interpreted language that has the library built-in or something. I think the standard is that if you depend on that specific code being there (i.e. the MySQL library), then it counts as distribution. The point is, you are deep in lawyer-ville. Maybe you can sort these things out and stay on the right side of the letter of the law. But to me, having to be so careful doesn't sound like the spirit "free software".
Let's imagine a hypothetical alternative: A GPL database and LGPL client libraries. You put as many of the databases anywhere you want, and you link up the client library to whatever you want and put the resulting programs wherever you want, or sell them if you want. To me, that's easy and feels a lot more free. Or, take the GNU example: GNU gzip will happily provide it's output to either GNU tar or BSD tar. Again, feels like the spirit of free software.
Limiting the linking of a library to GPL applications may promote more GPL applications. But limiting the distribution of a client library limits interoperability. A client library is sort of like a standard more than like code, and GPLing it means only GPL applications get to see the standard.
There are two important decisions that I think are relevent:
(1) Oracle bought not one, but TWO mysql backends, which happened to be both of their transactional backends. (2) MySQL AB licenses the client libraries under the GPL.
The only conclusion that I can come to from either of those is control.
MySQL AB needed control over their MySQL database, and so they restricted the distribution of the client libraries. You can argue about what licenses are acceptable for libraries in general, but for a client-server program, it is very strange to restrict the distribution of the client libraries. The decision therefore must have been deliberate, and made for a business reason. That reason is control.
And Oracle obviously made a business decision. There was question about the motives after buying Innobase, but those questions are now answered when they purchased the only remaining candidate for a transactional storage engine for the MySQL commercial product.
So here we have Oracle which clearly thinks they have control over MySQL AB, and MySQL AB which clearly thinks they have control over the MySQL database. For that to be false you would have to assume that one of those companies made a serious error in their business decision. So, Oracle now has some substantial degree of control over MySQL database.
To prevent Oracle from exercising this control, we need to (1) fork the MySQL database (2) do a cleanroom reverse engineering of the client libraries and make them LGPL/whatever (in order to keep current commercial MySQL users in business) (3) fork InnoDB and/or BDB to make sure we have an open source backend that is actively developed.
By that time, it will all be irrelevant.
Fortunately, PostgreSQL is immune from these types of licensing problems. The client libraries and the database itself are freely destributable. And the developers work for a wide variety of companies. As far as I know, FirebirdSQL, Inges, and SAP DB are also free of licensing problems. That's 4 good alternatives if Oracle really tries to set MySQL back.
Because, many people depend on commercially-licensed MySQL because they have a non-GPL product that they want to include MySQL support for.
Now, the commercial distribution of MySQL may be weaker than the GPL version, because Oracle can stop licensing the "good" backends to MySQL AB for them to license to you. And the GPL version is highly restrictive because you can't link the client libraries to non-GPL clients.
And if MySQL AB stops developing MySQL because they can't sell people a database without transactions, the development organization of MySQL database is gone. It takes a long time and/or a lot of help to get that organization back, and by that time it may be irrelevent.
Don't blame Oracle (since it's their right to buy software); blame the people selling to Oracle.
Huh? That doesn't make any sense. It their right to sell to Oracle also.
Why not blame open source software developers who depend heavily on products that they can't control. I'm not saying it's always a bad idea to link to BDB, I'm just saying that if your project can be seriously hurt by the actions of another project, you need to have a plan B.
The terms of the deal were not disclosed. Perhaps it was a stock deal?
And even if not, it's not like the money was spent on some party. That money goes to another company, who will use that money to buy labor and/or capital. If an Oracle employee is being a net negative, it's economically more efficient to reallocate those human resources elsewhere. If they are highly qualified, maybe they could go work for google, or someone who could use them more effectively.
But at least now developers can fork the open source code
True. However, any successful move of development from one organization to open source coders is usually heavily backed by the organization, at least to get it started. Oracle knows that the organization of the project itself takes a lot of work to nurture, and that anyone who forked development wouldn't really get off the ground for a while, if ever. And time is valuable to Oracle now.
Yes it does, as a potential replacement for InnoDB as a backend for MySQL. When Oracle bought Innobase (makers of InnoDB), all the MySQL people suggested improving the BerkeleyDB backend to make it their primary transaction-supporting backend. Now, looks like that's owned by Oracle to. Maybe it's a coincidence? Or maybe the licensing of MySQL really is a weakness*, and Oracle saw a cheap way to exploit it.
* MySQL licenses the client libraries as GPL, meaning that any application that has support for MySQL needs to either be GPL or get a commercial license.
Oracle now owns two MySQL backend products. First InnoDB, which was their primary transaction-supporting backend, and now BerkeleyDB. Now, in order for MySQL AB to license MySQL database commercially, they need Oracle's permission (that is, if they want basic database features like atomic transactions).
And if you don't get a commercial license from MySQL AB, you can't link the mysql client library to a non-GPL application. That means, if you have a non-GPL application and you want to add support for MySQL, you are now dependent on Oracle.
Exactly. I was responding to someone who thought that the OS could do something to automagically multi-thread. I was trying to say that once you have machine code that can access any memory location, it's pretty much impossible to try to multi-thread it then.
However, it's a little more possible at the compiler level in, e.g., a java program. Let's say you have some code like:
[...] x = factorial(100); y = fib(112); return x + y; [...]
If both factorial() and fib() have no side effects, the java compiler could run them in separate threads and join the threads right before the return statement. The compiler could guarantee that those functions have no side effects because in java, you can't dereference an arbitrary memory address. Perhaps a C compiler could guarantee that, but that would be a lot more challenging and bug-prone.
Not much slower for two tasks, twice as fast at one.
Not true at all. Most CPU-bound applications are actually memory-bound. CPUs spend most of their time idle, waiting for memory. Idle at 2GHz is no better than idle at 1GHz.
Having 2 cores means you can parallelize independent tasks. 2 1GHz cores, in some cases, could be almost twice as fast as one 2 GHz core.
Not only that, but there are a lot of other factors, like how big the pipeline is and how it's constructed.
Slashdot Mirror
Ok, or they could keep them employed, and instruct them to develop the software in a way that slowly kills the product.
Your plan works in theory, but in reality they lose all the marketing steam they had before. Oracle would be able to string the commercial companies along for a while with MySQL or some Oracle offering, leading to slow adoption from the new company. The userbase would be fractured, disorganized, and incompatible for years.
The engines are both available under GPL or a commercial license.
However, as I pointed out, that still causes problems. In particular, the commercial MySQL licenses are required by anyone who adds MySQL support to their non-GPL application because the client libraries are GPL. And, since development of all of MySQL, BDB, and InnoDB are all centralized, it's easier for the development to be disrupted, and harder to restablish a development team for the forked version.
Transactional engine using filesystem? *shudder*
It could be done as a proof of concept at least. My point was that the tools are out there, and that building a transactional system is reinventing the wheel. How much of the wheel you want to reinvent is up to you.
Want a new job?
Looking right now actually.
You can't copy windows 100 times because copyright law prevents you, and the license doesn't specifically allow you to. Copyright law means the default is no copying or distribution or whatever you want to call it.
The GPL only permits copying if you follow a bunch of rules, some of which are in section 2b (which you left out), which requires that, for any whole or derived work, you must make it available under the terms of the GPL.
So, you can only give it to people on a "need to have" basis and hope it doesn't get out as GPL software. But any employee can legally then take it and redistribute it under the GPL license, whether you like it or not. You can't use an NDA to prevent the GPLed code from being released (otherwise you could do that with anyone's GPL code, just offer it for sale with an NDA so they can't distribute). So, it's only safe if you are the entire organization, or if you have very loyal employees.
Again, not exactly "free". More like "free but living in fear".
That was my point, is that none of those things will actually happen. That's why I said "By that time, it will all be irrelevant."
By that I meant, when hell freezes over, and all those things are rewritten or forked, Oracle will have already accomplished its goal of delaying MySQL's development and adoption, which will effectively kill it.
Although that still doesn't really explain your post. Nobody would need to rewrite BDB or InnoDB, they would just need to fork it. You still need someone who knows what they're doing, but it's not like the storage engine has to be written from scratch in a week.
And a transactional system isn't necessarily that complicated. Heck, build it on top of a transactional file system and a lot of the work is done (I know most transactional filesystems provide no isolation guarantee, but you at least have atomicity and durability).
because everything that makes it go is BSD licensed
And because the developers are physically spread around the globe, and spread among many companies. And the development model is already built in a distributed way.
How did you get here?
.org or .info lookups.
slashdot. ORG
That was brought to you by PostgreSQL, as with all other
The fact is, there is a lot of heavy commercial use of both databases. With public involvement/use from companies like Fujitsu, Sun, the American Chemical Society, BASF, the National Weather Service, U.S. Dept. of State, and many more, PostgreSQL does not have anything to prove over MySQL any more.
http://www.postgresql.org/about/users
Good thing we still have PostgreSQL. Companies can and do offer support, and offer commercial licensed versions.
And for those who need world-class support, Sun offers PostgreSQL support 24/7.
By the time any of that happens, it will most likely be too late. Oracle is just buying time, but that's all they need right now while they're collecting huge license fees.
I'm sure some people really like MySQL and might want to take up development, but not me. I am a PostgreSQL user. There are no such restrictions on PostgreSQL, and it works better for everything that I need it to do. Why take MySQL's almost-free database when there are great -- and truly free -- database alternatives like PostgreSQL, FirebirdSQL, Ingres, &c. available?
I am mostly interested in this discussion because of the business aspects of it, and how that relates to F/OSS. We might be seeing an example of a business model that doesn't work (dual license + depend on other companies), and that's important to the whole F/OSS community.
Ok, fair complaint. The companies are gone now, a part of Oracle. So there's not much left to be mad at, except Oracle.
We could get really mad at the former owners, but it's not easy when most of the people here have their price as well. If you own a small, modestly successful enterprise and Oracle lays down some cash, most people would take it, and not ask questions.
Maybe get mad at the vendors who left themselves -- and therefore their customers -- so vulnerable? MySQL, in particular, who had the rug pulled out from under them.
That's a mighty fine line you're trying to draw. The way I understand it, the GPL kicks in anytime copyright law would, i.e., when you copy it and it's not covered by fair use. And copying windows 100 times in an office certainly isn't legally fair use.
The GPL can have 10 paragraphs on it, but the real question is what a judge will determine to be a derivative work in the court of law. Derivative works are determined by copyright law, not a license. If something is determined by copyright law (and a judge) not to be a derivative work of product X, you are 100% free from the requirement to license at all from the copyright holder(s) of product X. However, if it is determined to be a derivative work of product X, you are 100% bound by the terms of product X.
By your reasoning, any derivative code could be magically turned into non-derivative code by writing a wrapper in 5 lines of code. I think you can get away with that if your wrapper implements a real standard, because then you can distribute your product (which makes use of standard A), and the wrapper for use by any of N existing products (N > 1), then just distribute one of those existing products seperately. However, if your product makes use of something that isn't really a standard, and it entirely depends on some specific product, it's obvious that you're trying magically make your derivitive work into an independent work without actually doing the work yourself.
Truly free software doesn't require you to hide in a legal grey area, constantly in fear of being sued. And if someone did sue, it would have some merit at least, so it would cost you a bundle to defend yourself.
How many of those engines are distributed under a free license and have transactional support? Looks like both are owned by Oracle now. Oracle did that for a reason, and it's not because they like to collect database companies.
Many users of MySQL depend on one or more of:
(1) the ability to license MySQL commercially with one of those engines cheaply
(2) the continued development of those storage engines
(3) the continued development of MySQL
Oracle can now stronly influence all of those things. #1 they can just raise the price or not license. #2 they can just lay off all the developers. Good luck getting an open sources devel team together before it's too late. #3, they can just refuse to license those backends, thereby preventing #1, which is also MySQL's source of revenue, leading indirectly to exactly the same case as #2.
I really think that using a more generic interface, such as JDBC/ODBC would effectively act as a GPL barrier
True. The difficulty there is that MySQL's version of SQL is substantially different from other dialects. Granted, the standard is not adhered to all that well by anyone. But there are definately a few MySQLisms that would stand out, and limit that argument. I don't know whether it would stand up or not, but it seems like a lawyer could make a reasonable argument that "hey, they're just using this as a workaround layer" if you're still using highly MySQL-specific SQL.
Furthermore, if you built from scratch a library that talked with the mysql server, you could give it a generic license.
Yes. I highly recommend that people interested in MySQL as an open source database do indeed implement a from-scratch LGPL version of the library. It may be necessary in the future, in a sudden way. Then, if the worst happened (development from MySQL AB, Innobase, and Sleepycat just stopped), you would at least have the commercial users still on board when you needed to organize some developers to fork the code. If you didn't have the LGPL library, the commercial MySQL licensees would just have to jump ship when that happened.
That's a pretty strong restriction, considering that organizations usually want to deploy many copies of an application, even if they are only using it internally. Particularly a database driven application.
You can also split hairs over whether you can use an interpreted language that has the library built-in or something. I think the standard is that if you depend on that specific code being there (i.e. the MySQL library), then it counts as distribution. The point is, you are deep in lawyer-ville. Maybe you can sort these things out and stay on the right side of the letter of the law. But to me, having to be so careful doesn't sound like the spirit "free software".
Let's imagine a hypothetical alternative: A GPL database and LGPL client libraries. You put as many of the databases anywhere you want, and you link up the client library to whatever you want and put the resulting programs wherever you want, or sell them if you want. To me, that's easy and feels a lot more free. Or, take the GNU example: GNU gzip will happily provide it's output to either GNU tar or BSD tar. Again, feels like the spirit of free software.
Limiting the linking of a library to GPL applications may promote more GPL applications. But limiting the distribution of a client library limits interoperability. A client library is sort of like a standard more than like code, and GPLing it means only GPL applications get to see the standard.
[ if you weren't serious, I apologize ]
There are two important decisions that I think are relevent:
(1) Oracle bought not one, but TWO mysql backends, which happened to be both of their transactional backends.
(2) MySQL AB licenses the client libraries under the GPL.
The only conclusion that I can come to from either of those is control.
MySQL AB needed control over their MySQL database, and so they restricted the distribution of the client libraries. You can argue about what licenses are acceptable for libraries in general, but for a client-server program, it is very strange to restrict the distribution of the client libraries. The decision therefore must have been deliberate, and made for a business reason. That reason is control.
And Oracle obviously made a business decision. There was question about the motives after buying Innobase, but those questions are now answered when they purchased the only remaining candidate for a transactional storage engine for the MySQL commercial product.
So here we have Oracle which clearly thinks they have control over MySQL AB, and MySQL AB which clearly thinks they have control over the MySQL database. For that to be false you would have to assume that one of those companies made a serious error in their business decision. So, Oracle now has some substantial degree of control over MySQL database.
To prevent Oracle from exercising this control, we need to
(1) fork the MySQL database
(2) do a cleanroom reverse engineering of the client libraries and make them LGPL/whatever (in order to keep current commercial MySQL users in business)
(3) fork InnoDB and/or BDB to make sure we have an open source backend that is actively developed.
By that time, it will all be irrelevant.
Fortunately, PostgreSQL is immune from these types of licensing problems. The client libraries and the database itself are freely destributable. And the developers work for a wide variety of companies. As far as I know, FirebirdSQL, Inges, and SAP DB are also free of licensing problems. That's 4 good alternatives if Oracle really tries to set MySQL back.
Because, many people depend on commercially-licensed MySQL because they have a non-GPL product that they want to include MySQL support for.
Now, the commercial distribution of MySQL may be weaker than the GPL version, because Oracle can stop licensing the "good" backends to MySQL AB for them to license to you. And the GPL version is highly restrictive because you can't link the client libraries to non-GPL clients.
And if MySQL AB stops developing MySQL because they can't sell people a database without transactions, the development organization of MySQL database is gone. It takes a long time and/or a lot of help to get that organization back, and by that time it may be irrelevent.
Don't blame Oracle (since it's their right to buy software); blame the people selling to Oracle.
Huh? That doesn't make any sense. It their right to sell to Oracle also.
Why not blame open source software developers who depend heavily on products that they can't control. I'm not saying it's always a bad idea to link to BDB, I'm just saying that if your project can be seriously hurt by the actions of another project, you need to have a plan B.
The terms of the deal were not disclosed. Perhaps it was a stock deal?
And even if not, it's not like the money was spent on some party. That money goes to another company, who will use that money to buy labor and/or capital. If an Oracle employee is being a net negative, it's economically more efficient to reallocate those human resources elsewhere. If they are highly qualified, maybe they could go work for google, or someone who could use them more effectively.
But at least now developers can fork the open source code
True. However, any successful move of development from one organization to open source coders is usually heavily backed by the organization, at least to get it started. Oracle knows that the organization of the project itself takes a lot of work to nurture, and that anyone who forked development wouldn't really get off the ground for a while, if ever. And time is valuable to Oracle now.
Yes it does, as a potential replacement for InnoDB as a backend for MySQL. When Oracle bought Innobase (makers of InnoDB), all the MySQL people suggested improving the BerkeleyDB backend to make it their primary transaction-supporting backend. Now, looks like that's owned by Oracle to. Maybe it's a coincidence? Or maybe the licensing of MySQL really is a weakness*, and Oracle saw a cheap way to exploit it.
* MySQL licenses the client libraries as GPL, meaning that any application that has support for MySQL needs to either be GPL or get a commercial license.
Oracle now owns two MySQL backend products. First InnoDB, which was their primary transaction-supporting backend, and now BerkeleyDB. Now, in order for MySQL AB to license MySQL database commercially, they need Oracle's permission (that is, if they want basic database features like atomic transactions).
And if you don't get a commercial license from MySQL AB, you can't link the mysql client library to a non-GPL application. That means, if you have a non-GPL application and you want to add support for MySQL, you are now dependent on Oracle.
Ok, fair enough, but you should have probably mentioned that, since it's relevant to the post you responded to, and not the typical situation.
And 2GHz still isn't twice as fast as 1GHz, unless maybe if you fit all of your data in L1 cache, and all other processor properties are identical.
Exactly. I was responding to someone who thought that the OS could do something to automagically multi-thread. I was trying to say that once you have machine code that can access any memory location, it's pretty much impossible to try to multi-thread it then.
However, it's a little more possible at the compiler level in, e.g., a java program. Let's say you have some code like:
[...]
x = factorial(100);
y = fib(112);
return x + y;
[...]
If both factorial() and fib() have no side effects, the java compiler could run them in separate threads and join the threads right before the return statement. The compiler could guarantee that those functions have no side effects because in java, you can't dereference an arbitrary memory address. Perhaps a C compiler could guarantee that, but that would be a lot more challenging and bug-prone.
Not much slower for two tasks, twice as fast at one.
Not true at all. Most CPU-bound applications are actually memory-bound. CPUs spend most of their time idle, waiting for memory. Idle at 2GHz is no better than idle at 1GHz.
Having 2 cores means you can parallelize independent tasks. 2 1GHz cores, in some cases, could be almost twice as fast as one 2 GHz core.
Not only that, but there are a lot of other factors, like how big the pipeline is and how it's constructed.