[Maria-discuss] Additional promise to the MCA

newer
[Maria-discuss] [Kristian Nielsen]...

older
Re: [Maria-discuss] Information...

Henrik Ingo

15 Sep 2009 15 Sep '09

4:11 p.m.

Hi all As Monty blogged some time ago http://monty-says.blogspot.com/2009/08/thoughts-about-dual-licensing-open.ht... ...we want to add a promise to our MariaDB contributors signing the MCA, that we will not use their contributions to restrict other licensees ability to contribute to Open Source. This text has now been approved by a lawyer. The question is, is it understandable? ********************************** Additional promise to contributions under the Monty Program Contributor Agreement Monty Program Ab promises to each contributor assigning rights under the Monty Program Ab Contributor Agreement, that when licensing 'products' (software), that include a contribution, to other 3rd parties, the license will be either i) an Open Source license (www.opensource.org), or ii) another license, in which case: * the other license will NOT restrict the licensee from making his own modifications to the product, including adding other suitably licensed code or other 'materials' from other sources (such as code available under suitable Open Source licenses) * the license will NOT restrict the licensee from publishing his own code or other 'materials' including, but not limited to, under an Open Source license. As a special note, it is observed that the Monty Program Ab Contributor Agreement itself fulfills these requirements. Also note that this promise does not not extend as a requirement to 3rd parties so as to restrict their rights to license products containing contributions. ********************************** We are especially interested to get feedback on the understandability of the last paragraph. henrik -- email: henrik.ingo@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc

Show replies by date

Oleksandr Byelkin

16 Sep 16 Sep

10:53 p.m.

Hi! 15 сент. 2009, в 17:11, Henrik Ingo написал(а): [skip]

...

As a special note, it is observed that the Monty Program Ab Contributor Agreement itself fulfills these requirements. Also note that this promise does not not extend as a requirement to 3rd parties so as to restrict their rights to license products containing contributions. **********************************

We are especially interested to get feedback on the understandability of the last paragraph.

After 5 times reading it I think I understand: 1) the MCA satisfy requirements of this promise. 2) we do not require that others (not we and the contributor so 3rd parties) can not license other(?) products containing the same contributions. (if above is not corect that I was not able to understand)

Michael Widenius

6 Oct 6 Oct

4:32 p.m.

hi!

...

...
...
...
...
"Oleksandr" == Oleksandr Byelkin writes:

Oleksandr> Hi! Oleksandr> 15 сент. 2009, в 17:11, Henrik Ingo написал(а): Oleksandr> [skip]

...

...
As a special note, it is observed that the Monty Program Ab Contributor Agreement itself fulfills these requirements. Also note that this promise does not not extend as a requirement to 3rd parties so as to restrict their rights to license products containing contributions. **********************************

We are especially interested to get feedback on the understandability of the last paragraph.

Oleksandr> After 5 times reading it I think I understand: Oleksandr> 1) the MCA satisfy requirements of this promise. Oleksandr> 2) we do not require that others (not we and the contributor so 3rd Oleksandr> parties) can not license other(?) products containing the same Oleksandr> contributions. Oleksandr> (if above is not corect that I was not able to understand) Many not in the same sentence. Removing the not's: We allow other parties that license code from us to put their own restrictions on how they relicense their code. The main idea is that we will not put any restrictions in the code we relicense (like Sun does) Regards, Monty

Michael Widenius

4:34 p.m.

Hi!

...

...
...
...
...
"Henrik" == Henrik Ingo writes:

Henrik> Hi all Henrik> As Monty blogged some time ago Henrik> http://monty-says.blogspot.com/2009/08/thoughts-about-dual-licensing-open.ht... Henrik> ...we want to add a promise to our MariaDB contributors signing the Henrik> MCA, that we will not use their contributions to restrict other Henrik> licensees ability to contribute to Open Source. Henrik> This text has now been approved by a lawyer. The question is, is it Henrik> understandable? Henrik> ********************************** Henrik> Additional promise to contributions under the Monty Program Contributor Henrik> Agreement Henrik> Monty Program Ab promises to each contributor assigning rights under the Monty Henrik> Program Ab Contributor Agreement, that when licensing 'products' (software), Henrik> that include a contribution, to other 3rd parties, the license will be either Henrik> i) an Open Source license (www.opensource.org), or Henrik> ii) another license, in which case: Henrik> * the other license will NOT restrict the licensee from making his own Henrik> modifications to the product, including adding other suitably licensed code or Henrik> other 'materials' from other sources (such as code available under suitable Henrik> Open Source licenses) Henrik> * the license will NOT restrict the licensee from publishing his own code or Henrik> other 'materials' including, but not limited to, under an Open Source license. Henrik> As a special note, it is observed that the Monty Program Ab Contributor Henrik> Agreement itself fulfills these requirements. Also note that this promise Henrik> does not not extend as a requirement to 3rd parties so as to restrict Henrik> their rights to license products containing contributions. What is the state with the above ? I still think it's quite long and not much easier to understand that what we have now: "Monty Program Ab agrees that when it dual licenses code, it will not restrict the way the third party licensee uses the licensed copy of the code nor restrict how they use their own code. " Regards, Monty

Henrik Ingo

7:51 p.m.

On Tue, Oct 6, 2009 at 5:34 PM, Michael Widenius wrote:

...

...
...
...
...
...
"Henrik" == Henrik Ingo writes:

Henrik> Hi all Henrik> As Monty blogged some time ago Henrik> http://monty-says.blogspot.com/2009/08/thoughts-about-dual-licensing-open.ht... Henrik> ...we want to add a promise to our MariaDB contributors signing the Henrik> MCA, that we will not use their contributions to restrict other Henrik> licensees ability to contribute to Open Source.

Henrik> This text has now been approved by a lawyer. The question is, is it Henrik> understandable?

Henrik> **********************************

Henrik> Additional promise to contributions under the Monty Program Contributor Henrik> Agreement

Henrik> Monty Program Ab promises to each contributor assigning rights under the Monty Henrik> Program Ab Contributor Agreement, that when licensing 'products' (software), Henrik> that include a contribution, to other 3rd parties, the license will be either

Henrik> i) an Open Source license (www.opensource.org), or Henrik> ii) another license, in which case:

Henrik> * the other license will NOT restrict the licensee from making his own Henrik> modifications to the product, including adding other suitably licensed code or Henrik> other 'materials' from other sources (such as code available under suitable Henrik> Open Source licenses)

Henrik> * the license will NOT restrict the licensee from publishing his own code or Henrik> other 'materials' including, but not limited to, under an Open Source license.

Henrik> As a special note, it is observed that the Monty Program Ab Contributor Henrik> Agreement itself fulfills these requirements. Also note that this promise Henrik> does not not extend as a requirement to 3rd parties so as to restrict Henrik> their rights to license products containing contributions.

What is the state with the above ?

I still think it's quite long and not much easier to understand that what we have now:

Yes. We got some feedback and 100% indicated it wasn't really understandable. My current idea is to remove the "as a special note" part, but keep it as is until then. Ie legally this should be ok as it was approved by lawyer. The problem is that nobody understands what it is about. Here I was thinking we should write a non-legal introduction that explains why on earth we have this promise. It could also link to your blog, which should explain a lot. Then have the actual legal promise after the non-legal intro. I've seen for instance the Red Hat patent promise does this, and seems to work. I then of course have not had time to write the intro. (I don't mind if someone else does it, as long as the legal text is as above, minus the last paragraph.) Last step is to link from MCA, and MCA FAQ, to the intro+promise, which should be one separate page. henrik -- email: henrik.ingo@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc

Michael Widenius

8 Oct 8 Oct

12:42 a.m.

Hi!

...

...
...
...
...
"Henrik" == Henrik Ingo writes:

Henrik> On Tue, Oct 6, 2009 at 5:34 PM, Michael Widenius wrote:

...

...
...
...
...
...
> "Henrik" == Henrik Ingo writes:

Henrik> Hi all Henrik> As Monty blogged some time ago Henrik> http://monty-says.blogspot.com/2009/08/thoughts-about-dual-licensing-open.ht... Henrik> ...we want to add a promise to our MariaDB contributors signing the Henrik> MCA, that we will not use their contributions to restrict other Henrik> licensees ability to contribute to Open Source.

...
Henrik> This text has now been approved by a lawyer. The question is, is it Henrik> understandable?

...

<cut> Henrik> We got some feedback and 100% indicated it wasn't really understandable. The same was more or less said of the new text... (See Larry's response) Henrik> My current idea is to remove the "as a special note" part, but keep it Henrik> as is until then. Ie legally this should be ok as it was approved by Henrik> lawyer. Henrik> The problem is that nobody understands what it is about. Here I was Henrik> thinking we should write a non-legal introduction that explains why on Henrik> earth we have this promise. It could also link to your blog, which Henrik> should explain a lot. Then have the actual legal promise after the Henrik> non-legal intro. I've seen for instance the Red Hat patent promise Henrik> does this, and seems to work. That sounds like a good idea. Henrik> I then of course have not had time to write the intro. (I don't mind Henrik> if someone else does it, as long as the legal text is as above, minus Henrik> the last paragraph.) I would however like to know what problems the lawyer had with my paragraph. Henrik> Last step is to link from MCA, and MCA FAQ, to the intro+promise, Henrik> which should be one separate page. Regards, Monty

Henrik Ingo

9:28 p.m.

On Thu, Oct 8, 2009 at 1:42 AM, Michael Widenius wrote:

...

Henrik> I then of course have not had time to write the intro. (I don't mind Henrik> if someone else does it, as long as the legal text is as above, minus Henrik> the last paragraph.)

I would however like to know what problems the lawyer had with my paragraph.

If you mean... a) your original promise text: "Monty Program Ab agrees that when it dual licenses code, it will not restrict the way the third party licensee uses the licensed copy of the code nor restrict how they use their own code. " ...the lawyer never saw it. It was my "devils advocate reading" of it that made me think someone could say we cannot distribute MariaDB as GPL (since it has restrictions :-) b) in the new text, the last paragraph "As a special note, it is observed that the Monty Program Ab Contributor Agreement itself fulfills these requirements. Also note that this promise does not not extend as a requirement to 3rd parties so as to restrict their rights to license products containing contributions." ...the lawyer is fine with it, but nobody understands it. It also doesn't really add anything of legal significance, so it can be taken away. It was intended to be informational, but apparently the effect is the opposite! A short non-legal introduction is clearly the way to go. If I only didn't need to sleep at nights, I would have written it already... henrik -- email: henrik.ingo@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc

Arjen Lentz

9 Oct 9 Oct

1:38 a.m.

Hi Henrik On 09/10/2009, at 5:28 AM, Henrik Ingo wrote:

...

On Thu, Oct 8, 2009 at 1:42 AM, Michael Widenius wrote:

...
Henrik> I then of course have not had time to write the intro. (I don't mind Henrik> if someone else does it, as long as the legal text is as above, minus Henrik> the last paragraph.)

I would however like to know what problems the lawyer had with my paragraph.

If you mean...

a) your original promise text: "Monty Program Ab agrees that when it dual licenses code, it will not restrict the way the third party licensee uses the licensed copy of the code nor restrict how they use their own code. "

...the lawyer never saw it. It was my "devils advocate reading" of it that made me think someone could say we cannot distribute MariaDB as GPL (since it has restrictions :-)

That reading is incorrect, or rather - incomplete/unclear depending on your subject matter knowledge. It's unambiguous to me. Your reasoning above however is as far as I can see, incorrect in two ways. First: GPL provides additional freedoms to users, compared to the standard copyright which is the baseline. By default the IP owner holds *all* the rights and the user *none*, so asserting that a license "restricts" is silly, you can't get <0 rights - yes I know, people say this all the time anyway, particularly about GPL, but the baseline they presume is just wrong. Second: When dual licensed (best be clear and just say non-GPL/BSD license), there is a specific license in place which can do anything it likes, that's again the perogative of the IP holder. However, that's is not about GPL at all, and thus the sentence does not refer to GPL-licensed MariaDB. Cheers, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget. Follow our blog at http://openquery.com/blog/ OurDelta: enhanced builds for MySQL @ http://ourdelta.org

Arjen Lentz

7 Oct 7 Oct

1:15 a.m.

Hi Monty, Henrik On 07/10/2009, at 12:34 AM, Michael Widenius wrote:

...

I still think it's quite long and not much easier to understand that what we have now:

"Monty Program Ab agrees that when it dual licenses code, it will not restrict the way the third party licensee uses the licensed copy of the code nor restrict how they use their own code. "

In that case you might as well just keep it all GPL or BSD and sell it rather than dual licensing? Then the recipient has all the normal GPL or BSD rights and obligations that apply to the rest of the code anyway, without need for extra licensing texts. Dual would only make sense for discrete/distinct components, but even there it might be easier to just have it be GPL or BSD. People come back to the original company for expertise/customisation anyway, as they're the experts. As long as the service is good. There's also no incentive to like republish stuff, as that wouldn't be the core business of the client company. They wouldn't have interest in that. Cheers, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget. Follow our blog at http://openquery.com/blog/ OurDelta: enhanced builds for MySQL @ http://ourdelta.org

MARK CALLAGHAN

1:36 a.m.

On Tue, Oct 6, 2009 at 4:15 PM, Arjen Lentz wrote:

...

Hi Monty, Henrik

On 07/10/2009, at 12:34 AM, Michael Widenius wrote:

...
I still think it's quite long and not much easier to understand that what we have now:

"Monty Program Ab agrees that when it dual licenses code, it will not restrict the way the third party licensee uses the licensed copy of the code nor restrict how they use their own code. "

In that case you might as well just keep it all GPL or BSD and sell it rather than dual licensing? Then the recipient has all the normal GPL or BSD rights and obligations that apply to the rest of the code anyway, without need for extra licensing texts.

Dual would only make sense for discrete/distinct components, but even there it might be easier to just have it be GPL or BSD. People come back to the original company for expertise/customisation anyway, as they're the experts. As long as the service is good. There's also no incentive to like republish stuff, as that wouldn't be the core business of the client company. They wouldn't have interest in that.

It is easier to contribute code using BSD/GPL than MCA/SCA when working at a large company. People responsible for IP at such companies understand the BSD and GPL. When presented with a new and unique agreement such as the SCA or MCA, they must evaluate the agreement. That takes time and money. But Monty Program accepts code under MCA or BSD, so this isn't an issue for me. -- Mark Callaghan mdcallag@gmail.com

Michael Widenius

9:24 p.m.

Hi!

...

...
...
...
...
"MARK" == MARK CALLAGHAN writes:

MARK> On Tue, Oct 6, 2009 at 4:15 PM, Arjen Lentz wrote:

...

...
Hi Monty, Henrik

On 07/10/2009, at 12:34 AM, Michael Widenius wrote:

...
I still think it's quite long and not much easier to understand that what we have now:

"Monty Program Ab agrees that when it dual licenses code, it will not restrict the way the third party licensee uses the licensed copy of the code nor restrict how they use their own code. "

In that case you might as well just keep it all GPL or BSD and sell it rather than dual licensing? Then the recipient has all the normal GPL or BSD rights and obligations that apply to the rest of the code anyway, without need for extra licensing texts.

Dual would only make sense for discrete/distinct components, but even there it might be easier to just have it be GPL or BSD. People come back to the original company for expertise/customisation anyway, as they're the experts. As long as the service is good. There's also no incentive to like republish stuff, as that wouldn't be the core business of the client company. They wouldn't have interest in that.

MARK> It is easier to contribute code using BSD/GPL than MCA/SCA when MARK> working at a large company. People responsible for IP at such MARK> companies understand the BSD and GPL. When presented with a new and MARK> unique agreement such as the SCA or MCA, they must evaluate the MARK> agreement. That takes time and money. MARK> But Monty Program accepts code under MCA or BSD, so this isn't an issue for me. Yes, it shouldn't be a problem for you. However, the above promise is still relevant for you, as it gives you information of how we are going to work with the code you donate. It would be nice if Sun also could work with BSD, but we have learned the hard way that they don't accept code under the BSD license :( Anyway, we come up with a workaround to safely be able to donate code to Sun, so now we can finally start to submit them some bug fixes. Regards, Monty

Arjen Lentz

11:33 p.m.

Hi Monty, all On 08/10/2009, at 5:24 AM, Michael Widenius wrote:

...

It would be nice if Sun also could work with BSD, but we have learned the hard way that they don't accept code under the BSD license :(

You mean Sun/MySQL then, because for Drizzle, Sun does work with BSD code. That's actually a nuisance to me since it allows them to dual-license Drizzle, which I reckon is a really bad idea - best if that were not possible.

...

Anyway, we come up with a workaround to safely be able to donate code to Sun, so now we can finally start to submit them some bug fixes.

Seems to me like they're sidelining themselves. Cheers, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget. Follow our blog at http://openquery.com/blog/ OurDelta: enhanced builds for MySQL @ http://ourdelta.org

Michael Widenius

8 Oct 8 Oct

10:52 a.m.

Hi!

...

...
...
...
...
"Arjen" == Arjen Lentz writes:

Arjen> Hi Monty, all Arjen> On 08/10/2009, at 5:24 AM, Michael Widenius wrote:

...

...
It would be nice if Sun also could work with BSD, but we have learned the hard way that they don't accept code under the BSD license :(

Arjen> You mean Sun/MySQL then, because for Drizzle, Sun does work with BSD Arjen> code. Arjen> That's actually a nuisance to me since it allows them to dual-license Arjen> Drizzle, which I reckon is a really bad idea - best if that were not Arjen> possible. As far as I know, they have also accepted code under the GPL to Drizzle, so that makes it impossible to dual license. Anyway, I disagree strongly that it would be in any way bad for anyone to do dual-licensing of GPL code; Dual licensing gives the users more freedom, not less; It allows people that could not otherwise work with the code (because of restrictions in their code base) to still get access to the code under terms that can accept. Anyway, I think we two should stop the discussion about Dual licensing as we are clearly off different opinions of the importance of it for the future. It's of course all right to be of different opinions, but I don't think it brings value to this email list if we continue to discuss it here; It's better to continue the discussion in person next time we meet. Regards, Monty

Arjen Lentz

12:02 p.m.

Hi Monty On 08/10/2009, at 6:52 PM, Michael Widenius wrote:

...

Arjen> On 08/10/2009, at 5:24 AM, Michael Widenius wrote:

...
...
It would be nice if Sun also could work with BSD, but we have learned the hard way that they don't accept code under the BSD license :(

Arjen> You mean Sun/MySQL then, because for Drizzle, Sun does work with BSD Arjen> code.

Arjen> That's actually a nuisance to me since it allows them to dual- license Arjen> Drizzle, which I reckon is a really bad idea - best if that were not Arjen> possible.

As far as I know, they have also accepted code under the GPL to Drizzle, so that makes it impossible to dual license.

Yea but is that code also copyright-assigned, or not? If it's also copyright-assigned, the dual licensing still flies for Sun.

...

Anyway, I disagree strongly that it would be in any way bad for anyone to do dual-licensing of GPL code; Dual licensing gives the users more freedom, not less; It allows people that could not otherwise work with the code (because of restrictions in their code base) to still get access to the code under terms that can accept.

Anyway, I think we two should stop the discussion about Dual licensing as we are clearly off different opinions of the importance of it for the future. It's of course all right to be of different opinions, but I don't think it brings value to this email list if we continue to discuss it here; It's better to continue the discussion in person next time we meet.

Ack - perhaps add cough medicin. I will say though that the 10x vs 2x revenue argument holds no weight for me personally: to me, something that makes more profit is not intrinsically better (nor is a company that makes more money by definition more successful in my eyes). My criteria for better and successful are viewed from the client and community perspective. I want to see clients pay what *they* perceive as a fair price for a result they like, and talk well of the product and its vendor. Cheers, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget. Follow our blog at http://openquery.com/blog/ OurDelta: enhanced builds for MySQL @ http://ourdelta.org

Henrik Ingo

7 Oct 7 Oct

9:26 a.m.

On Wed, Oct 7, 2009 at 2:15 AM, Arjen Lentz wrote:

...

On 07/10/2009, at 12:34 AM, Michael Widenius wrote:

...
I still think it's quite long and not much easier to understand that what we have now:

In that case you might as well just keep it all GPL or BSD and sell it rather than dual licensing?

MariaDB is GPL and we can't do dual licensing in that sense.

...

Then the recipient has all the normal GPL or BSD rights and obligations that apply to the rest of the code anyway, without need for extra licensing texts.

Actually, the text being discussed here imposes no requirements on the contributor, it is something that Monty Program gives away. The fact that nobody (and I do mean nobody, it's not about you) except me has understood what Monty wants to do, indicates that the text is not clear.

...

Dual would only make sense for discrete/distinct components, but even there it might be easier to just have it be GPL or BSD. People come back to the original company for expertise/customisation anyway, as they're the experts. As long as the service is good.

Pooling copyrights is not primarily done to have any benefit for MP, it is done so we could potentially give code back to Sun (to benefit MySQL customers, and Sun of course) or to make sure we can stay license compatible with MySQL (to benefit MariaDB and its users). And yes, this is something we must do, so there is no point in discussing the pooling of copyrights as such. Just to repeat what Mark said, contributing as BSD seems to be the most popular way, and MP has no problem with that. henrik -- email: henrik.ingo@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc

Michael Widenius

8 Oct 8 Oct

12:48 a.m.

Hi!

...

...
...
...
...
"Arjen" == Arjen Lentz writes:

Arjen> Hi Monty, Henrik Arjen> On 07/10/2009, at 12:34 AM, Michael Widenius wrote:

...

...
I still think it's quite long and not much easier to understand that what we have now:

"Monty Program Ab agrees that when it dual licenses code, it will not restrict the way the third party licensee uses the licensed copy of the code nor restrict how they use their own code. "

Arjen> In that case you might as well just keep it all GPL or BSD and sell it Arjen> rather than dual licensing? Arjen> Then the recipient has all the normal GPL or BSD rights and Arjen> obligations that apply to the rest of the code anyway, without need Arjen> for extra licensing texts. The above is for the case when we dual license some code (not MariaDB) and give them a commercial-only version of the code. The intent is that in the commercial-only version, we will not put any unreasonable limitations on how the customer can use the licensed code (which may include donated code). The background can be found in for example my blog about the current MySQL OEM licenses, which I know a lot of customers finds totally unacceptable. Arjen> Dual would only make sense for discrete/distinct components, but even Arjen> there it might be easier to just have it be GPL or BSD. This is for the case where the customer does not want to have the code under GPL. BSD is not an option as then they could release the code and we would not have any dual-license revenue anymore. Arjen> People come back to the original company for expertise/customisation Arjen> anyway, as they're the experts. As long as the service is good. Arjen> There's also no incentive to like republish stuff, as that wouldn't be Arjen> the core business of the client company. They wouldn't have interest Arjen> in that. If you are successful, there is always someone who will take advantage of you... Look for example at MySQL; If they would license their GPL code as BSD, they would at once loose all their licensing business. Regards, Monty

Arjen Lentz

1:08 a.m.

Hi Monty On 08/10/2009, at 8:48 AM, Michael Widenius wrote:

...

Arjen> Dual would only make sense for discrete/distinct components, but even Arjen> there it might be easier to just have it be GPL or BSD.

This is for the case where the customer does not want to have the code under GPL. BSD is not an option as then they could release the code and we would not have any dual-license revenue anymore.

I regard the traditional dual licensing (in this context) as a non- viable revenue model. If it's custom code, have user pay for it and license code as GPL or BSD. If it's BSD, they can also use it in commercial - you could charge extra for making it BSD rather than GPL, for instance.

...

Arjen> People come back to the original company for expertise/ customisation Arjen> anyway, as they're the experts. As long as the service is good. Arjen> There's also no incentive to like republish stuff, as that wouldn't be Arjen> the core business of the client company. They wouldn't have interest Arjen> in that.

If you are successful, there is always someone who will take advantage of you...

Some will, so be it. They'd have to be a customer first to do this (with the above example) and you wouldn't keep them as a customer anyway, so there's no real loss. In general, people will act properly - particularly if the environment is *perceived* as fair to them.

...

Look for example at MySQL; If they would license their GPL code as BSD, they would at once loose all their licensing business.

Good. I wish Sun/MySQL all the best and success, and for their own good their old licensing has to cease. It is still causing a lot of bad publicity. It also rips off users/clients, because unscrupulus Sun/MySQL sales people selling licenses where none are required. By stopping it, this would make a clear statement that Sun does not support that kind of behaviour. It's no longer part of a legitimate business model, it's turned out as a devious scam. Furthermore, people *perceive* it as a scam, and thus it's not interesting for you or I to be doing something similar. "Dual Licensing" in the sphere of MySQL is a no-winner. Just drop it and lead by example. Cheers, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget. Follow our blog at http://openquery.com/blog/ OurDelta: enhanced builds for MySQL @ http://ourdelta.org

Michael Widenius

10:47 a.m.

Hi!

...

...
...
...
...
"Arjen" == Arjen Lentz writes:

Arjen> Hi Monty Arjen> On 08/10/2009, at 8:48 AM, Michael Widenius wrote: Arjen> Dual would only make sense for discrete/distinct components,

...

...
but even Arjen> there it might be easier to just have it be GPL or BSD.

This is for the case where the customer does not want to have the code under GPL. BSD is not an option as then they could release the code and we would not have any dual-license revenue anymore.

Arjen> I regard the traditional dual licensing (in this context) as a non- Arjen> viable revenue model. There is where we disagree :) It's a very viable revenue model for many companies, including Monty Program Ab; Just because we can't do it for MariaDB itself, doesn't mean that we can't do it for other things in the future. The promise is also relevant for other GPL vendors that are doing dual licensing and who wants to signal to their users, contributors and customers how they are going to relicense the code. Arjen> If it's custom code, have user pay for it and license code as GPL or Arjen> BSD. Arjen> If it's BSD, they can also use it in commercial - you could charge Arjen> extra for making it BSD rather than GPL, for instance. That is not a working business model. For a software company that wants to be highly successful (and get a high valuation), you need license revenues to be able to do that. You can't get that by relicensing GPL code as BSD. (Not that I am not talking about MariaDB here say, but more about principles) Arjen> People come back to the original company for expertise/

...

...
customisation Arjen> anyway, as they're the experts. As long as the service is good. Arjen> There's also no incentive to like republish stuff, as that wouldn't be Arjen> the core business of the client company. They wouldn't have interest Arjen> in that.

What you are talking is about a company that is working in the service sector, not a company that makes a living doing software and gets valuated based on it having license revenues. The valuation for a service company is about 2x times the revenue while a software company with license revenue is valued 10x times the revenue.

...

...
If you are successful, there is always someone who will take advantage of you...

Arjen> Some will, so be it. Arjen> They'd have to be a customer first to do this (with the above example) Arjen> and you wouldn't keep them as a customer anyway, so there's no real Arjen> loss. Yes, there is a real loss as you have lost your IP and thus lost your main revenue stream. Arjen> In general, people will act properly - particularly if the environment Arjen> is *perceived* as fair to them. This doesn't apply for someone that is creating a software business with the intention to some day sell it and make a nice profit.

...

...
Look for example at MySQL; If they would license their GPL code as BSD, they would at once loose all their licensing business.

Arjen> Good. I wish Sun/MySQL all the best and success, and for their own Arjen> good their old licensing has to cease. Arjen> It is still causing a lot of bad publicity. This has nothing to do with GPL or getting profit by selling licenses under a dual license scheme. It's a well established and even respected business when working with Open Source software. Arjen> It also rips off users/clients, because unscrupulus Sun/MySQL sales Arjen> people selling licenses where none are required. Agree that this is a problem and something a respectable company should not do. It's exactly because I wanted to make a stand against some of the Sun practices in selling licenses that I added the clarification of how I see that Monty Program Ab will work with code that is donated to the MariaDB project.a Arjen> By stopping it, this would make a clear statement that Sun does not Arjen> support that kind of behaviour. You mean stop trying to sell things under a false pretences? I agree with that. Arjen> It's no longer part of a legitimate business model, it's turned out as Arjen> a devious scam. I disagree with that. The fact that some people are doing things wrong, doesn't mean that the business model is wrong. It would be the same thing as saying that you should not sell used cars, because some used cars sells persons has a poor reputation. Arjen> Furthermore, people *perceive* it as a scam, and thus it's not Arjen> interesting for you or I to be doing something similar. Arjen> "Dual Licensing" in the sphere of MySQL is a no-winner. Just drop it Arjen> and lead by example. I lead by example by making the rules more clear. Dual Licensing is still one of the best way to make money in the Open Source space (and in many cases the ONLY WAY you can make enough money to create a workable business), so there is no need to go away from it. Regards, Monty

5406

Age (days ago)

5429

Last active (days ago)

List overview

Download

17 comments

5 participants

participants (5)

Arjen Lentz
Henrik Ingo
MARK CALLAGHAN
Michael Widenius
Oleksandr Byelkin

[Maria-discuss] Additional promise to the MCA

tags

participants (5)