>> Can you list any requirements in terms of code other than the ones
>> forth in the initial post by Sascha Pachev a few years back?
>> I'm cleaning it up anyway so I could just as well take that into
> sure can! Sascha's post is quite old :)
> We have some people internally (right now) making the process for
> accepting external contributions much easier. This is if you choose to
> have it become part of the MySQL Server tree. You may want to keep it as
> an external project and just GPLed - maybe at least for the first few
> releases during any integration work (and until any MySQL release with
> it in there).
> I'll keep you informed of the relevant info as it becomes current.
> Basically, we'd look for:
> - is it well coded
> - if it touches MySQL Server code
> - does it conform to the coding guidelines/practices etc
> - we'd also get people here to review it before it goes in.
> - the other legal stuff
> of course, having more details somewhere public would be good - i'll get
> people onto it (one of those "we should have" that's been around for a
I have a lot of interest in that subject also, and some questions
regarding the "legal stuff".
If a project is pure GPL and maintained on the side, then the
distinction between MySQL and MySQL+Patch "X" is clear,
and existence of project X (say, on SourceForge) does not prevent MySQL
AB to offer a dual license on it's own code base.
If the code is included into the MySQL server tree, what are the
guidelines and things to do to make sure
that the entire code can continue to be distributed under the dual
license ? (Assuming it's MySQL AB best interest to do so).
Is there anything in place comparable to the FSF copyright assignment
for MySQL ?
Let time spent with legal stuff, more time spent coding :)