You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(29) |
Aug
(75) |
Sep
(32) |
Oct
(147) |
Nov
(31) |
Dec
(49) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(46) |
Feb
(35) |
Mar
(148) |
Apr
(33) |
May
(53) |
Jun
(46) |
Jul
(60) |
Aug
(44) |
Sep
(135) |
Oct
(23) |
Nov
(68) |
Dec
(42) |
2011 |
Jan
(94) |
Feb
(55) |
Mar
(114) |
Apr
(78) |
May
(64) |
Jun
(10) |
Jul
(31) |
Aug
(2) |
Sep
(25) |
Oct
(13) |
Nov
(8) |
Dec
(24) |
2012 |
Jan
(5) |
Feb
(33) |
Mar
(31) |
Apr
(19) |
May
(24) |
Jun
(23) |
Jul
(14) |
Aug
(15) |
Sep
(12) |
Oct
(3) |
Nov
(4) |
Dec
(19) |
2013 |
Jan
(8) |
Feb
(20) |
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(4) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Arno P. <ar...@pu...> - 2010-03-25 13:28:18
|
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® 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® 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 |
From: Arno P. <ar...@pu...> - 2010-03-25 13:25:12
|
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 |
From: Arno P. <ar...@pu...> - 2010-03-25 13:02:05
|
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® 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® 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 |
From: Arno P. <ar...@pu...> - 2010-03-25 11:37:01
|
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 |
From: Panayotis K. <pan...@pa...> - 2010-03-23 23:12:22
|
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 |
From: Panayotis K. <pan...@pa...> - 2010-03-23 17:29:22
|
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 |
From: Tor L. <tm...@ik...> - 2010-03-23 16:15:05
|
> 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 |
From: Panayotis K. <pan...@pa...> - 2010-03-23 15:28:14
|
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. |
From: Dr. A. K. S. <al...@se...> - 2010-03-22 11:02:27
|
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 |
From: Gergely K. <ger...@ma...> - 2010-03-21 14:10:46
|
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® 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 |
From: Sascha H. <sa...@xm...> - 2010-03-21 12:48:03
|
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® 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 > > |
From: Panayotis K. <pan...@pa...> - 2010-03-21 12:40:53
|
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. |
From: Gergely K. <ger...@ma...> - 2010-03-20 09:33:22
|
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® 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 |
From: Gergely K. <ger...@ma...> - 2010-03-20 09:21:15
|
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 |
From: Wolfgang K. <wol...@xm...> - 2010-03-18 17:54:48
|
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® 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 |
From: Panayotis K. <pan...@pa...> - 2010-03-18 16:49:37
|
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" :) |
From: Dr. A. K. S. <al...@se...> - 2010-03-18 16:15:30
|
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 |
From: Panayotis K. <pan...@pa...> - 2010-03-18 16:03:38
|
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). |
From: George S. <ge...@sn...> - 2010-03-18 15:51:53
|
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® 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 |
From: Sascha H. <sa...@xm...> - 2010-03-18 14:37:23
|
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® 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 > |
From: Sascha H. <sa...@xm...> - 2010-03-18 14:35:47
|
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® 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 > |
From: George S. <ge...@sn...> - 2010-03-18 13:49:12
|
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 |
From: Panayotis K. <pan...@pa...> - 2010-03-18 12:55:17
|
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... |
From: Tor L. <tm...@ik...> - 2010-03-17 18:15:28
|
> 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 |
From: Arno P. <ar...@pu...> - 2010-03-17 17:53:40
|
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® 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® 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 |