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

Re: [xmlvm-users] Monster patches and GPL linking exception

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

I wholeheartedly agree with this. If you plan to work on a non-trivial 
enhancement for XMLVM, you should announce that on the mailing list 
before you begin to avoid redundant work.

Arno


On 3/20/10 2:32 AM, Gergely Kis wrote:
> Hi,
>
> I think the solution for this is to communicate more on the mailing
> list, to lay down the technical directions of the project. Right now
> everyone is developing privately, then throws patches "over the wall".
> If we discussed the approaches on the mailing list, then each of us
> would make less duplicated efforts.
>
> Of course, when you are under time pressure, to get an application
> working, you have to go ahead on your private branch. In this case you
> take the risk that your changes are never going to be merged.
>
> Best Regards,
> Gergely
>
> 2010/3/18 Panayotis Katsaloulis <pan...@pa...
> <mailto:pan...@pa...>>
>
>
>     On 18 Μαρ 2010, at 6:15 ΜΜ, Dr. Alexander K. Seewald wrote:
>
>     ...
>
>      > Currently it works like that: Wolfgang, Arno or Sascha ask me about
>      > a specific functionality (currently it's audio recording), and I
>
>     ....
>     right, that's the key point:
>     they "asked" you :)
>
>
>     I know that it really is difficult to handle, but (as I said in
>     previous posts), it is expected for a new project to have patches like
>     these.
>
>     Of course if such patch is not desirable, I could take it back and
>     send, for example, only UIViewContoller, then tomorrow another object,
>     and so forth :)
>     But I believe the total effort then will be much much larger than now,
>     since this whole patch has a common logic which at the end of the day
>     will make evaluating it easier than to send one file at a time.
>     Maybe it might seem too difficult, but it would be easier than to
>     "divide and conquer" :)
>
>
>     ------------------------------------------------------------------------------
>     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...
>     <mailto:xml...@li...>
>     https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>
> --
> Kis Gergely
> MattaKis Consulting
> Email: ger...@ma... <mailto: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...>]

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] "init" question

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

this is a very tricky issue. As Gergely pointed out, a JVM creates a new 
object in two steps: first allocate memory for the new instance (via 
instruction <dex:new>) and then call its constructor (via instruction 
<dex:invoke-special>). It is exactly this two step procedure that is 
difficult to map to Objective-C.

In Objective-C things are not that different. You first send a class the 
alloc message followed by an init* message. At some point I tried to use 
this fact by calling alloc for <dex:new> and init* for 
<dex:invoke-special>. However, for some strange reason Obejctive-C is 
very peculiar about calling alloc and init. If it is not done in a 
nested way via [[Class alloc] init], bad things happen.

I should also mention that it is not always guaranteed that <dex:new> is 
immediately followed by <dex:invoke-special>, otherwise one might do 
some peephole optimization.

I also noted the problem that Panayotis has come across, but I couldn't 
find an easy solution. If someone has a bright idea, I'm all ears!

Arno


On 3/21/10 6:09 AM, Gergely Kis wrote:
> Hi,
>
> I think the cause of the problem is the "3 phase" initialization of the
> Java objects.
>
> As you wrote in your mail, currently each object is initalized like this:
>
> x = [[[TypeName alloc] init] autorelease];
> [x __init_TypeName__parameter_types: parameters]; // This is the actual
> Java constructor
>
> If we could change this convention to the following:
> x = [[[TypeName alloc] __init_TypeName__parameter_types: parameters]
> autorelease];
>
> And then in the __init method, it would call the super constructor
> __init_SuperTypeName_*, while in the Java Runtime we could simply use:
>
> self = [self initWithClassSpecificParameters: parameters];
> return self;
>
> This approach would have advantages in many places, like the UIWindow
> that you mention, or e.g. immutable classes, like NSString, NSURL ...
> etc., where we had to introduce hacks of various sorts, like a special
> constructor for NSString, a dynamic proxy for NSURL.
>
> What do you think?
>
> Best Regards,
> Gergely
>
> 2010/3/21 Panayotis Katsaloulis <pan...@pa...
> <mailto:pan...@pa...>>
>
>     Hello again
>
>     Today I experienced an issue, which produced some strange behavior
>     and I am thinking if there is any way to solve it.
>     This behavior actually appeared to me with UIWindow (which was
>     easily solvable) but I am thinking of a more generic solution.
>
>     The problem is with objects that request a specific initialization
>     to be performed, other than [object init]
>     The auto-generated code of any object has something like
>     [[[NSObject alloc] init] autorelease]
>     which is fine, but it is wrong with objects like UITableView which
>     specifically request arguments in their initialization selector,
>     which can not be changed afterwards (like the "style" property).
>
>     What is done right now is to call once the generic "init" selector,
>     and at later time call the more specific initWithFrame:style: selector.
>     Thus initializing the object twice!
>
>     In this specific case there doesn't seem to do any harm, but I have
>     found out that in other cases, like UIWindow this might lead to
>     serious problems!
>     Of course solving UIWindow was an easy task, just replace
>     initWithFrame: with setFrame:  (since init was already called).
>
>     I am wondering though: is there any way to call the specific
>     initWithXXX: function instead of the generic one?
>     Or, in other words, is it possible to avoid this double
>     initialization of the object?
>
>
>     PS: I am massively creating a patch to avoid if possible all
>     non-needed init selectors in the library, but this is just a
>     convenient solution for special cases, not a generic one.
>
>
>     ------------------------------------------------------------------------------
>     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...
>     <mailto:xml...@li...>
>     https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>
> --
> Kis Gergely
> MattaKis Consulting
> Email: ger...@ma... <mailto: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

[xmlvm-users] No dependence on NSAutoreleasePool

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

Guys,

I have just committed a patch submitted by Joshua Melcon. His patch 
removes the dependency on NSAutoreleasePool during code generation. 
NSAutoreleasePool is a convenience class for Objective-C programmers to 
defer releases on object references to a later time. So far we have made 
heavy use of NSAutoreleasePool (every method had its own 
NSAutoreleasePool). Unfortunately, NSAutoreleasePool is very runtime 
inefficient. Joshua's patch removes this dependency by computing where 
release and retains need to be inserted. This should dramatically 
improve runtime performance of the code generated by XMLVM.

Please update your copies of XMLVM and try your applications. If there 
are problems, please report back on the mailing list. Joshua will 
continue with some further optimizations (currently there are some 
redundant retain/release in the generated code).

Note: this change has *no* impact on the ownership rules when passing 
object references as input arguments or when returning an object 
reference as a result. Newly created instances should not be added to a 
NSAutoreleasePool.

Arno

Re: [xmlvm-users] weak references

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

On 23 Μαρ 2010, at 7:29 μ.μ., Panayotis Katsaloulis wrote:

> Java will never stop surprise me!
> I really didn't know that it supported weak references!
> 
> Your idea is very good, I'll follow this path, then!
> 
> --
> Panayotis
> 
> 23 Μαρ 2010, 5:47 μ.μ., ο/η Tor Lillqvist <tm...@ik...> έγραψε:
> 
>>> although I am not sure that this is something that should be
>>> exposed in Java, but anyway.
>> 
>> Java is supposed to have weak references, isn't it?
>> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html
>> So if you expose them to Java as the spec describes, it should just
>> be a good thing and make even more Java code work with XMLVM.
>> 
>> --tml


It seems that this was much easier than what I originally thought.
In parallel I have created a mechanism to store variables of category objects (or any other object anyway), since by definition in a category you won't be able to store other variables.
This is useful to clean up a bit with retained delegates that nobody releases them (and yes, I believe this code has less memory leaks than ever!)

Probably I should take down my old patch and release a new patch, with this improved memory management issues.

What others (i.e. the xmlvm team) think?
:D

Re: [xmlvm-users] weak references

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

Java will never stop surprise me!
I really didn't know that it supported weak references!

Your idea is very good, I'll follow this path, then!

--
Panayotis

23 Μαρ 2010, 5:47 μ.μ., ο/η Tor Lillqvist <tm...@ik...>  
έγραψε:

>> although I am not sure that this is something that should be
>> exposed in Java, but anyway.
>
> Java is supposed to have weak references, isn't it?
> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html
> So if you expose them to Java as the spec describes, it should just
> be a good thing and make even more Java code work with XMLVM.
>
> --tml

Re: [xmlvm-users] weak references

[Tor L. <tm...@ik...>]

> although I am not sure that this is something that should be
> exposed in Java, but anyway.

Java is supposed to have weak references, isn't it?
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html
 So if you expose them to Java as the spec describes, it should just
be a good thing and make even more Java code work with XMLVM.

--tml

[xmlvm-users] weak references

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

I am wondering for a long time, how to have weak references under xmlvm.
You know that already, but just for reference I say that weak  
references are sometimes needed, to avoid cyclic dependencies.
An example with those are with delegates, which need to have a weak  
reference to the actual object.
If they simply have a strong reference, then there will be a cycle and  
everything will stay onto memory.

Thus I have created a patch which actually deals with the problem.  
First of all it gives access to the retain/release mechanism, just in  
case, although I am not sure that this is something that should be  
exposed in Java, but anyway.

It also gives access to dealloc, which is a vital location to clean up  
weak references.

And at the end it provides an utility object, which will perform the  
actual weak binding between the two objects, but which will also avoid  
cyclic dependencies.

This could be mostly used for delegates, but it can also be used for  
any other case someone wants to break cyclic dependencies in Java.

What do you think?

PS: I am not sending the patch right now, only because it depends on  
my previous memory management approach.
I could, though, send the "unofficially" the patch even in this list  
to have a look and gather opinions.

Re: [xmlvm-users] Monster patches and GPL linking exception

[Dr. A. K. S. <al...@se...>]

Hi,

I currently have the situation:
* I built a large private branch of xmlvm to make my application
  work.
* My application has been finished, working and tested for about a
  month.
However, as it is a paid application, I cannot (IMHO) submit it to
the Apple store without getting a GPL linking exception. Initially I
was told that this would be possible for every contributor. Now it
seems to depend on the significance of the contribution. And now it
also seems that I have implemented some of the core functionality in
a way that is incompatible with XMLVMs design goals which creates
additional work for refactoring the patches.

I would be happy with just being able to use the r953 with my
private patches. I would not even need any additional versions for
now. I am just a single-person company and a GPL linking exception
just for this single release in writing would allow me to finally
submit my app to the App Store (i'ts been available for Android
since November). So, with Gergely, can we agree on the legal issues
and on who gets a GPL linking exception for what and then get
back to improving xmlvm?

It may sound harsh but I do not intend to refactor and contribute
any more source code until this point is clarified.

Best,
  Alex
-- 
Dr. Alexander K. Seewald

Seewald Solutions
www.seewald.at
Tel. +43(664)1106886
Fax. +43(1)2533033/2764

Re: [xmlvm-users] "init" question

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

Hi,

I think the cause of the problem is the "3 phase" initialization of the Java
objects.

As you wrote in your mail, currently each object is initalized like this:

x = [[[TypeName alloc] init] autorelease];
[x __init_TypeName__parameter_types: parameters]; // This is the actual Java
constructor

If we could change this convention to the following:
x = [[[TypeName alloc] __init_TypeName__parameter_types: parameters]
autorelease];

And then in the __init method, it would call the super constructor
__init_SuperTypeName_*, while in the Java Runtime we could simply use:

self = [self initWithClassSpecificParameters: parameters];
return self;

This approach would have advantages in many places, like the UIWindow that
you mention, or e.g. immutable classes, like NSString, NSURL ... etc., where
we had to introduce hacks of various sorts, like a special constructor for
NSString, a dynamic proxy for NSURL.

What do you think?

Best Regards,
Gergely

2010/3/21 Panayotis Katsaloulis <pan...@pa...>

> Hello again
>
> Today I experienced an issue, which produced some strange behavior and I am
> thinking if there is any way to solve it.
> This behavior actually appeared to me with UIWindow (which was easily
> solvable) but I am thinking of a more generic solution.
>
> The problem is with objects that request a specific initialization to be
> performed, other than [object init]
> The auto-generated code of any object has something like
> [[[NSObject alloc] init] autorelease]
> which is fine, but it is wrong with objects like UITableView which
> specifically request arguments in their initialization selector, which can
> not be changed afterwards (like the "style" property).
>
> What is done right now is to call once the generic "init" selector, and at
> later time call the more specific initWithFrame:style: selector.
> Thus initializing the object twice!
>
> In this specific case there doesn't seem to do any harm, but I have found
> out that in other cases, like UIWindow this might lead to serious problems!
> Of course solving UIWindow was an easy task, just replace initWithFrame:
> with setFrame:  (since init was already called).
>
> I am wondering though: is there any way to call the specific initWithXXX:
> function instead of the generic one?
> Or, in other words, is it possible to avoid this double initialization of
> the object?
>
>
> PS: I am massively creating a patch to avoid if possible all non-needed
> init selectors in the library, but this is just a convenient solution for
> special cases, not a generic one.
>
>
>
> ------------------------------------------------------------------------------
> 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
>



-- 
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] UTF-8 in String?

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

Hi guys,

does any of you have some update on UTF-8? I am planning to look into this
problem now in order so solve it as soon as possible, but don't want to
duplicate any of your work.

// Sascha

On Fri, Mar 5, 2010 at 2:34 PM, Gergely Kis <ger...@ma...>wrote:

> Hi,
>
> I don't have much time, so just a quick FYI: I think we included some UTF-8
> fixes in our patch. I am sorry that I cannot be more specific now, I would
> need to check what we did exactly, but I am sure that our application loads
> and displays UTF-8 text correctly (german characters, copyright symbol
> ...etc.)
> I will try to sum it up when I get the time.
>
> Best Regards,
> Gergely
>
> 2010/3/5 Panayotis Katsaloulis <pan...@pa...>
>
> So any idea, how to correctly pass a unicode character to obj-c?
>> Let's take for example the euro symbol "€", how can create an
>> application which will display it?
>>
>
>
> --
> 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
>
>

[xmlvm-users] "init" question

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

Hello again

Today I experienced an issue, which produced some strange behavior and I am thinking if there is any way to solve it.
This behavior actually appeared to me with UIWindow (which was easily solvable) but I am thinking of a more generic solution. 

The problem is with objects that request a specific initialization to be performed, other than [object init]
The auto-generated code of any object has something like
[[[NSObject alloc] init] autorelease] 
which is fine, but it is wrong with objects like UITableView which specifically request arguments in their initialization selector, which can not be changed afterwards (like the "style" property). 

What is done right now is to call once the generic "init" selector, and at later time call the more specific initWithFrame:style: selector.
Thus initializing the object twice!

In this specific case there doesn't seem to do any harm, but I have found out that in other cases, like UIWindow this might lead to serious problems!
Of course solving UIWindow was an easy task, just replace initWithFrame: with setFrame:  (since init was already called).

I am wondering though: is there any way to call the specific initWithXXX: function instead of the generic one?
Or, in other words, is it possible to avoid this double initialization of the object?


PS: I am massively creating a patch to avoid if possible all non-needed init selectors in the library, but this is just a convenient solution for special cases, not a generic one. 

Re: [xmlvm-users] Monster patches and GPL linking exception

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

Hi,

I think the solution for this is to communicate more on the mailing list, to
lay down the technical directions of the project. Right now everyone is
developing privately, then throws patches "over the wall". If we discussed
the approaches on the mailing list, then each of us would make less
duplicated efforts.

Of course, when you are under time pressure, to get an application working,
you have to go ahead on your private branch. In this case you take the risk
that your changes are never going to be merged.

Best Regards,
Gergely

2010/3/18 Panayotis Katsaloulis <pan...@pa...>

>
> On 18 Μαρ 2010, at 6:15 ΜΜ, Dr. Alexander K. Seewald wrote:
>
> ...
>
> > Currently it works like that: Wolfgang, Arno or Sascha ask me about
> > a specific functionality (currently it's audio recording), and I
>
> ....
> right, that's the key point:
> they "asked" you :)
>
>
> I know that it really is difficult to handle, but (as I said in
> previous posts), it is expected for a new project to have patches like
> these.
>
> Of course if such patch is not desirable, I could take it back and
> send, for example, only UIViewContoller, then tomorrow another object,
> and so forth :)
> But I believe the total effort then will be much much larger than now,
> since this whole patch has a common logic which at the end of the day
> will make evaluating it easier than to send one file at a time.
> Maybe it might seem too difficult, but it would be easier than to
> "divide and conquer" :)
>
>
>
> ------------------------------------------------------------------------------
> 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
>



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

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] Monster patches and GPL linking exception

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

I think I have to correct a little bit. Actually we did not ask for a  
particular functionality. In fact we asked for some corrections/ 
rewritings after reviewing patches. Some of that was necessary due to  
the integration of other patches. And that boils down to the problem  
of concurrent patches, which is being discussed.

-- Wolfgang

Sent from my iPhone

On 18.03.2010, at 17:49, Panayotis Katsaloulis  
<pan...@pa...> wrote:

>
> On 18 Μαρ 2010, at 6:15 ΜΜ, Dr. Alexander K. Seewald wrote:
>
> ...
>
>> Currently it works like that: Wolfgang, Arno or Sascha ask me about
>> a specific functionality (currently it's audio recording), and I
>
> ....
> right, that's the key point:
> they "asked" you :)
>
>
> I know that it really is difficult to handle, but (as I said in
> previous posts), it is expected for a new project to have patches like
> these.
>
> Of course if such patch is not desirable, I could take it back and
> send, for example, only UIViewContoller, then tomorrow another object,
> and so forth :)
> But I believe the total effort then will be much much larger than now,
> since this whole patch has a common logic which at the end of the day
> will make evaluating it easier than to send one file at a time.
> Maybe it might seem too difficult, but it would be easier than to
> "divide and conquer" :)
>
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> 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] Monster patches and GPL linking exception

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

On 18 Μαρ 2010, at 6:15 ΜΜ, Dr. Alexander K. Seewald wrote:

...

> Currently it works like that: Wolfgang, Arno or Sascha ask me about
> a specific functionality (currently it's audio recording), and I

....
right, that's the key point:
they "asked" you :)


I know that it really is difficult to handle, but (as I said in  
previous posts), it is expected for a new project to have patches like  
these.

Of course if such patch is not desirable, I could take it back and  
send, for example, only UIViewContoller, then tomorrow another object,  
and so forth :)
But I believe the total effort then will be much much larger than now,  
since this whole patch has a common logic which at the end of the day  
will make evaluating it easier than to send one file at a time.
Maybe it might seem too difficult, but it would be easier than to  
"divide and conquer" :)

[xmlvm-users] Monster patches and GPL linking exception

[Dr. A. K. S. <al...@se...>]

Hi,

I've also submitted "monster" patches in the past. The problem is
that XMLVM is evolving so fast that it is a major effort to resync
the patches, and in some cases it is not possible (e.g. the old way
to localize strings is not compatible with the new way, I had to
reimplement it basically from scratch). So I don't think it makes
sense to submit monster patches anymore, but rather self-contained
parts with significant functionality.

Currently it works like that: Wolfgang, Arno or Sascha ask me about
a specific functionality (currently it's audio recording), and I
resync that part of my code with SVN head, polish it, beat out the
memory management bugs and submit it. IMHO that is a better way to
go than monster patches because it allows the XMLVM team to pace the
development and do the things in the right order as they make sense.
A lot of ways to fix things are ad-hoc and not really useful for
anyone else (e.g. the way I've implemented ProgressDialog.. :->>)

I personally won't go away for a long time from my r953-synchronized
private patch set which allows me to cross-compile my app with a minimum
of hassle... which is what XMLVM is about for me.

Best,
  Alex
-- 
Dr. Alexander K. Seewald

Seewald Solutions
www.seewald.at
Tel. +43(664)1106886
Fax. +43(1)2533033/2764

Re: [xmlvm-users] pending patches

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

On 18 Μαρ 2010, at 4:36 ΜΜ, Sascha Haeberling wrote:

> Panayotis,
>
> I just saw your giant patch. Do you think you can split it up into  
> smaller chunks? The bigger a patch gets, the harder it is for us to  
> review it and the longer it will take. A patch at that size is very  
> impractical to handle.
>
> If you could split it up into smaller chunks, that would help speed  
> up the process a lot.
>
> Thanks

Yes I know it's a monstrous patch, " I told you so" ;-)

The problem is that I did an overall change in the compatibility  
library, by defining a couple of useful macros (basically have a look  
at the end of xmlvm.h) which affect most (if not all) of org_xmlvm_*  
files. This has to do with my previous question "who owns a returned  
object", if you remember.
Along with this, there are many many additions to already defined  
files that merge with these changes. And of course new files that  
follow the same rules. And all this is mirrored in Java, with the new  
methods only as placeholders for the actual Obj-C calls ( in other  
words, it doesn't work in the emulator - yet).

Thus the only practical way to "split" this patch is only to give some  
files at a time (i.e today give all files that start with A, then of  
B, then of C etc :P ) but I don't know how this will help the  
reviewing process :)

As I said in previous posts, instead of sending a couple of files  
every six months, I prefer to give as much as I can now,  make now  
this library strong and useful and help it spread out, instead of  
thinking of timeframes and when ( or better "if") my contribution will  
expire.


PS: I practically didn't touch (yet) the java_* files and apply these  
rules, since there should have also a look what java actually does  
(i.e. some exceptions should be thrown).

Re: [xmlvm-users] GPL and iPhone AppStore

[George S. <ge...@sn...>]

Thanks for the comments.

 

Re:

 

It is my understanding that the GPL is about the Personal freedom to see
what the developer is doing on YOUR machine and the ability to change that.

 

The GPL is about contributing code back to the OpenSource, if you make use
of GPL code yourself. It's nothing about looking at other people's machines
:)

 

Having read a fair amount of the history re Richard Stallman, it is my
understanding that it all originated with a closed-source print driver that
he needed to tweak.  It was not about contributing back (though that is
simply the civilized thing to do), but being able to control you own
destiny.  Part of that control was to limit exploitation of developers and
the work they author without any contribution back to the community.  And
yes, simple use is not exploitation.

 

Anyways, my $0.02, George

 

  _____  

From: sa...@gm... [mailto:sa...@gm...] On Behalf Of Sascha
Haeberling
Sent: Thursday, March 18, 2010 7:35 AM
To: ge...@sn...
Cc: xml...@li...
Subject: Re: [xmlvm-users] GPL and iPhone AppStore

 

I didn't see a question in you e-mail, but I try to comment on what you say:

On Thu, Mar 18, 2010 at 2:49 PM, George Smith <ge...@sn...> wrote:


We (I and my two partners) are new to xmlvm and have not YET submitted any
patches, but intend to.

It is my understanding that the GPL is about the Personal freedom to see
what the developer is doing on YOUR machine and the ability to change that.

 

The GPL is about contributing code back to the OpenSource, if you make use
of GPL code yourself. It's nothing about looking at other people's machines
:)

 


No place, to my knowledge, does the GPL say that the developer must help (or
even facilitate) others redistributing the application.

 

No, GPL doesn't say that.

 


Currently, all the apps we plan on creating are going to be free, and
therefore we have no concern of an unscrupulous development org under
cutting us by simply taking the code we will publish and redistributing the
app at a lower price.

 

If you plan to OpenSource the apps you are generating using XMLVM, that
don't worry about anything, you can just do so. :)

 

// Sascha

 


George



----------------------------------------------------------------------------
--
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] pending patches

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

Panayotis,

I just saw your giant patch. Do you think you can split it up into smaller
chunks? The bigger a patch gets, the harder it is for us to review it and
the longer it will take. A patch at that size is very impractical to handle.

If you could split it up into smaller chunks, that would help speed up the
process a lot.

Thanks
// Sascha

On Thu, Mar 18, 2010 at 1:55 PM, Panayotis Katsaloulis <
pan...@pa...> wrote:

> Hello again!
>
> I've sent my current patch for review in the usual places.
>
> One thing I have in mind is that I see that there is some duplicate
> work done by me and  Gergely (and probably others?).
> The problem is not only the duplicate work and waste of time and
> resources, but it would also be difficult to merge things like this.
>
> I really know that the core xmlvm developers have very limited (free)
> time (as we all have).
> I believe though that, since xmlvm is still in the beginning, patches
> of this size (like mine and Gergely) are possible to come all the
> time. If the project was mature, then conflicts like this would be
> more seldom.
>
> To avoid this confusion the only thing could be done is rather faster
> review progress.
> I know that you want to keep the code quality into high levels, and
> time is sparse, but I believe this is also a priority for this
> project...
>
>
> ------------------------------------------------------------------------------
> 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

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

I didn't see a question in you e-mail, but I try to comment on what you say:

On Thu, Mar 18, 2010 at 2:49 PM, George Smith <ge...@sn...> wrote:

>
> We (I and my two partners) are new to xmlvm and have not YET submitted any
> patches, but intend to.
>
> It is my understanding that the GPL is about the Personal freedom to see
> what the developer is doing on YOUR machine and the ability to change that.
>

The GPL is about contributing code back to the OpenSource, if you make use
of GPL code yourself. It's nothing about looking at other people's machines
:)


>
> No place, to my knowledge, does the GPL say that the developer must help
> (or
> even facilitate) others redistributing the application.
>

No, GPL doesn't say that.


>
> Currently, all the apps we plan on creating are going to be free, and
> therefore we have no concern of an unscrupulous development org under
> cutting us by simply taking the code we will publish and redistributing the
> app at a lower price.
>

If you plan to OpenSource the apps you are generating using XMLVM, that
don't worry about anything, you can just do so. :)

// Sascha


>
> George
>
>
>
>
> ------------------------------------------------------------------------------
> 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] GPL and iPhone AppStore

[George S. <ge...@sn...>]

We (I and my two partners) are new to xmlvm and have not YET submitted any
patches, but intend to.

It is my understanding that the GPL is about the Personal freedom to see
what the developer is doing on YOUR machine and the ability to change that.

No place, to my knowledge, does the GPL say that the developer must help (or
even facilitate) others redistributing the application.

Currently, all the apps we plan on creating are going to be free, and
therefore we have no concern of an unscrupulous development org under
cutting us by simply taking the code we will publish and redistributing the
app at a lower price.

George

[xmlvm-users] pending patches

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

Hello again!

I've sent my current patch for review in the usual places.

One thing I have in mind is that I see that there is some duplicate  
work done by me and  Gergely (and probably others?).
The problem is not only the duplicate work and waste of time and  
resources, but it would also be difficult to merge things like this.

I really know that the core xmlvm developers have very limited (free)  
time (as we all have).
I believe though that, since xmlvm is still in the beginning, patches  
of this size (like mine and Gergely) are possible to come all the  
time. If the project was mature, then conflicts like this would be  
more seldom.

To avoid this confusion the only thing could be done is rather faster  
review progress.
I know that you want to keep the code quality into high levels, and  
time is sparse, but I believe this is also a priority for this  
project...

Re: [xmlvm-users] GPL and iPhone AppStore

[Tor L. <tm...@ik...>]

> Is anyone on this list able to clear up whether or not GPL'd apps are
> legally valid on the App Store?

First you should make it clear whether you mean GPL version 2 or
version 3. I won't bother considering version 3 at all here as it is
much more restrictive, or enforces much more "freedom" if you see it
from that point of view.

GPLv2 apps are of course legally valid on the App Store.

The interesting question is whether you can take code somebody *else*
holds the copyright to, and without their consent (or perhaps even
against their expressed wish) redistribute it in binary form through
the App Store. (I think you could, but I am certainly not going to
try.)

Of course, you would have to provide all source code to those who
receive the App, either by bundling the sources inside the app (if
feasible) and providing a means to extract it, or by providing a
"written offer". That is not what is unclear.

The potential problem is that it will take quite some effort for the
those who get the app from the App Store to make use of their right to
modify and redistribute it (and if they modify it in some utterly
trivial way, but add something that Apple doesn't approve of, they
won't be able to, except using the "ad hoc" schemes to a limited
number of recipients).

For this reason I personally wouldn't dream of taking random GPL or
LGPL code, no matter how widespread, no matter how many individuals
hold the copyright to it, and use it in something distributed through
the App Store without asking for permission first.

(In fact, it is *more* "risky" to use code that has a lot of copyright
holders without asking, as it makes it more likely that at least one
of them is a jerk and starts raising hell.)

Finally, one thing to keep in mind when pondering these questions is
that the GPLv2 was written in 1991. Back then the normal OSes most
GPL software ended up being run on were quite proprietary ones. They
did not necessarily come with any compiler bundled at all. Compilers
were costly extras. The GPLv2 as such must thus a priori be totally
fine with that situation, as it was the situation when it was
carefully written.

But the situation with the App Store is still quite different, as it
is a distribution channel with mandatory arbitrary "censorship"
enforced.

> but nothing definitive or from a lawyer.

Oh, you have misunderstood. A lawyer (which I am not) is somebody who
can give real legal *advice*, but that is just that, advice. For
definiteness you need a court  ruling ;)

--tml

Re: [xmlvm-users] GPL and iPhone AppStore

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

at this point it is easy to detect.   :-)   With enough effort we can 
probably detect even if someone tries to conceal the fact they are using 
XMLVM. But in principle we rely on the honesty of developers/companies. 
The whole discussion on this mailing list is an indication of this 
honesty. Of course there are cases where the GPL has been violated. 
There are actually some famous cases. There is a web site dedicated to 
this: http://gpl-violations.org/ As far as I know, those cases that have 
become known, the perpetrator was put under so much pressure (bad press) 
that they eventually complied to the GPL.

Arno


On 3/17/10 9:23 AM, Andrea Paiano wrote:
> 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
>>
>>
>
> ------------------------------------------------------------------------------
> 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