Hacker News new | comments | show | ask | jobs | submit login

As soon as Oracle bought them, the writing was on the wall for an open-source MySQL. Look how quickly they murdered OpenSolaris. Oracle is anathema to open software.

The writing has been on the wall ever since MySQL AB required copyright assignment.

Monty doesn't come to this with clean hands.

Copyright assignment is basically required if you're going to sell an open source project under a different license. It's not usually nefarious, all that contributed code is still available under GPL.

The point is that if one entity owns the original copyright, they can wreak sufficient havoc that the project can splinter into individually anaemic forks.

MySQL has splintered into at least 3 competing forks outside of the "real" MySQL: MariaDB, Percona and Drizzle.

I wouldn't say they "compete", at least, not harmfully. Maria and Percona swap patches with each other, and are drop-in replacements for MySQL. Drizzle is an exploration of the idea of paying off as much as possible of MySQL's technical debt and throwing away crufty backwards compatibility. The technical ecology of users and developers around MySQL is healthier than it has ever been.

> going to sell an open source project under a different license

It's required where you want to sell a restrictively licensed (GPL, say) open source project under a commercial license. If it's licensed under something like the Apache license or BSD, you can do what you want with it. But then, so can everyone else, so you don't have the advantage you would with the dual license and require copyright assignment strategy.

> restrictively licensed (GPL, say) open source project

Please, stop spreading this meme. The only thing GPL restricts is companies who want to restrict the freedoms of their users. Software, sex and yes, users, are better when free.

The FSF uses the words lax and permissive to describe licenses which do not have the requirements of the GPL (http://www.gnu.org/licenses/license-list.html), and describe the GPL as a copyleft license. If you want to describe the GPL with a word that is not "copyleft", I guess you would use some word opposite to lax and permissive, like restrictive. So it would only be restrictive relative to the permissive licenses, but in that context, it is restrictive, which is not necessarily a bad thing. Though personally I prefer to describe it as "strict".

It does not matter how you twist it, GPL is more restrictive, than MIT or BSD. And that's without going into you "freedom of usera" FUD.

I didn't pass any judgment on it, I just said it's more restrictive than a BSD style license. I have opinions on the two licenses, and could probably write a fairly lengthly article on it: "it's complicated".

You can call it more "robust", "strict" or a number of other words that more precisely reflect the GPL role and goals.

There are less things you can do with GPLed software than BSD software. Therefore, when comparing GPL and BSD, GPL is more restrictive. There is no need for the doublespeak of calling it anything else in a comparison.

Tell me, how does "robust" translate to "there are more restrictions on what you can do with this"?

> There are less things you can do with GPLed software

Yes. You won't be able to restrict your users with GPL.

"Robust" because the software, once licensed under it, will remain free.

BSDL software is usually far more restricted by the time it reaches end users' hands. I wouldn't take much comfort from being able to say all the proprietary software I subsidized was really somebody else's fault.

I don't know that is true. I would bet that Greenplum and EnterpriseDB have smaller marketshare, for example, than official PostgreSQL.

"It's complicated", and depends on a lot of factors: sometimes the equilibrium tips one way, and a vendor basically 'cleans up', ala Sun Microsystems and BSD Unix (the free ones took years to catch up). I think that is less likely to happen in this day and age, but it's a fascinating subject worthy of books, not merely a few comments on a thread.

GPL is restrictive. It may be unacceptable to put GPLd apps on the App Store because of Apple's regulations, for instance. It makes it impossible to integrate Pixar's new open-sourced code with Blender, because the licenses conflict.

Sure, the problems are caused by the contradictory licenses, but GPL is part of the problem here.

> It makes it impossible to integrate Pixar's new open-sourced code with Blender, because the licenses conflict.

Because Pixar's code is licenced under another restricted licence (MS-PL) which is crafted to be incompatible with GPL. Apparently Pixar is talking with Ton Rosendaal (Blender development leader) about solving the licence issue so it seems it won't be 'impossible' after all. Likely some sort of dual-licencing solution will take place.

Which will be great, but this isn't the only project using MS-PL. And if the GPL didn't include its "strong copyleft" text, there wouldn't be an issue.

It's coercion which tries to make everything freer, but in this case made things less free.

>Which will be great, but this isn't the only project using MS-PL.

It's certainly one of extremely few I've ever come across, and it's the only one which pertains to component/framework code like opensubdiv that I've seen, which is usually not GPL licenced either but rather uses permissive licencing like BSD/MIT.

>And if the GPL didn't include its "strong copyleft" text, there wouldn't be an issue.

That's the whole point of GPL, to keep the source code open. Just like the whole point of MS-PL is to serve proprietary needs while still employing the reciprocal nature of GPL.

And of course when this is shown to be problematic with a simple (GPL v2) license, the answer is to add tons of complications to the license to the point where you can't say that if you read both licenses literally, that the GPL v3 and BSD licenses are compatible.....

I actually kinda like the GPL v2. The GPL v3 license is an abomination however and needs to die.

Before you jump on me about BSD license compatibility, let me add a caveat and explanation. The caveat is that although the texts of the licenses are at least likely incompatible, "everyone" (namely every free software-inclined lawyer I have asked about this issue) agrees that since the intent was to be compatible the GPL v3 should be read to be compatible, but no two lawyers give me the same answers. I have discussed this with both Eben Moglen and Richard Fontana however. Also one cannot dispute that the GPL v3 is clearly compatible with the MIT license since that explicitly allows sublicensing.

The problem has to do with section 7 additional permissions and additional restrictions in the GPL v3, as well as the lack of a sublicensing grant in any of the BSD licenses. The BSD licenses offer a public grant by the software author to all who obtain the source code. However, they allow other intermingled code to be subject to other licensing schemes. This is different from the MIT license which directly allows sublicensing (Author A publishes, I take his work, and change the effective license without changing the software, and sell it to you, offering only some of the rights I received). The GPL v3 arguably requires a sublicensing grant from a permissive license in order to be compatible and the BSD family does not give this sort of license.

So when I talked with Moglen he suggested it would be compatible because you could add whatever additional restrictions you wanted but those would be unenforcible until actual changes were made to the software. Since the license change would be unenforcible, he suggested, the original author would not have his or her copyrights infringed. Richard Fontana however has suggested that this is a bad assumption and that developers must not make such an assumption that this is safe.

Instead Fontana suggests that additional notices should be read broadly enough to include the BSD license (and license grant) as is. However, this guts the idea of additional permissions under the GPL v3 and the requirement that they be legally removable without altering the code. Since you can't reduce the BSD license to (GPL v3 + permissions that can be removed without altering the software), the license is not compatible with the text of the GPL v3.

This means that although the licenses are (everyone agrees) compatible, it isn't at all clear as to what this means. Nor is it clear if I write a BSD license which explicitly states that sublicensing is not permitted and that permissions can only be revoked upon altering the code, whether this would also be compatible.

In short the solution to a license which may have some corner cases is a license that lawyers can argue about endlessly.

"Robust" is spin. "Restrictive" is neutral and factual.

Haven't we had enough annoying GPL vs BSD license arguments in the past 20 years?

"Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them." -- the guidelines

Copyright assignment is used by many projects, FSF included. Is there a comittment to the original authors to maintain an open source license in the MySQL case?

Not really. It was so, as mkurt explained, that MySQL AB could make money selling indulgences.

FSF is an exceptional case. In practice, however, dispersed copyrights are more effective for the user community because no one entity can wreak havoc through strategic neglect or minimal compliance.

There's a lot in a software system that is taken for granted that the GPL doesn't cover.

It's interesting. One possible interpretation is that dispersed copyrights may also create a situation where joint authors can violate the license with impunity. On the other hand, it avoids this: http://www.law.cornell.edu/uscode/text/17/203 (because getting a 50% quorum to revoke previously granted copyright license is going to be difficult indeed).

Also same story with OpenOffice, and Jenkins/Hudson.

OpenSolaris is still available for download including the source.


It's just not supported or maintained any longer.

I miss Sun.

They made some seriously cool stuff, and in their later years they were really quite progressive in their outlook and approach.

Jonathan Schwartz, for me anyway, kicked off the whole cool, open and chatty top exec thing that's so common now.

> in their later years they were really quite progressive in their outlook and approach.

This is a common misconception about Sun. In fact, they were quite progressive from the beginning. They embraced a hybrid open/closed model from day one, for instance. They opened up some key technologies, such as NFS and SPARC. They maintained huge, comparatively, research budgets, with relatively few strings attached to productization of that research. Through the late 90s and very early '00 (Dotcom era) they were under constant pressure from institutional investors to cut research funding, but didn't.

In the end, though, I have to agre. I miss Sun (though my friends and co-workers probably do not miss me talking about how great Sun is)

[edit: cut-n-paste quote error]

>I miss Sun. They made some seriously cool stuff, and in their later years they were really quite progressive in their outlook and approach.

Yes, and look how well it worked out for them...

One of the problems with corporate R&D in general it seems: what's successful for businesses and what's good for technological advancement often seem not to be in sync. Some of the best stuff has come from notoriously unprofitable groups, like the old Xerox PARC, which benefitted the whole sector, but not its originators.

Look at the amazing things that came from Bell Labs. The transistor, laser, cell phone (in the 40's!), UNIX......

Unlike most corporate R&D, PARC did good stuff. It was Xerox HQ that was exceptionally stupid. They had all the technology, but managed to do very little with it. Silicon Valley companies picked it up and ran with it.

Most big corporate research labs did good work. PARC, Bell Labs, IBM Research, Sun Labs, even Microsoft Research have all done "good stuff." Much of it critical to today's understanding of technology and computer science.

Certainly PARC has been instrumental in many areas of technology, I don't think it's fair to dismiss most corporate research. In fact, at least in the land of technology, most corporate research has done good stuff.

Making cool stuff and being progressive actually kept them alive longer.

When x86's starting eating away the profits of their SPARC business, it was abundantly clear they would have problems down the road. Computing platforms tend to move up and what's on your desktop now may be powering servers ten years from now (quite possibly because by then people will have spent ten years writing and learning how to write software for it).

Sun tried to disrupt the desktop with the SunRay series, but they never got to the right price point. I'd have loved to have a Niagara-based desktop and I bet that had one been available for Unix enthusiasts, Firefox would be rendering pages and tabs on dozens of different threads.

People often discount that, but I can say it from experience. Back in 1998, I had two machines on my desk at work: a 400 MHz Pentium II (or III) and a dual-processor 200 MHz Pentium (both running Windows NT 4). While the single processor was somewhat faster, the overall experience of the dual processor machine was much smoother, with very few pauses and hourglasses. A lot of software today is single-threaded for the sole reason processors have only recently become multi-threaded.

And x86's only became multi-core/thread after the NT kernel became mainstream.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact