Comments on: I don’t see why the GPL would be a major barrier to a useful MySQL fork http://www.dbms2.com/2009/04/21/i-dont-see-why-the-gpl-would-be-a-major-barrier-to-a-useful-mysql-fork/ Choices in data management and analysis Sat, 30 Jan 2010 06:11:40 -0500 http://wordpress.org/?v=2.8.4 hourly 1 By: Curt Monash http://www.dbms2.com/2009/04/21/i-dont-see-why-the-gpl-would-be-a-major-barrier-to-a-useful-mysql-fork/comment-page-1/#comment-120919 Curt Monash Mon, 11 May 2009 03:22:23 +0000 http://www.dbms2.com/?p=760#comment-120919 ScaleDB ScaleDB

]]> By: Jeff http://www.dbms2.com/2009/04/21/i-dont-see-why-the-gpl-would-be-a-major-barrier-to-a-useful-mysql-fork/comment-page-1/#comment-120907 Jeff Mon, 11 May 2009 00:27:25 +0000 http://www.dbms2.com/?p=760#comment-120907 Mike didn't leave a calling card? Mike didn’t leave a calling card?

]]> By: Curt Monash http://www.dbms2.com/2009/04/21/i-dont-see-why-the-gpl-would-be-a-major-barrier-to-a-useful-mysql-fork/comment-page-1/#comment-120841 Curt Monash Sun, 10 May 2009 19:37:28 +0000 http://www.dbms2.com/?p=760#comment-120841 Jeff, Not really. I'm just waiting -- and not necessarily while holding my breath -- for news that storage engine CEOs like you and Mike are getting together and actually making something happen. CAM Jeff,

Not really. I’m just waiting — and not necessarily while holding my breath — for news that storage engine CEOs like you and Mike are getting together and actually making something happen.

CAM

]]> By: Jeff http://www.dbms2.com/2009/04/21/i-dont-see-why-the-gpl-would-be-a-major-barrier-to-a-useful-mysql-fork/comment-page-1/#comment-120837 Jeff Sun, 10 May 2009 18:01:13 +0000 http://www.dbms2.com/?p=760#comment-120837 Curt, Do you have any additional thoughts, or have you uncovered any reasons, to your comments expressed above? But in principle, I’m not aware of any reason a software vendor or consortium of software vendors couldn’t support a project to modify a forked version of MySQL as they deem appropriate, GPL that, and then sell their own proprietary software to interact with it. Secondly, can you think of any reasons why a customer wouldn't be concerned about what Oracle might do to forked MySQL initiatives? Curt,
Do you have any additional thoughts, or have you uncovered any reasons, to your comments expressed above?

But in principle, I’m not aware of any reason a software vendor or consortium of software vendors couldn’t support a project to modify a forked version of MySQL as they deem appropriate, GPL that, and then sell their own proprietary software to interact with it.

Secondly, can you think of any reasons why a customer wouldn’t be concerned about what Oracle might do to forked MySQL initiatives?

]]> By: Curt Monash http://www.dbms2.com/2009/04/21/i-dont-see-why-the-gpl-would-be-a-major-barrier-to-a-useful-mysql-fork/comment-page-1/#comment-119347 Curt Monash Fri, 01 May 2009 00:43:58 +0000 http://www.dbms2.com/?p=760#comment-119347 Mike, Good point. And I think it addresses a point Dan was raising in another comment thread. Thanks, CAM Mike,

Good point. And I think it addresses a point Dan was raising in another comment thread.

Thanks,

CAM

]]> By: Mike http://www.dbms2.com/2009/04/21/i-dont-see-why-the-gpl-would-be-a-major-barrier-to-a-useful-mysql-fork/comment-page-1/#comment-119311 Mike Thu, 30 Apr 2009 22:29:45 +0000 http://www.dbms2.com/?p=760#comment-119311 It is my understanding that commercial storage engines can create an OSS glue layer that makes calls to storage engines (multiple). This same OSS glue could work with Berkeley DB, PostgreSQL and Ingres. Thus it is DB independent. Such glue could then call multiple commercial storage engines, aking it storage engine independent. This way the two pieces (MySQL and storage engine) are not considered one product. This satisfies another aspect of the buffer between GPL and commercial. With an open source glue that supports X DBMS and Y storage engines, and by making the glue OSS, you are good to go. It is my understanding that commercial storage engines can create an OSS glue layer that makes calls to storage engines (multiple). This same OSS glue could work with Berkeley DB, PostgreSQL and Ingres. Thus it is DB independent. Such glue could then call multiple commercial storage engines, aking it storage engine independent. This way the two pieces (MySQL and storage engine) are not considered one product. This satisfies another aspect of the buffer between GPL and commercial. With an open source glue that supports X DBMS and Y storage engines, and by making the glue OSS, you are good to go.

]]> By: Curt Monash http://www.dbms2.com/2009/04/21/i-dont-see-why-the-gpl-would-be-a-major-barrier-to-a-useful-mysql-fork/comment-page-1/#comment-118150 Curt Monash Thu, 23 Apr 2009 14:02:33 +0000 http://www.dbms2.com/?p=760#comment-118150 Well, yes. The GPL carries quite a load of FUD with it. Well, yes. The GPL carries quite a load of FUD with it.

]]> By: Daniel Weinreb http://www.dbms2.com/2009/04/21/i-dont-see-why-the-gpl-would-be-a-major-barrier-to-a-useful-mysql-fork/comment-page-1/#comment-118106 Daniel Weinreb Thu, 23 Apr 2009 09:52:38 +0000 http://www.dbms2.com/?p=760#comment-118106 IANAL, and even smart lawyers whom I've spoken to consider the GPL hard to deal with because it's so uncertain what various provisions might mean. There evidently is not a lot of case law at this point. I know enough about law to know that relying on the distinction between "statically linked" and "dynamically linked" is unlikely to make a big difference in a legal outcome. If a storage engine vendor has to tell its customers to download something and recompile or relink something, that is a very large problem. Making software that requires even THAT level of technical expertise, and can't just install in a straightforward way, would be a serious disadvantage. Maybe you could hide it all in an installation tool, or something like that. But my biggest worry is that the GPL issues raised here are murky. I would want some very strong assurances from a lawyer who, for some reason, was extremely credible about interpretation of the GPL, were I to approach this potential time-bomb. IANAL, and even smart lawyers whom I’ve spoken to consider the GPL hard to deal with because it’s so uncertain what various provisions might mean. There evidently is not a lot of case law at this point.

I know enough about law to know that relying on the distinction between “statically linked” and “dynamically linked” is unlikely to make a big difference in a legal outcome.

If a storage engine vendor has to tell its customers to download something and recompile or relink something, that is a very large problem. Making software that requires even THAT level of technical expertise, and can’t just install in a straightforward way, would be a serious disadvantage. Maybe you could hide it all in an installation tool, or something like that.

But my biggest worry is that the GPL issues raised here are murky. I would want some very strong assurances from a lawyer who, for some reason, was extremely credible about interpretation of the GPL, were I to approach this potential time-bomb.

]]> By: Curt Monash http://www.dbms2.com/2009/04/21/i-dont-see-why-the-gpl-would-be-a-major-barrier-to-a-useful-mysql-fork/comment-page-1/#comment-117985 Curt Monash Wed, 22 Apr 2009 20:05:18 +0000 http://www.dbms2.com/?p=760#comment-117985 My whole theme here is doing something with MySQL that the MySQL company might actively oppose. That can only be done under the GPL. :) My whole theme here is doing something with MySQL that the MySQL company might actively oppose. That can only be done under the GPL. :)

]]> By: Max Lybbert http://www.dbms2.com/2009/04/21/i-dont-see-why-the-gpl-would-be-a-major-barrier-to-a-useful-mysql-fork/comment-page-1/#comment-117972 Max Lybbert Wed, 22 Apr 2009 19:34:21 +0000 http://www.dbms2.com/?p=760#comment-117972 <blockquote>It is widely believed that Richard Stallman et al. are correct when they claim that anything which links with a GPLed program must be GPLed itself</blockquote> I've given up on Stallman's understanding of derivative work. He starts out well enough discussing how people can contribute code to FSF projects even if they have seen the source code for non-GPLed programs ( http://www.gnu.org/prep/standards/html_node/Reading-Non_002dFree-Code.html#Reading-Non_002dFree-Code ). But when it comes to linking to a GPLed program he leaves the law behind and talks about technical questions like address spaces. Derivative work is a legal question, and the boundaries will be expressed in legal terms, not technical ones. <blockquote>Currently, any version of the MySQL code that isn’t proprietary to the MySQL company ... is covered by GPL 2.</blockquote> I understood MySQL was open to dual licensing ( http://www.mysql.com/about/legal/licensing/oem/#3 ). Is this not the case in practice? <blockquote>But in principle, I’m not aware of any reason a software vendor or consortium of software vendors couldn’t support a project to modify a forked version of MySQL as they deem appropriate, GPL that, and then sell their own proprietary software to interact with it.</blockquote> I agree from a technical point of view. There are some costs associated with maintaining forks (GNU Emacs vs XEmacs, or if you prefer http://www.codemonkey.org.uk/projects/fsx/ ), but if the consortium gets enough user and developer support it can run indefinitely. But I would prefer to see one de facto implementation instead of fragmentation a la FreeBSD, OpenBSD, NetBSD, DragonflyBSD, etc. (please note, I have no problem with the BSDs; they are great software, but there is no arguing that a lot of effort is duplicated by four teams maintaining their own BSD).

It is widely believed that Richard Stallman et al. are correct when they claim that anything which links with a GPLed program must be GPLed itself

I’ve given up on Stallman’s understanding of derivative work. He starts out well enough discussing how people can contribute code to FSF projects even if they have seen the source code for non-GPLed programs ( http://www.gnu.org/prep/standards/html_node/Reading-Non_002dFree-Code.html#Reading-Non_002dFree-Code ). But when it comes to linking to a GPLed program he leaves the law behind and talks about technical questions like address spaces.

Derivative work is a legal question, and the boundaries will be expressed in legal terms, not technical ones.

Currently, any version of the MySQL code that isn’t proprietary to the MySQL company … is covered by GPL 2.

I understood MySQL was open to dual licensing ( http://www.mysql.com/about/legal/licensing/oem/#3 ). Is this not the case in practice?

But in principle, I’m not aware of any reason a software vendor or consortium of software vendors couldn’t support a project to modify a forked version of MySQL as they deem appropriate, GPL that, and then sell their own proprietary software to interact with it.

I agree from a technical point of view. There are some costs associated with maintaining forks (GNU Emacs vs XEmacs, or if you prefer http://www.codemonkey.org.uk/projects/fsx/ ), but if the consortium gets enough user and developer support it can run indefinitely. But I would prefer to see one de facto implementation instead of fragmentation a la FreeBSD, OpenBSD, NetBSD, DragonflyBSD, etc. (please note, I have no problem with the BSDs; they are great software, but there is no arguing that a lot of effort is duplicated by four teams maintaining their own BSD).

]]>