xmlvm-users — For current and interested XMLVM users, for public discussions and anouncements.

Re: [xmlvm-users] GPL and iPhone AppStore

[Andrea P. <and...@gm...>]

Hi all,

I following this mailing list since september and I didn't submit any
contribution yet, but I always asked to myself: How this guys think to
detect if an app has been cross-compiled with xmlvm and published on
appstore without owning a proper linking exception license? I don't
know deeply xmlvm but I hope that there are methods of detecting xmlvm
cross-compiled apps or are you relying only on good faith of
developers? Objectively, I can cross-compile my android app with xmlvm
and then publish it saying that I wrote it directly in Objective C
without using xmlvm (like C64 case mentioned by Panayotis)

Regards

a.p.

On Wed, Mar 17, 2010 at 4:48 PM, Panayotis Katsaloulis
<pan...@pa...> wrote:
>
> On 17 Μαρ 2010, at 5:19 ΜΜ, Steven Gurr wrote:
>
> Is anyone on this list able to clear up whether or not GPL'd apps are
> legally valid on the App Store? We've done some searching and found a number
> of blogs (http://diveintomark.org/archives/2008/03/07/iphone-gpl,
> http://stackoverflow.com/questions/762498/iphone-and-gpl, http://plasmasturm.org/log/512/, and
> http://www.geoffeg.org/wordpress/2009/10/07/the-iphone-and-the-gpl-v2-are-not-incompatible/)
> discussing it with varied conclusions, but nothing definitive or from a
> lawyer.
> This obviously has great implications on the suitability of xmlvm under its
> current licence for porting code to Objective-C for iPhone.
>
> There are already a lot of GPL-ed applications in the App-Store, including
> Xokoban :)
> Some of them, by the way, (like the C64 emulator) when requested to give
> back the source code, they don't do it.
> Something which made me furious*
>
>
> *except of course if they have a linking exception (which I believe they
> don't)
> ------------------------------------------------------------------------------
> 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] GPL and iPhone AppStore

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

On 17 Μαρ 2010, at 5:19 ΜΜ, Steven Gurr wrote:

> Is anyone on this list able to clear up whether or not GPL'd apps  
> are legally valid on the App Store? We've done some searching and  
> found a number of blogs (http://diveintomark.org/archives/2008/03/07/iphone-gpl 
> , http://stackoverflow.com/questions/762498/iphone-and-gpl, http://plasmasturm.org/log/512/ 
> , and http://www.geoffeg.org/wordpress/2009/10/07/the-iphone-and-the-gpl-v2-are-not-incompatible/) 
>  discussing it with varied conclusions, but nothing definitive or  
> from a lawyer.
>
> This obviously has great implications on the suitability of xmlvm  
> under its current licence for porting code to Objective-C for iPhone.
>

There are already a lot of GPL-ed applications in the App-Store,  
including Xokoban :)

Some of them, by the way, (like the C64 emulator) when requested to  
give back the source code, they don't do it.
Something which made me furious*



*except of course if they have a linking exception (which I believe  
they don't)

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 ;)

[xmlvm-users] GPL and iPhone AppStore

[Steven G. <st...@ma...>]

Is anyone on this list able to clear up whether or not GPL'd apps are
legally valid on the App Store? We've done some searching and found a number
of blogs (http://diveintomark.org/archives/2008/03/07/iphone-gpl,
http://stackoverflow.com/questions/762498/iphone-and-gpl,
http://plasmasturm.org/log/512/, and
http://www.geoffeg.org/wordpress/2009/10/07/the-iphone-and-the-gpl-v2-are-not-incompatible/)
discussing it with varied conclusions, but nothing definitive or from a
lawyer.

This obviously has great implications on the suitability of xmlvm under its
current licence for porting code to Objective-C for iPhone.


Thanks

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

[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

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

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

[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] xmlvm-users Digest, Vol 9, Issue 8

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

On 3/17/10 4:33 AM, Mark Wolfskehl wrote:
> I do have one additional comment regarding your view of the linking
> exception:  I believe that
> the linking exception should also be applied to all "derived works"
> created by the commercial developer
> based on the code base for which the linking exception was granted.
> At the very least, this allows
> the commercial developer to include bug fixes, even if these are not
> deemed "significant" by other standards.
> They may also include contributions that do not seem "significant" to
> the group but which are significant to the
> commercial entity.  I believe this would be a reasonable exception.

Lets say we grant you a linking exception for a version of XMLVM. Your 
commercial product as well as further modifications to XMLVM can be 
viewed as "derived work". Since we give you a linking exception for 
XMLVM, your commercial product can remain closed source. However, XMLVM 
itself is still covered by the GPL which means any modification you make 
to XMLVM needs to be placed under the GPL. If I understand you 
correctly, your question is about this locally modified version of 
XMLVM. The linking exception also applies to this locally modified 
version. Since you have to release your bug fix under the GPL, we will 
integrate it back to the code base of XMLVM. Because we grant you the 
linking exception for a period of time, you can download the new 
official version of XMLVM and you will also be given the linking exception.

> I appreciate your attitude of cooperation and desire to give-and-
> take.  That's what business is about, or at
> least should be about.

Thank you!  :-)

Arno

Re: [xmlvm-users] xmlvm-users Digest, Vol 9, Issue 8

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

Mark,

thanks for sharing you thoughts about our CLA. You suggest to grant the
CLA for all derived work based on the code base into which a
contribution was integrated. As Arno pointed out earlier, usually a
contribution gets never removed from XMLVM once we decided to accept and
integrate a patch. That means, that all subsequent versions of XMLVM can
be considered as "derived work" which implies that we should grant a CLA
which is not limited in terms of time. Did I get you right?

-- Wolfgang


Mark Wolfskehl wrote:
> Hi Arno,
>
> Thanks for answering here some of the questions I had sent to you  
> directly last week.
>
> I think the general direction of what you have proposed is reasonable.
> I understand your interest in motivating others with commercial  
> interests to contribute to the project.
>
> I find the technology of XMLVM interesting in and of itself.  My main  
> limitation is time, given that I work
> for someone else full-time and can only work on my personal  
> commercial interests (or XMLVM) with the limited time
> that is left.
>
> The main thing you are providing for commercial developers, I  
> believe, is savings of time - not having to
> port an application from Android to the iPhone.  So, as far as I am  
> concerned, if I spend roughly the same
> amount of time working on XMLVM that I would have done directly for  
> an iPhone port of an Android application,
> that's fine.  I'd rather be doing something different than coding the  
> same thing a second time anyway.
> And ostensibly that time savings adds up for the next product, etc.
>
> I do have one additional comment regarding your view of the linking  
> exception:  I believe that
> the linking exception should also be applied to all "derived works"  
> created by the commercial developer
> based on the code base for which the linking exception was granted.   
> At the very least, this allows
> the commercial developer to include bug fixes, even if these are not  
> deemed "significant" by other standards.
> They may also include contributions that do not seem "significant" to  
> the group but which are significant to the
> commercial entity.  I believe this would be a reasonable exception.
>
> I appreciate your attitude of cooperation and desire to give-and- 
> take.  That's what business is about, or at
> least should be about.
>
> I look forward to the opportunity to work with all of you.  My main  
> challenge will be to actually find the time
> to do all the personal projects (including XMLVM) that I would like  
> to do, with the challenges of keeping
> a full-time coding job.  If any of you have any advice or suggestions  
> from personal experience regarding this,
> I'm all ears.
>
> Regards,
> Mark Wolfskehl, Ph.D.
>   

Re: [xmlvm-users] xmlvm-users Digest, Vol 9, Issue 8

[Mark W. <ma...@ma...>]

Hi Arno,

Thanks for answering here some of the questions I had sent to you  
directly last week.

I think the general direction of what you have proposed is reasonable.
I understand your interest in motivating others with commercial  
interests to contribute to the project.

I find the technology of XMLVM interesting in and of itself.  My main  
limitation is time, given that I work
for someone else full-time and can only work on my personal  
commercial interests (or XMLVM) with the limited time
that is left.

The main thing you are providing for commercial developers, I  
believe, is savings of time - not having to
port an application from Android to the iPhone.  So, as far as I am  
concerned, if I spend roughly the same
amount of time working on XMLVM that I would have done directly for  
an iPhone port of an Android application,
that's fine.  I'd rather be doing something different than coding the  
same thing a second time anyway.
And ostensibly that time savings adds up for the next product, etc.

I do have one additional comment regarding your view of the linking  
exception:  I believe that
the linking exception should also be applied to all "derived works"  
created by the commercial developer
based on the code base for which the linking exception was granted.   
At the very least, this allows
the commercial developer to include bug fixes, even if these are not  
deemed "significant" by other standards.
They may also include contributions that do not seem "significant" to  
the group but which are significant to the
commercial entity.  I believe this would be a reasonable exception.

I appreciate your attitude of cooperation and desire to give-and- 
take.  That's what business is about, or at
least should be about.

I look forward to the opportunity to work with all of you.  My main  
challenge will be to actually find the time
to do all the personal projects (including XMLVM) that I would like  
to do, with the challenges of keeping
a full-time coding job.  If any of you have any advice or suggestions  
from personal experience regarding this,
I'm all ears.

Regards,
Mark Wolfskehl, Ph.D.

I'll repeat here part of my personal introduction to Arno:

http://www.linkedin.com/in/markwolfskehl


I am currently working as a senior software engineer for SeaChange  
International, a producer of cable Video On Demand servers and  
clients.  My programming background has been mainly in C++.  I have  
done a large project in Prolog, and I am currently working full-time  
in Java SE.  I have a Ph.D. granted in 2000 in computer science from  
Stevens Institute of Technology in Hoboken, NJ.  I will include a  
link to my LinkedIn page.  There isn't much mention there of my  
graduate background as it does not generally apply directly to the  
type of industry work I usually do (mainly highly multithreaded/logic  
intensive/algorithms work), but it is probably relevant to your project.

My graduate work was heavily focused on theoretical computer science  
- computational complexity theory, proofs, formal methods, formal  
semantics of programming languages, and model checking.  I have  
subsequently done some work utilizing a formal mathematics approach  
to algorithm development (only personal notes), in particular a  
speculative design for a heuristic solution to 3SAT - something that  
has been on the shelf for a long time and has never been prototyped.   
My Ph.D. advisor was Steve Bloom (Ph.D. in math from MIT), and I have  
worked with David Klappholz (he used to focus on compiler optimization).




On Mar 16, 2010, at 1:55 PM, xmlvm-users- 
re...@li... wrote:

> Send xmlvm-users mailing list submissions to
> 	xml...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> or, via email, send a message with subject or body 'help' to
> 	xml...@li...
>
> You can reach the person managing the list at
> 	xml...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of xmlvm-users digest..."
>
>
> Today's Topics:
>
>    1. Re: about org_xmlvm_iphone_AVAudioPlayer	initialization
>       (Wolfgang Korn)
>    2. Patches and broken SVN (Panayotis Katsaloulis)
>    3. Re: Patches and broken SVN (Sascha Haeberling)
>    4. Re: Patches and broken SVN (Sascha Haeberling)
>    5. Clarifications on the Linking Exception (Arno Puder)
>    6. Google TechTalk (Arno Puder)
>    7. Re: Clarifications on the Linking Exception
>       (Panayotis Katsaloulis)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 11 Mar 2010 20:08:58 +0100
> From: Wolfgang Korn <wol...@xm...>
> Subject: Re: [xmlvm-users] about org_xmlvm_iphone_AVAudioPlayer
> 	initialization
> To: Panayotis Katsaloulis <pan...@pa...>
> Cc: xml...@li...
> Message-ID: <4B9...@xm...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Panayotis,
>
> I just checked the code you mentioned. I agree - retain shouldn't be
> called. I committed this change to SVN.
>
> -- Wolfgang
>
>
> Panayotis Katsaloulis wrote:
>> in the initialization of  "org_xmlvm_iphone_AVAudioPlayer.m",  
>> there is
>> this code:
>>
>> return [[[AVAudioPlayer alloc] initWithContentsOfURL: url error:
>> &(outError->error_org_xmlvm_iphone_NSError)] retain];
>>
>> Why there is a need for a second retain there (the first is the alloc
>> itself) ?
>>
>> --------------------------------------------------------------------- 
>> ---------
>> 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
>>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 15 Mar 2010 19:16:12 +0200
> From: Panayotis Katsaloulis <pan...@pa...>
> Subject: [xmlvm-users] Patches and broken SVN
> To: xml...@li...
> Message-ID: <AAC...@pa...>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Hello again!
>
> I'd decided to send you my latest patch with tons of improvements in
> the obj-c compatibility layer.
> But I've seen that the current SVN release is broken.
> Can I just send the patches the usual way ?
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 15 Mar 2010 18:22:54 +0100
> From: Sascha Haeberling <sa...@xm...>
> Subject: Re: [xmlvm-users] Patches and broken SVN
> To: Panayotis Katsaloulis <pan...@pa...>
> Cc: xml...@li...
> Message-ID:
> 	<709...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> You can send us the well-commented and formatted patches the usual  
> way via
> the review tool.
>
> I am currently taking a look at the breakage.
>
> // Sascha
>
> On Mon, Mar 15, 2010 at 6:16 PM, Panayotis Katsaloulis <
> pan...@pa...> wrote:
>
>> Hello again!
>>
>> I'd decided to send you my latest patch with tons of improvements in
>> the obj-c compatibility layer.
>> But I've seen that the current SVN release is broken.
>> Can I just send the patches the usual way ?
>>
>>
>> --------------------------------------------------------------------- 
>> ---------
>> 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
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: Mon, 15 Mar 2010 18:42:51 +0100
> From: Sascha Haeberling <sa...@xm...>
> Subject: Re: [xmlvm-users] Patches and broken SVN
> To: Panayotis Katsaloulis <pan...@pa...>
> Cc: xml...@li...
> Message-ID:
> 	<709...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> FYI: Current HEAD should work again.
>
> // Sascha
>
> On Mon, Mar 15, 2010 at 6:22 PM, Sascha Haeberling  
> <sa...@xm...> wrote:
>
>> You can send us the well-commented and formatted patches the usual  
>> way via
>> the review tool.
>>
>> I am currently taking a look at the breakage.
>>
>> // Sascha
>>
>>
>> On Mon, Mar 15, 2010 at 6:16 PM, Panayotis Katsaloulis <
>> pan...@pa...> wrote:
>>
>>> Hello again!
>>>
>>> I'd decided to send you my latest patch with tons of improvements in
>>> the obj-c compatibility layer.
>>> But I've seen that the current SVN release is broken.
>>> Can I just send the patches the usual way ?
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> ----------
>>> 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
>>>
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 5
> Date: Tue, 16 Mar 2010 17:16:18 +0100
> From: Arno Puder <ar...@pu...>
> Subject: [xmlvm-users] Clarifications on the Linking Exception
> To: "xml...@li..."
> 	<xml...@li...>
> Message-ID: <4B9...@pu...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> 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
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 16 Mar 2010 17:26:18 +0100
> From: Arno Puder <ar...@pu...>
> Subject: [xmlvm-users] Google TechTalk
> To: "xml...@li..."
> 	<xml...@li...>
> Message-ID: <4B9...@pu...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> Guys,
>
> I was fortunate enough to get invited by Google to talk about XMLVM as
> part of their TechTalk series. If you are interested, there is a
> recording on YouTube: http://www.youtube.com/watch?v=TG-NIt2O5J8
>
> Here is a link to the slides:
> http://xmlvm.org/slides/android2iphone-google-mtv.pdf
>
> Arno
>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 16 Mar 2010 19:54:59 +0200
> From: Panayotis Katsaloulis <pan...@pa...>
> Subject: Re: [xmlvm-users] Clarifications on the Linking Exception
> To: xml...@li...
> Message-ID: <6CA...@pa...>
> Content-Type: text/plain; charset="us-ascii"
>
>>
>> (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) ?
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> ---------------------------------------------------------------------- 
> --------
> 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
>
>
> End of xmlvm-users Digest, Vol 9, Issue 8
> *****************************************

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

[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) ?

[xmlvm-users] Google TechTalk

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

Guys,

I was fortunate enough to get invited by Google to talk about XMLVM as 
part of their TechTalk series. If you are interested, there is a 
recording on YouTube: http://www.youtube.com/watch?v=TG-NIt2O5J8

Here is a link to the slides:
http://xmlvm.org/slides/android2iphone-google-mtv.pdf

Arno

[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] Patches and broken SVN

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

FYI: Current HEAD should work again.

// Sascha

On Mon, Mar 15, 2010 at 6:22 PM, Sascha Haeberling <sa...@xm...> wrote:

> You can send us the well-commented and formatted patches the usual way via
> the review tool.
>
> I am currently taking a look at the breakage.
>
> // Sascha
>
>
> On Mon, Mar 15, 2010 at 6:16 PM, Panayotis Katsaloulis <
> pan...@pa...> wrote:
>
>> Hello again!
>>
>> I'd decided to send you my latest patch with tons of improvements in
>> the obj-c compatibility layer.
>> But I've seen that the current SVN release is broken.
>> Can I just send the patches the usual way ?
>>
>>
>> ------------------------------------------------------------------------------
>> 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] Patches and broken SVN

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

You can send us the well-commented and formatted patches the usual way via
the review tool.

I am currently taking a look at the breakage.

// Sascha

On Mon, Mar 15, 2010 at 6:16 PM, Panayotis Katsaloulis <
pan...@pa...> wrote:

> Hello again!
>
> I'd decided to send you my latest patch with tons of improvements in
> the obj-c compatibility layer.
> But I've seen that the current SVN release is broken.
> Can I just send the patches the usual way ?
>
>
> ------------------------------------------------------------------------------
> 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
>

[xmlvm-users] Patches and broken SVN

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

Hello again!

I'd decided to send you my latest patch with tons of improvements in  
the obj-c compatibility layer.
But I've seen that the current SVN release is broken.
Can I just send the patches the usual way ?

Re: [xmlvm-users] about org_xmlvm_iphone_AVAudioPlayer initialization

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

Panayotis,

I just checked the code you mentioned. I agree - retain shouldn't be
called. I committed this change to SVN.

-- Wolfgang


Panayotis Katsaloulis wrote:
> in the initialization of  "org_xmlvm_iphone_AVAudioPlayer.m", there is  
> this code:
>
> return [[[AVAudioPlayer alloc] initWithContentsOfURL: url error:  
> &(outError->error_org_xmlvm_iphone_NSError)] retain];
>
> Why there is a need for a second retain there (the first is the alloc  
> itself) ?
>
> ------------------------------------------------------------------------------
> 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] memory management and return of an object

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

as of now, it is the rule.

Arno


On 3/11/10 8:50 AM, Panayotis Katsaloulis wrote:
>
> On 11 Μαρ 2010, at 6:09 ΜΜ, Arno Puder wrote:
>
>>
>> right now we have the rule that ownership of an object that is
>> returned
>> as a result of a method invocation is passed to the caller. That is
>> why
>> we have as a general rule a retain on references when returning them.
>> The caller then decides what it wants to do with the reference. If the
>> caller ignores the result (which the callee cannot know) it will do a
>> release.
>>
>> I will be adding a patch in the next few days that will get rid of
>> NSAutoreleasePool. Those memory management rules won't change, but the
>> code should be much more efficient.
>>
>> Arno
>
> So, practically it is always important to "retain" the object when
> creating the objective-c library connection with java, right?
>
> I am asking this because I am working on a patch which will take care
> of nil objects returned by various property glue functions, and I want
> to make clear that it's a _rule_ to always retain an object before
> returning it.
>
>
> ------------------------------------------------------------------------------
> 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] memory management and return of an object

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

On 11 Μαρ 2010, at 6:09 ΜΜ, Arno Puder wrote:

>
> right now we have the rule that ownership of an object that is  
> returned
> as a result of a method invocation is passed to the caller. That is  
> why
> we have as a general rule a retain on references when returning them.
> The caller then decides what it wants to do with the reference. If the
> caller ignores the result (which the callee cannot know) it will do a
> release.
>
> I will be adding a patch in the next few days that will get rid of
> NSAutoreleasePool. Those memory management rules won't change, but the
> code should be much more efficient.
>
> Arno

So, practically it is always important to "retain" the object when  
creating the objective-c library connection with java, right?

I am asking this because I am working on a patch which will take care  
of nil objects returned by various property glue functions, and I want  
to make clear that it's a _rule_ to always retain an object before  
returning it.

Re: [xmlvm-users] memory management and return of an object

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

right now we have the rule that ownership of an object that is returned 
as a result of a method invocation is passed to the caller. That is why 
we have as a general rule a retain on references when returning them. 
The caller then decides what it wants to do with the reference. If the 
caller ignores the result (which the callee cannot know) it will do a 
release.

I will be adding a patch in the next few days that will get rid of 
NSAutoreleasePool. Those memory management rules won't change, but the 
code should be much more efficient.

Arno


On 3/11/10 5:20 AM, Panayotis Katsaloulis wrote:
>
> I've seen that in the code produced by xmlvm, every time an object is
> returned, this object is at the same moment released.
> Thus usually in properties we see something like:
>
> return [[self propertyname] retain];
>
> So, can we say that this is a general rule?
> I mean, that in any case, no matter what, when the thin library obj-c
> layer is required to return an object, this object should be *always*
> retained?
>
> Is this valid also for objects like usually retrieved with selectors
> like
> [UIFont systemFontOfSize:fontsize]
> ?
>
> I have made some tests with the last one, and even if I don't retain
> it, there is no segfault (which, ok, this doesn't mean anything).
>
>
> So what is optimum (concerning memory management) ?
>
> Thank you!
>
> ------------------------------------------------------------------------------
> 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] about org_xmlvm_iphone_AVAudioPlayer initialization

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

That's actually a good question. I'll check that.

-- Wolfgang

Panayotis Katsaloulis wrote:
> in the initialization of  "org_xmlvm_iphone_AVAudioPlayer.m", there is  
> this code:
>
> return [[[AVAudioPlayer alloc] initWithContentsOfURL: url error:  
> &(outError->error_org_xmlvm_iphone_NSError)] retain];
>
> Why there is a need for a second retain there (the first is the alloc  
> itself) ?
>
> ------------------------------------------------------------------------------
> 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
>   

[xmlvm-users] memory management and return of an object

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

I've seen that in the code produced by xmlvm, every time an object is  
returned, this object is at the same moment released.
Thus usually in properties we see something like:

return [[self propertyname] retain];

So, can we say that this is a general rule?
I mean, that in any case, no matter what, when the thin library obj-c  
layer is required to return an object, this object should be *always*  
retained?

Is this valid also for objects like usually retrieved with selectors  
like
[UIFont systemFontOfSize:fontsize]
?

I have made some tests with the last one, and even if I don't retain  
it, there is no segfault (which, ok, this doesn't mean anything).


So what is optimum (concerning memory management) ?

Thank you!