Re: [xmlvm-users] Clarifications on the Linking Exception

[Panayotis K. <pan...@pa...>]

Due to the length of this reply, let me leave out some not so  
"significant" parts.


On 17 Μαρ 2010, at 3:22 ΜΜ, Arno Puder wrote:
> If you build a product for a client, the client pays you for that
> service but they are *not* using XMLVM. So, they do not need to apply
> for a linking exception.


I really like the way you expressed it now.

So, practically that's my original question: a client comes and asks  
me to write an application for them (and that's a real scenario).
I write the application, I compile it and I upload it to app store.
With this new aspect, there is no need for the client to purchase  
XMLVM, right?

If of course they want the complete source code and they want to make  
changes to it and submit them to the app store, *then* they need the  
license. In any other case they don't.
That's my interpretation of what you say.
Is it correct?

I think a model like this is more practical, useful and has a real  
meaning than the previous answer "Either you or the company are the  
recipient of the linking exception, but not both of you."


>> 4. The current license strategy encourages minimal contributions
>> With this 6  month time limit, contributors are not encouraged to
>> contribute as much as they can. Instead they are encouraged to
>> contribute the "minimal amount necessary", and then to contribute a
>> small amount again, when their linking exception runs out. Even if  
>> they
>> are required to release all their changes under the GPL (see next
>> point), these code dumps cannot be used in XMLVM, because they were  
>> not
>> contributed to the project.
>>
>> I think this hurts the XMLVM project as a whole, including the Core  
>> Team
>> and any current and potential contributors.
>
> I should not have mentioned the 6 months. As I already pointed out  
> in my
> original post, patches come in very different quality. This will be
> reflected in the time period. You indicated several times that you are
> sitting on a monster patch. Of course that will be acknowledged very
> differently than someone adding a few lines of code to XMLVM.

I couldn't agree more with Gergely.

You can not really weight "early" or "heavy" patches, since they  
exponentially help the project to evolve and/or to explode.

The reason we are talking for the iPhone compatibility library is just  
because there is already some work on it. If a newcomer comes and see  
that no library is present, they will not bother at all.
If on the contrary they see that the library is there, they will have  
a go, and probably make some contributions back.
So a small patch "early" could be in the long run more important than  
a big patch "later on".

Moreover, Gergely is right. I have already a monster patch pending  
(just like I had a similar monster patch a couple of months ago). By  
defining any time period this is a kill for me. My will is to send it  
right now, and intergrade it as is (like in the past). I could cut it  
in pieces of course and send a piece every 6 months, but I don't like  
that.
By defining any type of fixed time-point, you discourage me (and  
probably all others) to send really serious patches.

And it is not only that. Since now it is still "early" (and that's why  
I could still create patches like this), as I said before, this will  
help the exponential grow of XMLVM. I wish this project to succeed and  
I understand that you want to *protect* yourselves from companies who  
would say "have a 10-line patch and grand me lifetime linking  
exemption".

But on the other hand, I believe that us, the early adopters and  
helpers, should not be constrained by any time period, since we are  
helping *you* make (and sell) this great tool. Or else the community  
(which means us) I think they'll be discouraged and the growth of  
XMLVM will be as slow as you (the core team) can write code.


>> 6. Very asymmetric relationship between the Core Team and the  
>> contributors
>>

...

>> By the time XMLVM becomes mature, the current contributors will  
>> have no
>> valid linking exceptions, so they will need to buy a commercial
>> license...for something that they in part (and it is a significant  
>> part,
>> because they received a linking exception for it) created.
>> And there is no say how much will a commercial license cost then. We
>> don't know who will be in control of the project.
>>
>
> You have invested weeks, perhaps months into the development in XMLVM.
> We have invested years (I personally since 2002). There is no  
> asymmetry
> between the core team and contributors. We cannot sell XMLVM because  
> you
> still have the copyright of your work. With the linking exception you
> can do the same as we do: offer services to your clients. Again: the
> length of the linking exception will reflect the value of your
> contribution, but that will be done in context with what everyone else
> has contributed.

That's exactly my point, couldn't be expressed more clearly: "By the  
time XMLVM becomes mature, the current contributors will have no valid  
linking exceptions".

Of course you have invested (and you will invest) more time than us to  
create this project, but don't forget that *you* own the project,  and  
more importantly you are able to give it as a product any way you like.

We can't.

To say the truth, although I totally understand your point of view and  
your will to stay with a GPL-ed compatibility library (since this is  
the only way I know to force anybody to pay for it), I don't feel  
comfortable with it. Of course the compiler and all other tools could  
be with any license you like. But I still feel "jailed" with a GPL  
library without a linking exception by default (or a LGPL or an Apache  
license or whatever) .

And this makes me reluctant on sending patches and improvements for  
this library, except if I really *have* to.

I have to remind you that, if the "fun" goes away from this project, I  
(or should I say "we") will go back and code in Objective C again, or  
get a linking exemption now, make my own fork and go on from this time  
point. My strongest motivation though is that it happens to me to like  
this project and I am willing to help this project succeed.