xmlvm-users

[xmlvm-users] Clarifications on the Linking Exception

[Arno P. <ar...@pu...>]

Guys,

there have been some questions regarding our licensing model. I would 
like to take this opportunity to express our (i.e., the XMLVM Core Team) 
intent. Before I go into details, I want to point out that our goal is 
to create a fair model that serves both the XMLVM Core Team as well as 
contributors. We acknowledge that some of you are interested in using 
XMLVM for commercial purposes. We ask you to acknowledge that we have 
legitimate business interests as well. The goal is to find a balance 
that works for all of us. XMLVM is and always will be Open Source. We 
use the GPL license and as many of you know, this license is very 
restrictive. The GPL license requires you to put your own source code 
under the GPL license. If you are just doing Open Source work, this is 
usually fine, however, if you want to develop commercial applications, 
this is not acceptable for obvious reasons. That is where the idea of 
dual licensing kicks in. We offer a second, commercial license, that 
will allow you to develop proprietary products based on XMLVM. Note that 
the idea of dual licensing is not new. Projects such as MySQL and JBoss 
have been doing this for a long time.

Our commercial license is a non-transferrable GPL Linking Exception (or 
just linking exception for short) that takes away the 'viral' component 
of the GPL. This means, if we grant you a linking exception, you are 
*not* required to release your own application that is based on XMLVM to 
the Open Source. This linking exception is not transferrable. You cannot 
transfer this right to your customers.

What is somewhat new with XMLVM is that we still want XMLVM to be a 
community project. That means, we hope and encourage the community to 
make contributions to XMLVM. It is important to us that we do not leave 
the perception of exploiting contributors via our commercial license. 
For that reason we have come up with a way to 'reward' outside 
contributors: If you make a (non-trivial) contribution to XMLVM, we will 
give you a commercial license (i.e., non-transferrable linking 
exception) that will allow you to develop a commercial application with 
XMLVM without sharing your proceeds with us.

Of course there are some details that need to be clarified and there 
have been some questions on the mailing list regarding the details. Let 
us make a specific example: you send us a patch to XMLVM that is 
non-trivial (lets not get into the discussion on what is a non-trivial 
contribution. There is obviously no objective way of measuring the 
quality of a contribution. We will make that call on a case-by-case 
basis). If we (the XMLVM Core Team) agrees to merge your patch with the 
code base of XMLVM, we will give you a non-transferrable linking 
exception in return. In terms of the scope of this non-transferrable 
linking exception, there are several components: (1) to which version of 
XMLVM does the linking exception apply? (2) who is the recipient of the 
linking exception? (3) what is the duration of the linking exception? 
Let me address these issues individually.

(1) we do not maintain an official versioning scheme for XMLVM. Things 
happen so fast in our code base that we do not plan to introduce 
official version numbers. In the future we might change this, but for 
now, we simply refer to the Subversion revision numbers. The linking 
exception is issued for the version of XMLVM that includes the 
contributors patch and any version of XMLVM released in the following 6 
months. For really significant contributions we are willing to extend 
that time frame.

(2) the linking exception is issued to the contributor of the patch. 
This can be an individual or the company for which the contributor 
works. This will allow the individual/company to develop applications 
that can be sold to their customers without having to share revenues 
with the XMLVM Core Team. The linking exception *cannot* be transferred 
to the customers of the contributor.

(3) for the versions of XMLVM for which we issue the linking exception, 
the usage is not limited to the aforementioned 6 months. I.e., 6 months 
after you made your contribution you may still use older versions of 
XMLVM for commercial purposes. Only if you want to benefit from new 
features introduced to XMLVM after those 6 months, you will need to make 
another contribution to XMLVM to extend the duration of the linking 
exception.

I would like to start a discussion with you guys on the mailing list to 
refine these rules. Again, we want to strike a balance between your 
legitimate commercial interest and ours.

Let me know what you think.

Arno

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

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

>
> (3) for the versions of XMLVM for which we issue the linking  
> exception,
> the usage is not limited to the aforementioned 6 months. I.e., 6  
> months
> after you made your contribution you may still use older versions of
> XMLVM for commercial purposes. Only if you want to benefit from new
> features introduced to XMLVM after those 6 months, you will need to  
> make
> another contribution to XMLVM to extend the duration of the linking
> exception.


I'll comment at first this part, how long this exception will be.

I don't believe this is fair enough.
I believe it is fair, if this exception will last as long as the patch  
will last.
If you continue to use a specific patch (or in other terms, this patch  
is useful to you), then I believe you should grand the linking  
exception to the person who sent a patch (or in other words, you  
should be useful to him). Moreover I think 6 months is a very limited  
time period. Usually licenses last (at least) a year.

And still, I have this question, which I posted in a previous post of  
mine:
for example today I work in a company and I send a patch. In (let's  
say) a month I go to another company. Can I still develop with xmlvm  
or should I do something else (like making them to pay or send another  
patch or whatever) ?

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

[Arno P. <ar...@pu...>]

On 3/16/10 6:54 PM, Panayotis Katsaloulis wrote:
> I don't believe this is fair enough.
> I believe it is fair, if this exception will last as long as the patch
> will last.
> If you continue to use a specific patch (or in other terms, this patch
> is useful to you), then I believe you should grand the linking exception
> to the person who sent a patch (or in other words, you should be useful
> to him). Moreover I think 6 months is a very limited time period.
> Usually licenses last (at least) a year.

Once a patch is applied, it is usually never removed anymore. We see a 
patch as a contribution that gives you access to a certain number of 
updates. But that does not mean that you get unlimited updates. The same 
is true for any software license that you purchase. I mentioned 6 months 
in my mail. That is just a ballpark figure. Patches that come in are of 
very different quality and scope. I think it is fair to discuss the 
length of the period based on an individual contribution. And as I 
already indicated, if the contribution is significant, we are of course 
willing to extend the time period.

> And still, I have this question, which I posted in a previous post of mine:
> for example today I work in a company and I send a patch. In (let's say)
> a month I go to another company. Can I still develop with xmlvm or
> should I do something else (like making them to pay or send another
> patch or whatever) ?

Either you or the company are the recipient of the linking exception, 
but not both of you. If the company is the recipient and you leave the 
company, then you cannot do commercial products based on XMLVM anymore. 
If you are the recipient, you can build products which the company (or 
anyone else) may use (after paying you). But in that case the company 
has no right to build applications with XMLVM.

Arno

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

[Gergely K. <ger...@ma...>]

Hi,

Thank you for sharing / clarifying your licensing strategy with us.

We at MattaKis Consulting have been working on improving XMLVM in order to
enable us using it in real projects. We have already contributed a pretty
large set of patches, and more patches are in the works internally.

Unfortunately, we have some major concerns with the current licensing
strategy.

1. The current state (maturity) of XMLVM
Although XMLVM is improving rapidly (thanks to both the core team and also
to the dedicated external contributors), it is not a mature product yet. The
Core Team seems to acknowledge this in the licensing strategy by not
specifying a release cycle, instead of using exclusively a time based model.

Realistically, if you want to use XMLVM currently for anything serious, you
will have to "pop the hood", and start developing into the runtime library
the missing parts that you are using. My optimistic estimate is that it will
take at least 1.5 - 2 years for this situation to change, when you can take
a non-trivial Java/Android program, and it will output a reasonably well
working Objective-C/Iphone version.

However, the current licensing proposal means that those who make the
essential contributions now (like implementing java_lang_String methods ...
etc.) that led to the mature XMLVM will be in the same position as any
newcomer. Their linking exceptions will have long run out by then. The
problem is, that this asymmetry is not solved by simply extending the length
of the linking exception.

2. Unclear legal status of the project
When we are signing the CLA, we are signing the rights to "XMLVM". This
issue has been brought up last year on this list. Right now it is not clear,
who is XMLVM? Is there a commercial entity? Is it the 3 Core Team members?
Who will "own" the code, that is contributed? Who will grant the commercial
licenses?
The core team members work at large software companies / US universities.
It is not clear if these entities have any legal basis of "taking XMLVM",
and saying that the previous "linking exceptions" are invalid, and starts to
sue the users of XMLVM. This all depends on the work contracts of the core
team members, and also the relevant US and EU laws.

I know that this seems like a slim chance right now, but stranger things
have happened, especially when there is money involved.

3. Absence of a real commercial license
Since the linking exception is non-transferrable, essentially, our clients
will have to somehow obtain a commercial license (In many cases you also
have to deliver the source code and all necessary tools to your clients.) It
is not realistic, that each of those clients will be able to do a
contribution. Also, as the project matures, it will be harder and harder to
contribute something that is valuable enough for a linking exception. It is
also "funny": You take a future, mature XMLVM version, it works flawlessly
for your project, but then you have to go and implement something completely
irrelevant to your project, just to get a linking exception.

This was also brought up earlier, and then the Core Team mentioned something
about 2-300 USD for a linking exception license, but the specific details
were never really worked out.

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.

5. It is still not clear what the linking exception will allow and what not
I was actually pretty surprised when in a later email Arno wrote, that even
if you have the linking exception, you have to release any changes you make
in XMLVM under the GPL. Clearly, the Core Team has a very different notion
of what the linking exception allows, than us (MattaKis Consulting), and
this gets us back to the "Unclear legal status" and the "Absence of
commercial license" points.

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

The contributors have to grant all rights to the XMLVM project, more
specifically the Core Team. This means that the Core Team is free to change
the license of the project, sell the project to the highest bidder ... etc.

At the same time, the contributors get only a limited time non-transferrable
"license exception".

This is already an issue now (judging from the many questions regarding
transferrability ... etc.),  but in 1 - 2 years, when XMLVM will be a mature
project, and will worth much more than currently, it will be a huge issue.

The current contributors are adding significant value to the project, and
that value will still be used then. It is unrealistic that the essential
runtime features that we are working on now are going to be thrown out: you
cannot do it too much differently. The contributors are doing everything
from alpha- and beta-testing, to adding essential features and to
participating in design discussions here on the mailing list which form the
direction of XMLVM significantly.

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.

My proposal:
XMLVM has 2 major components for each source -> target permutation:
1. The compiler, which takes the input and generate the output for the
target
2. The runtime library which implements the API for the platform to make the
compiled code usable.

>From what I have seen in the last months, the compiler itself is mostly
worked on by the core team. We, the contributors, only touch it, when we
have to fix a bug, or we need to put in a missing part for a feature of the
runtime library.

On the other hand, the runtime library has already received significant
external contributions, and it is my estimate that this will only increase
in the future.

Now we have two components that cannot be used without the other.
My suggestion is to:

- Make the license of the runtime library (Java & Iphone API) more liberal,
since it is written in a significant part by external contributors.

- Keep the current dual licensing scheme for the compiler. As far as I know
the code generated by the compiler is still GPL - so you need a commercial
license for using it in commercial project. I am not a lawyer -- if this is
not the case, then you might consider changing the compiler license
accordingly.

- When someone contributes to the library, you at your own discretion may or
may not grant commercial license to the compiler. This way you sponsor the
development of the libraries without actually using hard cash.

- For those who cannot contribute for any reason, please offer a commercial
license for a fee. (I am deliberatly not using the "linking exception",
because I think it has become a way too ambiguous term.)

- If someone contributes directly to the compiler, then the Core Team (or
better yet, the commercial entity behind the project) would agree with them
on a reasonable compensation (this can be also a specified number of
commercial licenses, or later money). Of course it should be well documented
how to negotiate (who to contact...etc.) such agreements ... etc.

The advantage of this proposal is that it clearly separates the community
developed parts, and the commercial parts of the project, while still taking
the commercial interests of all parties into consideration.

What do you think about all this?

Best Regards,
Gergely

2010/3/16 Arno Puder <ar...@pu...>
[...]


-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622

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

[Arno P. <ar...@pu...>]

Gergely,

thanks for your feedback. Let me address each of your issues one-by-one. 
A lot to read but please pay special attention to the end of the mail.

> 1. The current state (maturity) of XMLVM
> Although XMLVM is improving rapidly (thanks to both the core team and
> also to the dedicated external contributors), it is not a mature product
> yet. The Core Team seems to acknowledge this in the licensing strategy
> by not specifying a release cycle, instead of using exclusively a time
> based model.
>
> Realistically, if you want to use XMLVM currently for anything serious,
> you will have to "pop the hood", and start developing into the runtime
> library the missing parts that you are using. My optimistic estimate is
> that it will take at least 1.5 - 2 years for this situation to change,
> when you can take a non-trivial Java/Android program, and it will output
> a reasonably well working Objective-C/Iphone version.
>
> However, the current licensing proposal means that those who make the
> essential contributions now (like implementing java_lang_String methods
> ... etc.) that led to the mature XMLVM will be in the same position as
> any newcomer. Their linking exceptions will have long run out by then.
> The problem is, that this asymmetry is not solved by simply extending
> the length of the linking exception.

Of course there is still a lot of work that needs to be done in XMLVM. 
However, I disagree with you that it will take 1.5 - 2 years for XMLVM 
to become usable. We are currently wrapping up a project for a customer 
where we use XMLVM. Even when all the Android API is covered (which may 
take the 1-2 years you mentioned), there are still many other things 
that can be done. We are currently thinking of implementing the Java 
Debugging Protocol inside the Apple Emulator. We are also considering to 
allow hybrid applications where you can use an Android layout manager to 
lay out an iPhone widget. Innovation will never stop. Even right now 
XMLVM is usable for certain applications and a "newcomer" can benefit 
right now from the work that has gone into XMLVM since 2002 (the 
founding year of XMLVM).


>
> 2. Unclear legal status of the project
> When we are signing the CLA, we are signing the rights to "XMLVM". This
> issue has been brought up last year on this list. Right now it is not
> clear, who is XMLVM? Is there a commercial entity? Is it the 3 Core Team
> members? Who will "own" the code, that is contributed? Who will grant
> the commercial licenses?
> The core team members work at large software companies / US universities.
> It is not clear if these entities have any legal basis of "taking
> XMLVM", and saying that the previous "linking exceptions" are invalid,
> and starts to sue the users of XMLVM. This all depends on the work
> contracts of the core team members, and also the relevant US and EU laws.
>
> I know that this seems like a slim chance right now, but stranger things
> have happened, especially when there is money involved.

By signing the CLA electronically, you only give us the right to use 
your patch. You still retain the copyright of your work. It is correct 
that XMLVM is not a legal entity and when I refer to XMLVM, I mean the 
core team. Would it help you if XMLVM incorporated in California? If I 
remember correctly, you are located in Eastern Europe. We cannot create 
companies all over the world to accommodate each national law.

A developer on SourceForge must choose an Open Source license. The 
license spells out the rules, without the developer having to register a 
company. In that sense we do the same, except that we add the linking 
exception in return for a contribution (which, btw, is also not a new 
idea. Look on Wikipedia). Its a cheap man's commercial license, but I'd 
rather do that than charge $50.000 for a proper commercial license so we 
can pay the legal bills.

> 3. Absence of a real commercial license
> Since the linking exception is non-transferrable, essentially, our
> clients will have to somehow obtain a commercial license (In many cases
> you also have to deliver the source code and all necessary tools to your
> clients.) It is not realistic, that each of those clients will be able
> to do a contribution. Also, as the project matures, it will be harder
> and harder to contribute something that is valuable enough for a linking
> exception. It is also "funny": You take a future, mature XMLVM version,
> it works flawlessly for your project, but then you have to go and
> implement something completely irrelevant to your project, just to get a
> linking exception.
>
> This was also brought up earlier, and then the Core Team mentioned
> something about 2-300 USD for a linking exception license, but the
> specific details were never really worked out.

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 acknowledge that some clients require you to 
deliver source code of your work and the ability to re-compile the 
application (which means that they need XMLVM). If you use a commercial 
tool to build the application for your client (lets say, a modeling 
tool), your client will also need to buy a commercial license for this 
modeling tool if they want to re-compile the application themselves, right?

> 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.

> 5. It is still not clear what the linking exception will allow and what not
> I was actually pretty surprised when in a later email Arno wrote, that
> even if you have the linking exception, you have to release any changes
> you make in XMLVM under the GPL. Clearly, the Core Team has a very
> different notion of what the linking exception allows, than us (MattaKis
> Consulting), and this gets us back to the "Unclear legal status" and the
> "Absence of commercial license" points.

I do think this is very clear. XMLVM is under GPL license and the 
linking exception takes away the viral component so that you do not have 
to Open Source your own proprietary app. Otherwise the GPL still applies 
to XMLVM and therefore any further modifications you do to XMLVM need to 
be made available.

> 6. Very asymmetric relationship between the Core Team and the contributors
>
> The contributors have to grant all rights to the XMLVM project, more
> specifically the Core Team. This means that the Core Team is free to
> change the license of the project, sell the project to the highest
> bidder ... etc.
>
> At the same time, the contributors get only a limited time
> non-transferrable "license exception".
>
> This is already an issue now (judging from the many questions regarding
> transferrability ... etc.),  but in 1 - 2 years, when XMLVM will be a
> mature project, and will worth much more than currently, it will be a
> huge issue.
>
> The current contributors are adding significant value to the project,
> and that value will still be used then. It is unrealistic that the
> essential runtime features that we are working on now are going to be
> thrown out: you cannot do it too much differently. The contributors are
> doing everything from alpha- and beta-testing, to adding essential
> features and to participating in design discussions here on the mailing
> list which form the direction of XMLVM significantly.
>
> 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.


> My proposal:

[...]

> - Keep the current dual licensing scheme for the compiler. As far as I
> know the code generated by the compiler is still GPL - so you need a
> commercial license for using it in commercial project. I am not a lawyer
> -- if this is not the case, then you might consider changing the
> compiler license accordingly.

no. this is not correct. Look at gcc. gcc is GPLed and you can use it 
for commercial applications. The only way to do dual licensing is by 
having a restrictive license on the libraries.

BOTTOM LINE:

I think what this whole thing boils down to is that you feel that your 
contribution is not valued enough. I do believe that we can address this 
with the length of the linking exception (I really don't want to spend 
big bucks on a lawyer to come up with a commercial license which 
probably will be more restrictive and also most likely would require you 
to transfer copyright). Forget the 6 months, ok? Show us what you've got 
and I'm sure we'll grant you a significantly longer time period. 
Remember that XMLVM is more than just code. There is also a certain 
skill set and credibility you gain by participating early on and I'm 
sure you will be able to leverage that.

Arno

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.

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

[Arno P. <ar...@pu...>]

On 3/17/10 7:06 AM, Panayotis Katsaloulis wrote:
> 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?

Yes.

> 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.

I guess I really did a lot of harm with mentioning the 6 months. As I 
mentioned numerous times now, the length of the linking exception will 
depend on the significance of your contribution. If I understand you 
correctly with what you've written in the remainder of your message, 
some contributions warrant an unlimited linking exception. Is that what 
you have in mind? Would that solve your headaches?

Arno

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

[Sascha H. <sa...@xm...>]

I would like add on top of what Arno said, that the 6 months is really
nothing we decided on inside the core team. And I agree, with you Gergely
and Panayotis, that any fixed time period would harm XMLVM as contributors
might delay submitting patches this way in order to get another 6 months.
So, forget about 6 months :)

I think, for people that continuously help the project, like the two of you
did and hopefully will do, there should be an ever-expanding time period and
you shouldn't have to wait until the current one expires. Example: You
submit a patch and we agree on a linking exception for XX months. After a
week you have another patch of the same size. Then I think it is reasonable
to add XX months to the expiration date. Is that something that makes sense?

Also, if you say you have a monster patch, and let's assume we choose to
accept it in the project, then this time period could really be extremely
long so that it essentially goes to infinity for practical purposes.

But I think you agree, that somebody who contributes a lot less, should be
limited in the use of the linking exception, but should still benefit from
it, but for a shorter period of time.

// Sascha

On Wed, Mar 17, 2010 at 3:29 PM, Arno Puder <ar...@pu...> wrote:

>
>
> On 3/17/10 7:06 AM, Panayotis Katsaloulis wrote:
> > 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?
>
> Yes.
>
> > 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.
>
> I guess I really did a lot of harm with mentioning the 6 months. As I
> mentioned numerous times now, the length of the linking exception will
> depend on the significance of your contribution. If I understand you
> correctly with what you've written in the remainder of your message,
> some contributions warrant an unlimited linking exception. Is that what
> you have in mind? Would that solve your headaches?
>
> Arno
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

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

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

On 17 Μαρ 2010, at 4:29 ΜΜ, Arno Puder wrote:

>
>
> On 3/17/10 7:06 AM, Panayotis Katsaloulis wrote:
>> 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?
>
> Yes.
>
>> 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.
>
> I guess I really did a lot of harm with mentioning the 6 months. As I
> mentioned numerous times now, the length of the linking exception will
> depend on the significance of your contribution. If I understand you
> correctly with what you've written in the remainder of your message,
> some contributions warrant an unlimited linking exception. Is that  
> what
> you have in mind? Would that solve your headaches?


Both of these key points are much much better and clearer now, and  
better address issues with early contributions and/or large important  
& significant contributions which do not "expire".
Thank you, Arno.



I still don't feel comfortable though that the library is under GPL,  
but I can't think of any other way for you to make money for your  
ideas and efforts right now, so I'll be silent for this issue at the  
moment ;)

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

[Gergely K. <ger...@ma...>]

Hi,

Please find my comments below. Since the emails are already too long, I will
only include the relevant parts.

2010/3/17 Arno Puder <ar...@pu...>

> [...]
> >
> > 2. Unclear legal status of the project
> > When we are signing the CLA, we are signing the rights to "XMLVM". This
> > issue has been brought up last year on this list. Right now it is not
> > clear, who is XMLVM? Is there a commercial entity? Is it the 3 Core Team
> > members? Who will "own" the code, that is contributed? Who will grant
> > the commercial licenses?
> > The core team members work at large software companies / US universities.
> > It is not clear if these entities have any legal basis of "taking
> > XMLVM", and saying that the previous "linking exceptions" are invalid,
> > and starts to sue the users of XMLVM. This all depends on the work
> > contracts of the core team members, and also the relevant US and EU laws.
> >
> > I know that this seems like a slim chance right now, but stranger things
> > have happened, especially when there is money involved.
>
> By signing the CLA electronically, you only give us the right to use
> your patch. You still retain the copyright of your work. It is correct
> that XMLVM is not a legal entity and when I refer to XMLVM, I mean the
> core team. Would it help you if XMLVM incorporated in California? If I
> remember correctly, you are located in Eastern Europe. We cannot create
> companies all over the world to accommodate each national law.
>
No, Hungary is in Central Europe, and also an EU member state.

No one asked you to create a company in every country. What I suggested,
that it would clear up the legal stand of the XMLVM project, if there would
be a single legal entity who owns the project. Since you plan to
commercialize the project, this legal entity should probably be a for-profit
company. International business relationships between companies are pretty
common, our company is working with multiple companies all over the world.

The problem is, that currently the XMLVM Core Team who own the project, are
3 independent persons, who are possibly not even located in the same
country. This makes it pretty hard to enter into a business relationship
with you, like to buy a linking exception. Who is signing the contracts? All
3 of you? Who is going to create the invoice? Where do we transfer the
money?
Also, the contributors should receive written proof that they received a
linking exception.



>
> A developer on SourceForge must choose an Open Source license. The
> license spells out the rules, without the developer having to register a
> company. In that sense we do the same, except that we add the linking
> exception in return for a contribution (which, btw, is also not a new
> idea. Look on Wikipedia). Its a cheap man's commercial license, but I'd
> rather do that than charge $50.000 for a proper commercial license so we
> can pay the legal bills.
>
I think you have cleared up the confusion with the linking exception pretty
well, so it is an acceptable solution. It would make sense to create a
detailed official FAQ page about this.


> > 3. Absence of a real commercial license
> [...]
>
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 acknowledge that some clients require you to
> deliver source code of your work and the ability to re-compile the
> application (which means that they need XMLVM). If you use a commercial
> tool to build the application for your client (lets say, a modeling
> tool), your client will also need to buy a commercial license for this
> modeling tool if they want to re-compile the application themselves, right?
>
OK, I think with the other mails, the meaning of the linking exception is
pretty much cleared up. However, with a commercial tool, our client would be
able to buy the tool from the creator of the tool. Right now with XMLVM the
situation is unclear:
- How much does it cost for a company? Is it even possible to buy it for
money?
- Who do we need to contact? All 3 Core Team members at the same time?

I am trying to be practical here: We would recommend to buy XMLVM licenses
for our customers, but right now, we can't do that, because there is no one
to buy it from.

[...]

>
>
> 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.


This is an excerpt from the Contributor License Agreement:

> Grant of Copyright License. Subject to the terms and conditions of this
> Agreement, You hereby grant to XMLVM and to recipients of software
> distributed by XMLVM a perpetual, worldwide, non-exclusive, no-charge,
> royalty-free, irrevocable copyright license to reproduce, prepare derivative
> works of, publicly display, publicly perform, sublicense, and distribute
> Your Contributions and such derivative works.


In my interpretation this means that you can do whatever you want with the
contributed code, which includes re-licensing and selling it. If this were
not true, then you would not be able to provide linking exceptions for the
code that contributors wrote.

> - Keep the current dual licensing scheme for the compiler. As far as I
> > know the code generated by the compiler is still GPL - so you need a
> > commercial license for using it in commercial project. I am not a lawyer
> > -- if this is not the case, then you might consider changing the
> > compiler license accordingly.
>
>
> no. this is not correct. Look at gcc. gcc is GPLed and you can use it
> for commercial applications. The only way to do dual licensing is by
> having a restrictive license on the libraries.
>
> Just to clarify: This means that if no part of the compatibility library
(and of course the Android library) of XMLVM is used in a project, then the
resulting software is not subject to the GPL, and it can be redistributed
under any license without a linking exception.

Is this the correct interpretation?

 [...]

>
> I think what this whole thing boils down to is that you feel that your
> contribution is not valued enough. I do believe that we can address this
> with the length of the linking exception (I really don't want to spend
>
> [...]
Thank you for acknowledging the size of the contributions, I think that part
is covered, with your later mails.

However, what I meant here is not just about that. We (as a company) would
like to keep our investments safe, the same way you do.

Any contribution that we (or anybody else) make will have 2 parts:
- original work: something that was created independently of the existing
parts of XMLVM, e.g. a new class or method in a class.
- derived work: something that was created based on existing code in XMLVM,
e.g. when a method is changed to fix a bug, or the xsl is changed...etc.

I think the solution is that we contribute our original works as separate
patches, clearly marked as that. These are the parts that we are also
allowed to distribute under any license, according to the XMLVM CLA, which
we signed.

This method of submission will also mean much smaller patches, which will
help the review process substantially. I would recommend that you encourage
all contributions separated this way, since this is a sure way of avoiding
monster patches.

Do you agree with this approach?
I am already working on splitting up the patch that is sitting in the review
system to make it easier to review.

May I ask for the consent from each member of the Core Team about the GPL
interpretation and the "patch submission policy"?

I would very much like to be done with this legal stuff, and get back to
coding and improving XMLVM. :)

Best Regards,
Gergely

-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622

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

[Gergely K. <ger...@ma...>]

Hi,

2010/3/25 Arno Puder <ar...@pu...>

>
> > Just to clarify: This means that if no part of the compatibility library
> > (and of course the Android library) of XMLVM is used in a project, then
> > the resulting software is not subject to the GPL, and it can be
> > redistributed under any license without a linking exception.
> >
> > Is this the correct interpretation?
>
> Yes. If you only used XMLVM's compiler, the generated code would not be
> covered by the GPL. Note however, that the generated code without the
> library (e.g., xmlvm.m) will not do much. Once you link xmlvm.m, the GPL
> does apply to your application.
>

So essentially if one replaces everything in compat-lib with a new
implementation, then it is fine.


> > Any contribution that we (or anybody else) make will have 2 parts:
> > - original work: something that was created independently of the
> > existing parts of XMLVM, e.g. a new class or method in a class.
> > - derived work: something that was created based on existing code in
> > XMLVM, e.g. when a method is changed to fix a bug, or the xsl is
> > changed...etc.
>
> It is my interpretation of the GPL that these two cases would both be
> considered derived work. How you break up your contribution is up to
>

I am confused. I develop code that is not based on XMLVM in any way, like
the NSRecursiveCondition in the patch I submitted. Why would you consider it
derived work? So I can't reuse it in a different project without making it
GPL?

Or am I misunderstanding something?

Best Regards,
Gergely

-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622

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

[Sascha H. <sa...@xm...>]

On Fri, Mar 26, 2010 at 9:55 PM, Gergely Kis <ger...@ma...>wrote:

> Hi,
>
> 2010/3/25 Arno Puder <ar...@pu...>
>
>
>> > Just to clarify: This means that if no part of the compatibility library
>> > (and of course the Android library) of XMLVM is used in a project, then
>> > the resulting software is not subject to the GPL, and it can be
>> > redistributed under any license without a linking exception.
>> >
>> > Is this the correct interpretation?
>>
>> Yes. If you only used XMLVM's compiler, the generated code would not be
>> covered by the GPL. Note however, that the generated code without the
>> library (e.g., xmlvm.m) will not do much. Once you link xmlvm.m, the GPL
>> does apply to your application.
>>
>
> So essentially if one replaces everything in compat-lib with a new
> implementation, then it is fine.
>
>
>> > Any contribution that we (or anybody else) make will have 2 parts:
>> > - original work: something that was created independently of the
>> > existing parts of XMLVM, e.g. a new class or method in a class.
>> > - derived work: something that was created based on existing code in
>> > XMLVM, e.g. when a method is changed to fix a bug, or the xsl is
>> > changed...etc.
>>
>> It is my interpretation of the GPL that these two cases would both be
>> considered derived work. How you break up your contribution is up to
>>
>
> I am confused. I develop code that is not based on XMLVM in any way, like
> the NSRecursiveCondition in the patch I submitted. Why would you consider it
> derived work? So I can't reuse it in a different project without making it
> GPL?
>

It is my understanding as well, that you can take the code that you
contributed, and use it somewhere else. But you cannot use modifications,
that have been made to your class by somebody else, and use them.


>
> Or am I misunderstanding something?
>
>
> Best Regards,
> Gergely
>
> --
> Kis Gergely
> MattaKis Consulting
> Email: ger...@ma...
> Web: http://www.mattakis.com
> Phone: +36 70 408 1723
> Fax: +36 27 998 622
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

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

[Arno P. <ar...@pu...>]

On 3/26/10 1:55 PM, Gergely Kis wrote:
> So essentially if one replaces everything in compat-lib with a new
> implementation, then it is fine.

Yes, but I hope you are not insinuating anything with that observation.  :-)

>     It is my interpretation of the GPL that these two cases would both be
>     considered derived work. How you break up your contribution is up to
>
>
> I am confused. I develop code that is not based on XMLVM in any way,
> like the NSRecursiveCondition in the patch I submitted. Why would you
> consider it derived work? So I can't reuse it in a different project
> without making it GPL?
>
> Or am I misunderstanding something?

Is NSRecursiveCondition part of your application or an enhancement to 
XMLVM? I guess it is the latter. In this case you contribute it to XMLVM 
and it will fall under the GPL (because we, the core team, will add it 
to XMLVM since you gave us the permission to do so by signing the CLA). 
If it is part of your application and your application is linked against 
XMLVM, then it also must be placed under the GPL (unless we have granted 
you a linking exception). In both cases you retain copyright of your 
work and of course you are free to use your work in other projects. If 
you don't submit NSRecursiveCondition to us and you view it as part of 
your application, it is also covered by the linking exception (which 
means you can keep it closed source).

Arno

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

[Arno P. <ar...@pu...>]

sorry for the slow response.



On 3/20/10 2:20 AM, Gergely Kis wrote:
> No, Hungary is in Central Europe, and also an EU member state.

sooorry...

> The problem is, that currently the XMLVM Core Team who own the project,
> are 3 independent persons, who are possibly not even located in the same
> country. This makes it pretty hard to enter into a business relationship
> with you, like to buy a linking exception. Who is signing the contracts?
> All 3 of you? Who is going to create the invoice? Where do we transfer
> the money?
> Also, the contributors should receive written proof that they received a
> linking exception.

these are all fair questions to which we have no specific answers at 
this point. Right now 'payment' for which you receive the linking 
exception is only for code contribution. There is no way to pay $$$ at 
this point. We will address this issue so that your customer can 
purchase a linking exception. But we need some time to implement a 
procedure for this. Right now XMLVM is still a young project and it is 
more important for us to find consensus with you guys (the developers). 
And your currency is code.

> - How much does it cost for a company? Is it even possible to buy it for
> money?
> - Who do we need to contact? All 3 Core Team members at the same time?
>
> I am trying to be practical here: We would recommend to buy XMLVM
> licenses for our customers, but right now, we can't do that, because
> there is no one to buy it from.

We will work on these issues and consult with you guys as usual. Again, 
it is important to us to have a fair way of balancing open source and 
legitimate business interests. I hope that in the meantime, you as 
developers are OK with the 'code contribution in exchange for linking 
exception' idea.

> This is an excerpt from the Contributor License Agreement:
>
>     Grant of Copyright License. Subject to the terms and conditions of
>     this Agreement, You hereby grant to XMLVM and to recipients of
>     software distributed by XMLVM a perpetual, worldwide, non-exclusive,
>     no-charge, royalty-free, irrevocable copyright license to reproduce,
>     prepare derivative works of, publicly display, publicly perform,
>     sublicense, and distribute Your Contributions and such derivative works.
>
>
> In my interpretation this means that you can do whatever you want with
> the contributed code, which includes re-licensing and selling it. If
> this were not true, then you would not be able to provide linking
> exceptions for the code that contributors wrote.

Yes. You retain the copyright, but by signing the CLA you give us the 
right to do the things you have mentioned.

> Just to clarify: This means that if no part of the compatibility library
> (and of course the Android library) of XMLVM is used in a project, then
> the resulting software is not subject to the GPL, and it can be
> redistributed under any license without a linking exception.
>
> Is this the correct interpretation?

Yes. If you only used XMLVM's compiler, the generated code would not be 
covered by the GPL. Note however, that the generated code without the 
library (e.g., xmlvm.m) will not do much. Once you link xmlvm.m, the GPL 
does apply to your application.

> Any contribution that we (or anybody else) make will have 2 parts:
> - original work: something that was created independently of the
> existing parts of XMLVM, e.g. a new class or method in a class.
> - derived work: something that was created based on existing code in
> XMLVM, e.g. when a method is changed to fix a bug, or the xsl is
> changed...etc.

It is my interpretation of the GPL that these two cases would both be 
considered derived work. How you break up your contribution is up to 
you. There is obviously much value in sending bug fixes (your second 
case). If those bug fixes are 'significant' we will of course also grant 
a linking exception for that. In general we prefer smaller patches. But 
from my perspective you don't need to break it up into new code vs. bug 
fixes. Sometimes you cannot do one without the other.


> [...]
> Do you agree with this approach?
> I am already working on splitting up the patch that is sitting in the
> review system to make it easier to review.
>
> May I ask for the consent from each member of the Core Team about the
> GPL interpretation and the "patch submission policy"?

You certainly my consent. If Wolfgang and Sascha kept on reading until 
here, they can hopefully also give their consent.  :)

> I would very much like to be done with this legal stuff, and get back to
> coding and improving XMLVM. :)

I would like that very much!

Arno

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

[Wolfgang K. <wol...@xm...>]

Yes - I agree with Arno's statement concerning GPL interpretation and
monster patches. As can be seen - I read the complete mail ;-)

-- Wolfgang


Arno Puder wrote:
> sorry for the slow response.
>
>
>
> On 3/20/10 2:20 AM, Gergely Kis wrote:
>   
>> No, Hungary is in Central Europe, and also an EU member state.
>>     
>
> sooorry...
>
>   
>> The problem is, that currently the XMLVM Core Team who own the project,
>> are 3 independent persons, who are possibly not even located in the same
>> country. This makes it pretty hard to enter into a business relationship
>> with you, like to buy a linking exception. Who is signing the contracts?
>> All 3 of you? Who is going to create the invoice? Where do we transfer
>> the money?
>> Also, the contributors should receive written proof that they received a
>> linking exception.
>>     
>
> these are all fair questions to which we have no specific answers at 
> this point. Right now 'payment' for which you receive the linking 
> exception is only for code contribution. There is no way to pay $$$ at 
> this point. We will address this issue so that your customer can 
> purchase a linking exception. But we need some time to implement a 
> procedure for this. Right now XMLVM is still a young project and it is 
> more important for us to find consensus with you guys (the developers). 
> And your currency is code.
>
>   
>> - How much does it cost for a company? Is it even possible to buy it for
>> money?
>> - Who do we need to contact? All 3 Core Team members at the same time?
>>
>> I am trying to be practical here: We would recommend to buy XMLVM
>> licenses for our customers, but right now, we can't do that, because
>> there is no one to buy it from.
>>     
>
> We will work on these issues and consult with you guys as usual. Again, 
> it is important to us to have a fair way of balancing open source and 
> legitimate business interests. I hope that in the meantime, you as 
> developers are OK with the 'code contribution in exchange for linking 
> exception' idea.
>
>   
>> This is an excerpt from the Contributor License Agreement:
>>
>>     Grant of Copyright License. Subject to the terms and conditions of
>>     this Agreement, You hereby grant to XMLVM and to recipients of
>>     software distributed by XMLVM a perpetual, worldwide, non-exclusive,
>>     no-charge, royalty-free, irrevocable copyright license to reproduce,
>>     prepare derivative works of, publicly display, publicly perform,
>>     sublicense, and distribute Your Contributions and such derivative works.
>>
>>
>> In my interpretation this means that you can do whatever you want with
>> the contributed code, which includes re-licensing and selling it. If
>> this were not true, then you would not be able to provide linking
>> exceptions for the code that contributors wrote.
>>     
>
> Yes. You retain the copyright, but by signing the CLA you give us the 
> right to do the things you have mentioned.
>
>   
>> Just to clarify: This means that if no part of the compatibility library
>> (and of course the Android library) of XMLVM is used in a project, then
>> the resulting software is not subject to the GPL, and it can be
>> redistributed under any license without a linking exception.
>>
>> Is this the correct interpretation?
>>     
>
> Yes. If you only used XMLVM's compiler, the generated code would not be 
> covered by the GPL. Note however, that the generated code without the 
> library (e.g., xmlvm.m) will not do much. Once you link xmlvm.m, the GPL 
> does apply to your application.
>
>   
>> Any contribution that we (or anybody else) make will have 2 parts:
>> - original work: something that was created independently of the
>> existing parts of XMLVM, e.g. a new class or method in a class.
>> - derived work: something that was created based on existing code in
>> XMLVM, e.g. when a method is changed to fix a bug, or the xsl is
>> changed...etc.
>>     
>
> It is my interpretation of the GPL that these two cases would both be 
> considered derived work. How you break up your contribution is up to 
> you. There is obviously much value in sending bug fixes (your second 
> case). If those bug fixes are 'significant' we will of course also grant 
> a linking exception for that. In general we prefer smaller patches. But 
> from my perspective you don't need to break it up into new code vs. bug 
> fixes. Sometimes you cannot do one without the other.
>
>
>   
>> [...]
>> Do you agree with this approach?
>> I am already working on splitting up the patch that is sitting in the
>> review system to make it easier to review.
>>
>> May I ask for the consent from each member of the Core Team about the
>> GPL interpretation and the "patch submission policy"?
>>     
>
> You certainly my consent. If Wolfgang and Sascha kept on reading until 
> here, they can hopefully also give their consent.  :)
>
>   
>> I would very much like to be done with this legal stuff, and get back to
>> coding and improving XMLVM. :)
>>     
>
> I would like that very much!
>
> Arno
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>   

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

[Sascha H. <sa...@xm...>]

Same here.

On Thu, Mar 25, 2010 at 2:34 PM, Wolfgang Korn <wol...@xm...> wrote:

>  Yes - I agree with Arno's statement concerning GPL interpretation and
> monster patches. As can be seen - I read the complete mail ;-)
>
> -- Wolfgang
>
>
>
> Arno Puder wrote:
>
> sorry for the slow response.
>
>
>
> On 3/20/10 2:20 AM, Gergely Kis wrote:
>
>
>  No, Hungary is in Central Europe, and also an EU member state.
>
>
>  sooorry...
>
>
>
>  The problem is, that currently the XMLVM Core Team who own the project,
> are 3 independent persons, who are possibly not even located in the same
> country. This makes it pretty hard to enter into a business relationship
> with you, like to buy a linking exception. Who is signing the contracts?
> All 3 of you? Who is going to create the invoice? Where do we transfer
> the money?
> Also, the contributors should receive written proof that they received a
> linking exception.
>
>
>  these are all fair questions to which we have no specific answers at
> this point. Right now 'payment' for which you receive the linking
> exception is only for code contribution. There is no way to pay $$$ at
> this point. We will address this issue so that your customer can
> purchase a linking exception. But we need some time to implement a
> procedure for this. Right now XMLVM is still a young project and it is
> more important for us to find consensus with you guys (the developers).
> And your currency is code.
>
>
>
>  - How much does it cost for a company? Is it even possible to buy it for
> money?
> - Who do we need to contact? All 3 Core Team members at the same time?
>
> I am trying to be practical here: We would recommend to buy XMLVM
> licenses for our customers, but right now, we can't do that, because
> there is no one to buy it from.
>
>
>  We will work on these issues and consult with you guys as usual. Again,
> it is important to us to have a fair way of balancing open source and
> legitimate business interests. I hope that in the meantime, you as
> developers are OK with the 'code contribution in exchange for linking
> exception' idea.
>
>
>
>  This is an excerpt from the Contributor License Agreement:
>
>     Grant of Copyright License. Subject to the terms and conditions of
>     this Agreement, You hereby grant to XMLVM and to recipients of
>     software distributed by XMLVM a perpetual, worldwide, non-exclusive,
>     no-charge, royalty-free, irrevocable copyright license to reproduce,
>     prepare derivative works of, publicly display, publicly perform,
>     sublicense, and distribute Your Contributions and such derivative works.
>
>
> In my interpretation this means that you can do whatever you want with
> the contributed code, which includes re-licensing and selling it. If
> this were not true, then you would not be able to provide linking
> exceptions for the code that contributors wrote.
>
>
>  Yes. You retain the copyright, but by signing the CLA you give us the
> right to do the things you have mentioned.
>
>
>
>  Just to clarify: This means that if no part of the compatibility library
> (and of course the Android library) of XMLVM is used in a project, then
> the resulting software is not subject to the GPL, and it can be
> redistributed under any license without a linking exception.
>
> Is this the correct interpretation?
>
>
>  Yes. If you only used XMLVM's compiler, the generated code would not be
> covered by the GPL. Note however, that the generated code without the
> library (e.g., xmlvm.m) will not do much. Once you link xmlvm.m, the GPL
> does apply to your application.
>
>
>
>  Any contribution that we (or anybody else) make will have 2 parts:
> - original work: something that was created independently of the
> existing parts of XMLVM, e.g. a new class or method in a class.
> - derived work: something that was created based on existing code in
> XMLVM, e.g. when a method is changed to fix a bug, or the xsl is
> changed...etc.
>
>
>  It is my interpretation of the GPL that these two cases would both be
> considered derived work. How you break up your contribution is up to
> you. There is obviously much value in sending bug fixes (your second
> case). If those bug fixes are 'significant' we will of course also grant
> a linking exception for that. In general we prefer smaller patches. But
> from my perspective you don't need to break it up into new code vs. bug
> fixes. Sometimes you cannot do one without the other.
>
>
>
>
>  [...]
> Do you agree with this approach?
> I am already working on splitting up the patch that is sitting in the
> review system to make it easier to review.
>
> May I ask for the consent from each member of the Core Team about the
> GPL interpretation and the "patch submission policy"?
>
>
>  You certainly my consent. If Wolfgang and Sascha kept on reading until
> here, they can hopefully also give their consent.  :)
>
>
>
>  I would very much like to be done with this legal stuff, and get back to
> coding and improving XMLVM. :)
>
>
>  I would like that very much!
>
> Arno
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>