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: Andrea P. <and...@gm...> - 2010-03-17 16:23:21
|
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 > > |
From: Panayotis K. <pan...@pa...> - 2010-03-17 15:49:05
|
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) |
From: Panayotis K. <pan...@pa...> - 2010-03-17 15:45:42
|
On 17 Μαρ 2010, at 4:29 ΜΜ, Arno Puder wrote: > > > On 3/17/10 7:06 AM, Panayotis Katsaloulis wrote: >> So, practically that's my original question: a client comes and asks >> me to write an application for them (and that's a real scenario). >> I write the application, I compile it and I upload it to app store. >> With this new aspect, there is no need for the client to purchase >> XMLVM, right? >> >> If of course they want the complete source code and they want to make >> changes to it and submit them to the app store, *then* they need the >> license. In any other case they don't. >> That's my interpretation of what you say. >> Is it correct? > > Yes. > >> I couldn't agree more with Gergely. >> >> You can not really weight "early" or "heavy" patches, since they >> exponentially help the project to evolve and/or to explode. > > I guess I really did a lot of harm with mentioning the 6 months. As I > mentioned numerous times now, the length of the linking exception will > depend on the significance of your contribution. If I understand you > correctly with what you've written in the remainder of your message, > some contributions warrant an unlimited linking exception. Is that > what > you have in mind? Would that solve your headaches? Both of these key points are much much better and clearer now, and better address issues with early contributions and/or large important & significant contributions which do not "expire". Thank you, Arno. I still don't feel comfortable though that the library is under GPL, but I can't think of any other way for you to make money for your ideas and efforts right now, so I'll be silent for this issue at the moment ;) |
From: Steven G. <st...@ma...> - 2010-03-17 15:41:48
|
Is anyone on this list able to clear up whether or not GPL'd apps are legally valid on the App Store? We've done some searching and found a number of blogs (http://diveintomark.org/archives/2008/03/07/iphone-gpl, http://stackoverflow.com/questions/762498/iphone-and-gpl, http://plasmasturm.org/log/512/, and http://www.geoffeg.org/wordpress/2009/10/07/the-iphone-and-the-gpl-v2-are-not-incompatible/) discussing it with varied conclusions, but nothing definitive or from a lawyer. This obviously has great implications on the suitability of xmlvm under its current licence for porting code to Objective-C for iPhone. Thanks |
From: Sascha H. <sa...@xm...> - 2010-03-17 15:19:54
|
I would like add on top of what Arno said, that the 6 months is really nothing we decided on inside the core team. And I agree, with you Gergely and Panayotis, that any fixed time period would harm XMLVM as contributors might delay submitting patches this way in order to get another 6 months. So, forget about 6 months :) I think, for people that continuously help the project, like the two of you did and hopefully will do, there should be an ever-expanding time period and you shouldn't have to wait until the current one expires. Example: You submit a patch and we agree on a linking exception for XX months. After a week you have another patch of the same size. Then I think it is reasonable to add XX months to the expiration date. Is that something that makes sense? Also, if you say you have a monster patch, and let's assume we choose to accept it in the project, then this time period could really be extremely long so that it essentially goes to infinity for practical purposes. But I think you agree, that somebody who contributes a lot less, should be limited in the use of the linking exception, but should still benefit from it, but for a shorter period of time. // Sascha On Wed, Mar 17, 2010 at 3:29 PM, Arno Puder <ar...@pu...> wrote: > > > On 3/17/10 7:06 AM, Panayotis Katsaloulis wrote: > > So, practically that's my original question: a client comes and asks > > me to write an application for them (and that's a real scenario). > > I write the application, I compile it and I upload it to app store. > > With this new aspect, there is no need for the client to purchase > > XMLVM, right? > > > > If of course they want the complete source code and they want to make > > changes to it and submit them to the app store, *then* they need the > > license. In any other case they don't. > > That's my interpretation of what you say. > > Is it correct? > > Yes. > > > I couldn't agree more with Gergely. > > > > You can not really weight "early" or "heavy" patches, since they > > exponentially help the project to evolve and/or to explode. > > I guess I really did a lot of harm with mentioning the 6 months. As I > mentioned numerous times now, the length of the linking exception will > depend on the significance of your contribution. If I understand you > correctly with what you've written in the remainder of your message, > some contributions warrant an unlimited linking exception. Is that what > you have in mind? Would that solve your headaches? > > Arno > > > ------------------------------------------------------------------------------ > Download Intel® 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-17 14:37:55
|
On 3/17/10 7:06 AM, Panayotis Katsaloulis wrote: > So, practically that's my original question: a client comes and asks > me to write an application for them (and that's a real scenario). > I write the application, I compile it and I upload it to app store. > With this new aspect, there is no need for the client to purchase > XMLVM, right? > > If of course they want the complete source code and they want to make > changes to it and submit them to the app store, *then* they need the > license. In any other case they don't. > That's my interpretation of what you say. > Is it correct? Yes. > I couldn't agree more with Gergely. > > You can not really weight "early" or "heavy" patches, since they > exponentially help the project to evolve and/or to explode. I guess I really did a lot of harm with mentioning the 6 months. As I mentioned numerous times now, the length of the linking exception will depend on the significance of your contribution. If I understand you correctly with what you've written in the remainder of your message, some contributions warrant an unlimited linking exception. Is that what you have in mind? Would that solve your headaches? Arno |
From: Panayotis K. <pan...@pa...> - 2010-03-17 14:06:35
|
Due to the length of this reply, let me leave out some not so "significant" parts. On 17 Μαρ 2010, at 3:22 ΜΜ, Arno Puder wrote: > If you build a product for a client, the client pays you for that > service but they are *not* using XMLVM. So, they do not need to apply > for a linking exception. I really like the way you expressed it now. So, practically that's my original question: a client comes and asks me to write an application for them (and that's a real scenario). I write the application, I compile it and I upload it to app store. With this new aspect, there is no need for the client to purchase XMLVM, right? If of course they want the complete source code and they want to make changes to it and submit them to the app store, *then* they need the license. In any other case they don't. That's my interpretation of what you say. Is it correct? I think a model like this is more practical, useful and has a real meaning than the previous answer "Either you or the company are the recipient of the linking exception, but not both of you." >> 4. The current license strategy encourages minimal contributions >> With this 6 month time limit, contributors are not encouraged to >> contribute as much as they can. Instead they are encouraged to >> contribute the "minimal amount necessary", and then to contribute a >> small amount again, when their linking exception runs out. Even if >> they >> are required to release all their changes under the GPL (see next >> point), these code dumps cannot be used in XMLVM, because they were >> not >> contributed to the project. >> >> I think this hurts the XMLVM project as a whole, including the Core >> Team >> and any current and potential contributors. > > I should not have mentioned the 6 months. As I already pointed out > in my > original post, patches come in very different quality. This will be > reflected in the time period. You indicated several times that you are > sitting on a monster patch. Of course that will be acknowledged very > differently than someone adding a few lines of code to XMLVM. I couldn't agree more with Gergely. You can not really weight "early" or "heavy" patches, since they exponentially help the project to evolve and/or to explode. The reason we are talking for the iPhone compatibility library is just because there is already some work on it. If a newcomer comes and see that no library is present, they will not bother at all. If on the contrary they see that the library is there, they will have a go, and probably make some contributions back. So a small patch "early" could be in the long run more important than a big patch "later on". Moreover, Gergely is right. I have already a monster patch pending (just like I had a similar monster patch a couple of months ago). By defining any time period this is a kill for me. My will is to send it right now, and intergrade it as is (like in the past). I could cut it in pieces of course and send a piece every 6 months, but I don't like that. By defining any type of fixed time-point, you discourage me (and probably all others) to send really serious patches. And it is not only that. Since now it is still "early" (and that's why I could still create patches like this), as I said before, this will help the exponential grow of XMLVM. I wish this project to succeed and I understand that you want to *protect* yourselves from companies who would say "have a 10-line patch and grand me lifetime linking exemption". But on the other hand, I believe that us, the early adopters and helpers, should not be constrained by any time period, since we are helping *you* make (and sell) this great tool. Or else the community (which means us) I think they'll be discouraged and the growth of XMLVM will be as slow as you (the core team) can write code. >> 6. Very asymmetric relationship between the Core Team and the >> contributors >> ... >> By the time XMLVM becomes mature, the current contributors will >> have no >> valid linking exceptions, so they will need to buy a commercial >> license...for something that they in part (and it is a significant >> part, >> because they received a linking exception for it) created. >> And there is no say how much will a commercial license cost then. We >> don't know who will be in control of the project. >> > > You have invested weeks, perhaps months into the development in XMLVM. > We have invested years (I personally since 2002). There is no > asymmetry > between the core team and contributors. We cannot sell XMLVM because > you > still have the copyright of your work. With the linking exception you > can do the same as we do: offer services to your clients. Again: the > length of the linking exception will reflect the value of your > contribution, but that will be done in context with what everyone else > has contributed. That's exactly my point, couldn't be expressed more clearly: "By the time XMLVM becomes mature, the current contributors will have no valid linking exceptions". Of course you have invested (and you will invest) more time than us to create this project, but don't forget that *you* own the project, and more importantly you are able to give it as a product any way you like. We can't. To say the truth, although I totally understand your point of view and your will to stay with a GPL-ed compatibility library (since this is the only way I know to force anybody to pay for it), I don't feel comfortable with it. Of course the compiler and all other tools could be with any license you like. But I still feel "jailed" with a GPL library without a linking exception by default (or a LGPL or an Apache license or whatever) . And this makes me reluctant on sending patches and improvements for this library, except if I really *have* to. I have to remind you that, if the "fun" goes away from this project, I (or should I say "we") will go back and code in Objective C again, or get a linking exemption now, make my own fork and go on from this time point. My strongest motivation though is that it happens to me to like this project and I am willing to help this project succeed. |
From: Arno P. <ar...@pu...> - 2010-03-17 13:23:20
|
Gergely, thanks for your feedback. Let me address each of your issues one-by-one. A lot to read but please pay special attention to the end of the mail. > 1. The current state (maturity) of XMLVM > Although XMLVM is improving rapidly (thanks to both the core team and > also to the dedicated external contributors), it is not a mature product > yet. The Core Team seems to acknowledge this in the licensing strategy > by not specifying a release cycle, instead of using exclusively a time > based model. > > Realistically, if you want to use XMLVM currently for anything serious, > you will have to "pop the hood", and start developing into the runtime > library the missing parts that you are using. My optimistic estimate is > that it will take at least 1.5 - 2 years for this situation to change, > when you can take a non-trivial Java/Android program, and it will output > a reasonably well working Objective-C/Iphone version. > > However, the current licensing proposal means that those who make the > essential contributions now (like implementing java_lang_String methods > ... etc.) that led to the mature XMLVM will be in the same position as > any newcomer. Their linking exceptions will have long run out by then. > The problem is, that this asymmetry is not solved by simply extending > the length of the linking exception. Of course there is still a lot of work that needs to be done in XMLVM. However, I disagree with you that it will take 1.5 - 2 years for XMLVM to become usable. We are currently wrapping up a project for a customer where we use XMLVM. Even when all the Android API is covered (which may take the 1-2 years you mentioned), there are still many other things that can be done. We are currently thinking of implementing the Java Debugging Protocol inside the Apple Emulator. We are also considering to allow hybrid applications where you can use an Android layout manager to lay out an iPhone widget. Innovation will never stop. Even right now XMLVM is usable for certain applications and a "newcomer" can benefit right now from the work that has gone into XMLVM since 2002 (the founding year of XMLVM). > > 2. Unclear legal status of the project > When we are signing the CLA, we are signing the rights to "XMLVM". This > issue has been brought up last year on this list. Right now it is not > clear, who is XMLVM? Is there a commercial entity? Is it the 3 Core Team > members? Who will "own" the code, that is contributed? Who will grant > the commercial licenses? > The core team members work at large software companies / US universities. > It is not clear if these entities have any legal basis of "taking > XMLVM", and saying that the previous "linking exceptions" are invalid, > and starts to sue the users of XMLVM. This all depends on the work > contracts of the core team members, and also the relevant US and EU laws. > > I know that this seems like a slim chance right now, but stranger things > have happened, especially when there is money involved. By signing the CLA electronically, you only give us the right to use your patch. You still retain the copyright of your work. It is correct that XMLVM is not a legal entity and when I refer to XMLVM, I mean the core team. Would it help you if XMLVM incorporated in California? If I remember correctly, you are located in Eastern Europe. We cannot create companies all over the world to accommodate each national law. A developer on SourceForge must choose an Open Source license. The license spells out the rules, without the developer having to register a company. In that sense we do the same, except that we add the linking exception in return for a contribution (which, btw, is also not a new idea. Look on Wikipedia). Its a cheap man's commercial license, but I'd rather do that than charge $50.000 for a proper commercial license so we can pay the legal bills. > 3. Absence of a real commercial license > Since the linking exception is non-transferrable, essentially, our > clients will have to somehow obtain a commercial license (In many cases > you also have to deliver the source code and all necessary tools to your > clients.) It is not realistic, that each of those clients will be able > to do a contribution. Also, as the project matures, it will be harder > and harder to contribute something that is valuable enough for a linking > exception. It is also "funny": You take a future, mature XMLVM version, > it works flawlessly for your project, but then you have to go and > implement something completely irrelevant to your project, just to get a > linking exception. > > This was also brought up earlier, and then the Core Team mentioned > something about 2-300 USD for a linking exception license, but the > specific details were never really worked out. If you build a product for a client, the client pays you for that service but they are *not* using XMLVM. So, they do not need to apply for a linking exception. I acknowledge that some clients require you to deliver source code of your work and the ability to re-compile the application (which means that they need XMLVM). If you use a commercial tool to build the application for your client (lets say, a modeling tool), your client will also need to buy a commercial license for this modeling tool if they want to re-compile the application themselves, right? > 4. The current license strategy encourages minimal contributions > With this 6 month time limit, contributors are not encouraged to > contribute as much as they can. Instead they are encouraged to > contribute the "minimal amount necessary", and then to contribute a > small amount again, when their linking exception runs out. Even if they > are required to release all their changes under the GPL (see next > point), these code dumps cannot be used in XMLVM, because they were not > contributed to the project. > > I think this hurts the XMLVM project as a whole, including the Core Team > and any current and potential contributors. I should not have mentioned the 6 months. As I already pointed out in my original post, patches come in very different quality. This will be reflected in the time period. You indicated several times that you are sitting on a monster patch. Of course that will be acknowledged very differently than someone adding a few lines of code to XMLVM. > 5. It is still not clear what the linking exception will allow and what not > I was actually pretty surprised when in a later email Arno wrote, that > even if you have the linking exception, you have to release any changes > you make in XMLVM under the GPL. Clearly, the Core Team has a very > different notion of what the linking exception allows, than us (MattaKis > Consulting), and this gets us back to the "Unclear legal status" and the > "Absence of commercial license" points. I do think this is very clear. XMLVM is under GPL license and the linking exception takes away the viral component so that you do not have to Open Source your own proprietary app. Otherwise the GPL still applies to XMLVM and therefore any further modifications you do to XMLVM need to be made available. > 6. Very asymmetric relationship between the Core Team and the contributors > > The contributors have to grant all rights to the XMLVM project, more > specifically the Core Team. This means that the Core Team is free to > change the license of the project, sell the project to the highest > bidder ... etc. > > At the same time, the contributors get only a limited time > non-transferrable "license exception". > > This is already an issue now (judging from the many questions regarding > transferrability ... etc.), but in 1 - 2 years, when XMLVM will be a > mature project, and will worth much more than currently, it will be a > huge issue. > > The current contributors are adding significant value to the project, > and that value will still be used then. It is unrealistic that the > essential runtime features that we are working on now are going to be > thrown out: you cannot do it too much differently. The contributors are > doing everything from alpha- and beta-testing, to adding essential > features and to participating in design discussions here on the mailing > list which form the direction of XMLVM significantly. > > By the time XMLVM becomes mature, the current contributors will have no > valid linking exceptions, so they will need to buy a commercial > license...for something that they in part (and it is a significant part, > because they received a linking exception for it) created. > And there is no say how much will a commercial license cost then. We > don't know who will be in control of the project. > You have invested weeks, perhaps months into the development in XMLVM. We have invested years (I personally since 2002). There is no asymmetry between the core team and contributors. We cannot sell XMLVM because you still have the copyright of your work. With the linking exception you can do the same as we do: offer services to your clients. Again: the length of the linking exception will reflect the value of your contribution, but that will be done in context with what everyone else has contributed. > My proposal: [...] > - Keep the current dual licensing scheme for the compiler. As far as I > know the code generated by the compiler is still GPL - so you need a > commercial license for using it in commercial project. I am not a lawyer > -- if this is not the case, then you might consider changing the > compiler license accordingly. no. this is not correct. Look at gcc. gcc is GPLed and you can use it for commercial applications. The only way to do dual licensing is by having a restrictive license on the libraries. BOTTOM LINE: I think what this whole thing boils down to is that you feel that your contribution is not valued enough. I do believe that we can address this with the length of the linking exception (I really don't want to spend big bucks on a lawyer to come up with a commercial license which probably will be more restrictive and also most likely would require you to transfer copyright). Forget the 6 months, ok? Show us what you've got and I'm sure we'll grant you a significantly longer time period. Remember that XMLVM is more than just code. There is also a certain skill set and credibility you gain by participating early on and I'm sure you will be able to leverage that. Arno |
From: Gergely K. <ger...@ma...> - 2010-03-17 11:49:25
|
Hi, Thank you for sharing / clarifying your licensing strategy with us. We at MattaKis Consulting have been working on improving XMLVM in order to enable us using it in real projects. We have already contributed a pretty large set of patches, and more patches are in the works internally. Unfortunately, we have some major concerns with the current licensing strategy. 1. The current state (maturity) of XMLVM Although XMLVM is improving rapidly (thanks to both the core team and also to the dedicated external contributors), it is not a mature product yet. The Core Team seems to acknowledge this in the licensing strategy by not specifying a release cycle, instead of using exclusively a time based model. Realistically, if you want to use XMLVM currently for anything serious, you will have to "pop the hood", and start developing into the runtime library the missing parts that you are using. My optimistic estimate is that it will take at least 1.5 - 2 years for this situation to change, when you can take a non-trivial Java/Android program, and it will output a reasonably well working Objective-C/Iphone version. However, the current licensing proposal means that those who make the essential contributions now (like implementing java_lang_String methods ... etc.) that led to the mature XMLVM will be in the same position as any newcomer. Their linking exceptions will have long run out by then. The problem is, that this asymmetry is not solved by simply extending the length of the linking exception. 2. Unclear legal status of the project When we are signing the CLA, we are signing the rights to "XMLVM". This issue has been brought up last year on this list. Right now it is not clear, who is XMLVM? Is there a commercial entity? Is it the 3 Core Team members? Who will "own" the code, that is contributed? Who will grant the commercial licenses? The core team members work at large software companies / US universities. It is not clear if these entities have any legal basis of "taking XMLVM", and saying that the previous "linking exceptions" are invalid, and starts to sue the users of XMLVM. This all depends on the work contracts of the core team members, and also the relevant US and EU laws. I know that this seems like a slim chance right now, but stranger things have happened, especially when there is money involved. 3. Absence of a real commercial license Since the linking exception is non-transferrable, essentially, our clients will have to somehow obtain a commercial license (In many cases you also have to deliver the source code and all necessary tools to your clients.) It is not realistic, that each of those clients will be able to do a contribution. Also, as the project matures, it will be harder and harder to contribute something that is valuable enough for a linking exception. It is also "funny": You take a future, mature XMLVM version, it works flawlessly for your project, but then you have to go and implement something completely irrelevant to your project, just to get a linking exception. This was also brought up earlier, and then the Core Team mentioned something about 2-300 USD for a linking exception license, but the specific details were never really worked out. 4. The current license strategy encourages minimal contributions With this 6 month time limit, contributors are not encouraged to contribute as much as they can. Instead they are encouraged to contribute the "minimal amount necessary", and then to contribute a small amount again, when their linking exception runs out. Even if they are required to release all their changes under the GPL (see next point), these code dumps cannot be used in XMLVM, because they were not contributed to the project. I think this hurts the XMLVM project as a whole, including the Core Team and any current and potential contributors. 5. It is still not clear what the linking exception will allow and what not I was actually pretty surprised when in a later email Arno wrote, that even if you have the linking exception, you have to release any changes you make in XMLVM under the GPL. Clearly, the Core Team has a very different notion of what the linking exception allows, than us (MattaKis Consulting), and this gets us back to the "Unclear legal status" and the "Absence of commercial license" points. 6. Very asymmetric relationship between the Core Team and the contributors The contributors have to grant all rights to the XMLVM project, more specifically the Core Team. This means that the Core Team is free to change the license of the project, sell the project to the highest bidder ... etc. At the same time, the contributors get only a limited time non-transferrable "license exception". This is already an issue now (judging from the many questions regarding transferrability ... etc.), but in 1 - 2 years, when XMLVM will be a mature project, and will worth much more than currently, it will be a huge issue. The current contributors are adding significant value to the project, and that value will still be used then. It is unrealistic that the essential runtime features that we are working on now are going to be thrown out: you cannot do it too much differently. The contributors are doing everything from alpha- and beta-testing, to adding essential features and to participating in design discussions here on the mailing list which form the direction of XMLVM significantly. By the time XMLVM becomes mature, the current contributors will have no valid linking exceptions, so they will need to buy a commercial license...for something that they in part (and it is a significant part, because they received a linking exception for it) created. And there is no say how much will a commercial license cost then. We don't know who will be in control of the project. My proposal: XMLVM has 2 major components for each source -> target permutation: 1. The compiler, which takes the input and generate the output for the target 2. The runtime library which implements the API for the platform to make the compiled code usable. >From what I have seen in the last months, the compiler itself is mostly worked on by the core team. We, the contributors, only touch it, when we have to fix a bug, or we need to put in a missing part for a feature of the runtime library. On the other hand, the runtime library has already received significant external contributions, and it is my estimate that this will only increase in the future. Now we have two components that cannot be used without the other. My suggestion is to: - Make the license of the runtime library (Java & Iphone API) more liberal, since it is written in a significant part by external contributors. - Keep the current dual licensing scheme for the compiler. As far as I know the code generated by the compiler is still GPL - so you need a commercial license for using it in commercial project. I am not a lawyer -- if this is not the case, then you might consider changing the compiler license accordingly. - When someone contributes to the library, you at your own discretion may or may not grant commercial license to the compiler. This way you sponsor the development of the libraries without actually using hard cash. - For those who cannot contribute for any reason, please offer a commercial license for a fee. (I am deliberatly not using the "linking exception", because I think it has become a way too ambiguous term.) - If someone contributes directly to the compiler, then the Core Team (or better yet, the commercial entity behind the project) would agree with them on a reasonable compensation (this can be also a specified number of commercial licenses, or later money). Of course it should be well documented how to negotiate (who to contact...etc.) such agreements ... etc. The advantage of this proposal is that it clearly separates the community developed parts, and the commercial parts of the project, while still taking the commercial interests of all parties into consideration. What do you think about all this? Best Regards, Gergely 2010/3/16 Arno Puder <ar...@pu...> [...] -- Kis Gergely MattaKis Consulting Email: ger...@ma... Web: http://www.mattakis.com Phone: +36 70 408 1723 Fax: +36 27 998 622 |
From: Arno P. <ar...@pu...> - 2010-03-17 07:02:50
|
On 3/17/10 4:33 AM, Mark Wolfskehl wrote: > I do have one additional comment regarding your view of the linking > exception: I believe that > the linking exception should also be applied to all "derived works" > created by the commercial developer > based on the code base for which the linking exception was granted. > At the very least, this allows > the commercial developer to include bug fixes, even if these are not > deemed "significant" by other standards. > They may also include contributions that do not seem "significant" to > the group but which are significant to the > commercial entity. I believe this would be a reasonable exception. Lets say we grant you a linking exception for a version of XMLVM. Your commercial product as well as further modifications to XMLVM can be viewed as "derived work". Since we give you a linking exception for XMLVM, your commercial product can remain closed source. However, XMLVM itself is still covered by the GPL which means any modification you make to XMLVM needs to be placed under the GPL. If I understand you correctly, your question is about this locally modified version of XMLVM. The linking exception also applies to this locally modified version. Since you have to release your bug fix under the GPL, we will integrate it back to the code base of XMLVM. Because we grant you the linking exception for a period of time, you can download the new official version of XMLVM and you will also be given the linking exception. > I appreciate your attitude of cooperation and desire to give-and- > take. That's what business is about, or at > least should be about. Thank you! :-) Arno |
From: Wolfgang K. <wol...@xm...> - 2010-03-17 06:39:09
|
Mark, thanks for sharing you thoughts about our CLA. You suggest to grant the CLA for all derived work based on the code base into which a contribution was integrated. As Arno pointed out earlier, usually a contribution gets never removed from XMLVM once we decided to accept and integrate a patch. That means, that all subsequent versions of XMLVM can be considered as "derived work" which implies that we should grant a CLA which is not limited in terms of time. Did I get you right? -- Wolfgang Mark Wolfskehl wrote: > Hi Arno, > > Thanks for answering here some of the questions I had sent to you > directly last week. > > I think the general direction of what you have proposed is reasonable. > I understand your interest in motivating others with commercial > interests to contribute to the project. > > I find the technology of XMLVM interesting in and of itself. My main > limitation is time, given that I work > for someone else full-time and can only work on my personal > commercial interests (or XMLVM) with the limited time > that is left. > > The main thing you are providing for commercial developers, I > believe, is savings of time - not having to > port an application from Android to the iPhone. So, as far as I am > concerned, if I spend roughly the same > amount of time working on XMLVM that I would have done directly for > an iPhone port of an Android application, > that's fine. I'd rather be doing something different than coding the > same thing a second time anyway. > And ostensibly that time savings adds up for the next product, etc. > > I do have one additional comment regarding your view of the linking > exception: I believe that > the linking exception should also be applied to all "derived works" > created by the commercial developer > based on the code base for which the linking exception was granted. > At the very least, this allows > the commercial developer to include bug fixes, even if these are not > deemed "significant" by other standards. > They may also include contributions that do not seem "significant" to > the group but which are significant to the > commercial entity. I believe this would be a reasonable exception. > > I appreciate your attitude of cooperation and desire to give-and- > take. That's what business is about, or at > least should be about. > > I look forward to the opportunity to work with all of you. My main > challenge will be to actually find the time > to do all the personal projects (including XMLVM) that I would like > to do, with the challenges of keeping > a full-time coding job. If any of you have any advice or suggestions > from personal experience regarding this, > I'm all ears. > > Regards, > Mark Wolfskehl, Ph.D. > |
From: Mark W. <ma...@ma...> - 2010-03-17 04:00:29
|
Hi Arno, Thanks for answering here some of the questions I had sent to you directly last week. I think the general direction of what you have proposed is reasonable. I understand your interest in motivating others with commercial interests to contribute to the project. I find the technology of XMLVM interesting in and of itself. My main limitation is time, given that I work for someone else full-time and can only work on my personal commercial interests (or XMLVM) with the limited time that is left. The main thing you are providing for commercial developers, I believe, is savings of time - not having to port an application from Android to the iPhone. So, as far as I am concerned, if I spend roughly the same amount of time working on XMLVM that I would have done directly for an iPhone port of an Android application, that's fine. I'd rather be doing something different than coding the same thing a second time anyway. And ostensibly that time savings adds up for the next product, etc. I do have one additional comment regarding your view of the linking exception: I believe that the linking exception should also be applied to all "derived works" created by the commercial developer based on the code base for which the linking exception was granted. At the very least, this allows the commercial developer to include bug fixes, even if these are not deemed "significant" by other standards. They may also include contributions that do not seem "significant" to the group but which are significant to the commercial entity. I believe this would be a reasonable exception. I appreciate your attitude of cooperation and desire to give-and- take. That's what business is about, or at least should be about. I look forward to the opportunity to work with all of you. My main challenge will be to actually find the time to do all the personal projects (including XMLVM) that I would like to do, with the challenges of keeping a full-time coding job. If any of you have any advice or suggestions from personal experience regarding this, I'm all ears. Regards, Mark Wolfskehl, Ph.D. I'll repeat here part of my personal introduction to Arno: http://www.linkedin.com/in/markwolfskehl I am currently working as a senior software engineer for SeaChange International, a producer of cable Video On Demand servers and clients. My programming background has been mainly in C++. I have done a large project in Prolog, and I am currently working full-time in Java SE. I have a Ph.D. granted in 2000 in computer science from Stevens Institute of Technology in Hoboken, NJ. I will include a link to my LinkedIn page. There isn't much mention there of my graduate background as it does not generally apply directly to the type of industry work I usually do (mainly highly multithreaded/logic intensive/algorithms work), but it is probably relevant to your project. My graduate work was heavily focused on theoretical computer science - computational complexity theory, proofs, formal methods, formal semantics of programming languages, and model checking. I have subsequently done some work utilizing a formal mathematics approach to algorithm development (only personal notes), in particular a speculative design for a heuristic solution to 3SAT - something that has been on the shelf for a long time and has never been prototyped. My Ph.D. advisor was Steve Bloom (Ph.D. in math from MIT), and I have worked with David Klappholz (he used to focus on compiler optimization). On Mar 16, 2010, at 1:55 PM, xmlvm-users- re...@li... wrote: > Send xmlvm-users mailing list submissions to > xml...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > or, via email, send a message with subject or body 'help' to > xml...@li... > > You can reach the person managing the list at > xml...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of xmlvm-users digest..." > > > Today's Topics: > > 1. Re: about org_xmlvm_iphone_AVAudioPlayer initialization > (Wolfgang Korn) > 2. Patches and broken SVN (Panayotis Katsaloulis) > 3. Re: Patches and broken SVN (Sascha Haeberling) > 4. Re: Patches and broken SVN (Sascha Haeberling) > 5. Clarifications on the Linking Exception (Arno Puder) > 6. Google TechTalk (Arno Puder) > 7. Re: Clarifications on the Linking Exception > (Panayotis Katsaloulis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 11 Mar 2010 20:08:58 +0100 > From: Wolfgang Korn <wol...@xm...> > Subject: Re: [xmlvm-users] about org_xmlvm_iphone_AVAudioPlayer > initialization > To: Panayotis Katsaloulis <pan...@pa...> > Cc: xml...@li... > Message-ID: <4B9...@xm...> > Content-Type: text/plain; charset=ISO-8859-1 > > Panayotis, > > I just checked the code you mentioned. I agree - retain shouldn't be > called. I committed this change to SVN. > > -- Wolfgang > > > Panayotis Katsaloulis wrote: >> in the initialization of "org_xmlvm_iphone_AVAudioPlayer.m", >> there is >> this code: >> >> return [[[AVAudioPlayer alloc] initWithContentsOfURL: url error: >> &(outError->error_org_xmlvm_iphone_NSError)] retain]; >> >> Why there is a need for a second retain there (the first is the alloc >> itself) ? >> >> --------------------------------------------------------------------- >> --------- >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> xmlvm-users mailing list >> xml...@li... >> https://lists.sourceforge.net/lists/listinfo/xmlvm-users >> > > > > > ------------------------------ > > Message: 2 > Date: Mon, 15 Mar 2010 19:16:12 +0200 > From: Panayotis Katsaloulis <pan...@pa...> > Subject: [xmlvm-users] Patches and broken SVN > To: xml...@li... > Message-ID: <AAC...@pa...> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Hello again! > > I'd decided to send you my latest patch with tons of improvements in > the obj-c compatibility layer. > But I've seen that the current SVN release is broken. > Can I just send the patches the usual way ? > > > > ------------------------------ > > Message: 3 > Date: Mon, 15 Mar 2010 18:22:54 +0100 > From: Sascha Haeberling <sa...@xm...> > Subject: Re: [xmlvm-users] Patches and broken SVN > To: Panayotis Katsaloulis <pan...@pa...> > Cc: xml...@li... > Message-ID: > <709...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > You can send us the well-commented and formatted patches the usual > way via > the review tool. > > I am currently taking a look at the breakage. > > // Sascha > > On Mon, Mar 15, 2010 at 6:16 PM, Panayotis Katsaloulis < > pan...@pa...> wrote: > >> Hello again! >> >> I'd decided to send you my latest patch with tons of improvements in >> the obj-c compatibility layer. >> But I've seen that the current SVN release is broken. >> Can I just send the patches the usual way ? >> >> >> --------------------------------------------------------------------- >> --------- >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> xmlvm-users mailing list >> xml...@li... >> https://lists.sourceforge.net/lists/listinfo/xmlvm-users >> > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 4 > Date: Mon, 15 Mar 2010 18:42:51 +0100 > From: Sascha Haeberling <sa...@xm...> > Subject: Re: [xmlvm-users] Patches and broken SVN > To: Panayotis Katsaloulis <pan...@pa...> > Cc: xml...@li... > Message-ID: > <709...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > FYI: Current HEAD should work again. > > // Sascha > > On Mon, Mar 15, 2010 at 6:22 PM, Sascha Haeberling > <sa...@xm...> wrote: > >> You can send us the well-commented and formatted patches the usual >> way via >> the review tool. >> >> I am currently taking a look at the breakage. >> >> // Sascha >> >> >> On Mon, Mar 15, 2010 at 6:16 PM, Panayotis Katsaloulis < >> pan...@pa...> wrote: >> >>> Hello again! >>> >>> I'd decided to send you my latest patch with tons of improvements in >>> the obj-c compatibility layer. >>> But I've seen that the current SVN release is broken. >>> Can I just send the patches the usual way ? >>> >>> >>> -------------------------------------------------------------------- >>> ---------- >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> xmlvm-users mailing list >>> xml...@li... >>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users >>> >> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 5 > Date: Tue, 16 Mar 2010 17:16:18 +0100 > From: Arno Puder <ar...@pu...> > Subject: [xmlvm-users] Clarifications on the Linking Exception > To: "xml...@li..." > <xml...@li...> > Message-ID: <4B9...@pu...> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Guys, > > there have been some questions regarding our licensing model. I would > like to take this opportunity to express our (i.e., the XMLVM Core > Team) > intent. Before I go into details, I want to point out that our goal is > to create a fair model that serves both the XMLVM Core Team as well as > contributors. We acknowledge that some of you are interested in using > XMLVM for commercial purposes. We ask you to acknowledge that we have > legitimate business interests as well. The goal is to find a balance > that works for all of us. XMLVM is and always will be Open Source. We > use the GPL license and as many of you know, this license is very > restrictive. The GPL license requires you to put your own source code > under the GPL license. If you are just doing Open Source work, this is > usually fine, however, if you want to develop commercial applications, > this is not acceptable for obvious reasons. That is where the idea of > dual licensing kicks in. We offer a second, commercial license, that > will allow you to develop proprietary products based on XMLVM. Note > that > the idea of dual licensing is not new. Projects such as MySQL and > JBoss > have been doing this for a long time. > > Our commercial license is a non-transferrable GPL Linking Exception > (or > just linking exception for short) that takes away the 'viral' > component > of the GPL. This means, if we grant you a linking exception, you are > *not* required to release your own application that is based on > XMLVM to > the Open Source. This linking exception is not transferrable. You > cannot > transfer this right to your customers. > > What is somewhat new with XMLVM is that we still want XMLVM to be a > community project. That means, we hope and encourage the community to > make contributions to XMLVM. It is important to us that we do not > leave > the perception of exploiting contributors via our commercial license. > For that reason we have come up with a way to 'reward' outside > contributors: If you make a (non-trivial) contribution to XMLVM, we > will > give you a commercial license (i.e., non-transferrable linking > exception) that will allow you to develop a commercial application > with > XMLVM without sharing your proceeds with us. > > Of course there are some details that need to be clarified and there > have been some questions on the mailing list regarding the details. > Let > us make a specific example: you send us a patch to XMLVM that is > non-trivial (lets not get into the discussion on what is a non-trivial > contribution. There is obviously no objective way of measuring the > quality of a contribution. We will make that call on a case-by-case > basis). If we (the XMLVM Core Team) agrees to merge your patch with > the > code base of XMLVM, we will give you a non-transferrable linking > exception in return. In terms of the scope of this non-transferrable > linking exception, there are several components: (1) to which > version of > XMLVM does the linking exception apply? (2) who is the recipient of > the > linking exception? (3) what is the duration of the linking exception? > Let me address these issues individually. > > (1) we do not maintain an official versioning scheme for XMLVM. Things > happen so fast in our code base that we do not plan to introduce > official version numbers. In the future we might change this, but for > now, we simply refer to the Subversion revision numbers. The linking > exception is issued for the version of XMLVM that includes the > contributors patch and any version of XMLVM released in the > following 6 > months. For really significant contributions we are willing to extend > that time frame. > > (2) the linking exception is issued to the contributor of the patch. > This can be an individual or the company for which the contributor > works. This will allow the individual/company to develop applications > that can be sold to their customers without having to share revenues > with the XMLVM Core Team. The linking exception *cannot* be > transferred > to the customers of the contributor. > > (3) for the versions of XMLVM for which we issue the linking > exception, > the usage is not limited to the aforementioned 6 months. I.e., 6 > months > after you made your contribution you may still use older versions of > XMLVM for commercial purposes. Only if you want to benefit from new > features introduced to XMLVM after those 6 months, you will need to > make > another contribution to XMLVM to extend the duration of the linking > exception. > > I would like to start a discussion with you guys on the mailing > list to > refine these rules. Again, we want to strike a balance between your > legitimate commercial interest and ours. > > Let me know what you think. > > Arno > > > > ------------------------------ > > Message: 6 > Date: Tue, 16 Mar 2010 17:26:18 +0100 > From: Arno Puder <ar...@pu...> > Subject: [xmlvm-users] Google TechTalk > To: "xml...@li..." > <xml...@li...> > Message-ID: <4B9...@pu...> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Guys, > > I was fortunate enough to get invited by Google to talk about XMLVM as > part of their TechTalk series. If you are interested, there is a > recording on YouTube: http://www.youtube.com/watch?v=TG-NIt2O5J8 > > Here is a link to the slides: > http://xmlvm.org/slides/android2iphone-google-mtv.pdf > > Arno > > > > > > ------------------------------ > > Message: 7 > Date: Tue, 16 Mar 2010 19:54:59 +0200 > From: Panayotis Katsaloulis <pan...@pa...> > Subject: Re: [xmlvm-users] Clarifications on the Linking Exception > To: xml...@li... > Message-ID: <6CA...@pa...> > Content-Type: text/plain; charset="us-ascii" > >> >> (3) for the versions of XMLVM for which we issue the linking >> exception, >> the usage is not limited to the aforementioned 6 months. I.e., 6 >> months >> after you made your contribution you may still use older versions of >> XMLVM for commercial purposes. Only if you want to benefit from new >> features introduced to XMLVM after those 6 months, you will need to >> make >> another contribution to XMLVM to extend the duration of the linking >> exception. > > > I'll comment at first this part, how long this exception will be. > > I don't believe this is fair enough. > I believe it is fair, if this exception will last as long as the patch > will last. > If you continue to use a specific patch (or in other terms, this patch > is useful to you), then I believe you should grand the linking > exception to the person who sent a patch (or in other words, you > should be useful to him). Moreover I think 6 months is a very limited > time period. Usually licenses last (at least) a year. > > And still, I have this question, which I posted in a previous post of > mine: > for example today I work in a company and I send a patch. In (let's > say) a month I go to another company. Can I still develop with xmlvm > or should I do something else (like making them to pay or send another > patch or whatever) ? > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > ---------------------------------------------------------------------- > -------- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > > ------------------------------ > > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > > End of xmlvm-users Digest, Vol 9, Issue 8 > ***************************************** |
From: Arno P. <ar...@pu...> - 2010-03-16 18:12:38
|
On 3/16/10 6:54 PM, Panayotis Katsaloulis wrote: > I don't believe this is fair enough. > I believe it is fair, if this exception will last as long as the patch > will last. > If you continue to use a specific patch (or in other terms, this patch > is useful to you), then I believe you should grand the linking exception > to the person who sent a patch (or in other words, you should be useful > to him). Moreover I think 6 months is a very limited time period. > Usually licenses last (at least) a year. Once a patch is applied, it is usually never removed anymore. We see a patch as a contribution that gives you access to a certain number of updates. But that does not mean that you get unlimited updates. The same is true for any software license that you purchase. I mentioned 6 months in my mail. That is just a ballpark figure. Patches that come in are of very different quality and scope. I think it is fair to discuss the length of the period based on an individual contribution. And as I already indicated, if the contribution is significant, we are of course willing to extend the time period. > And still, I have this question, which I posted in a previous post of mine: > for example today I work in a company and I send a patch. In (let's say) > a month I go to another company. Can I still develop with xmlvm or > should I do something else (like making them to pay or send another > patch or whatever) ? Either you or the company are the recipient of the linking exception, but not both of you. If the company is the recipient and you leave the company, then you cannot do commercial products based on XMLVM anymore. If you are the recipient, you can build products which the company (or anyone else) may use (after paying you). But in that case the company has no right to build applications with XMLVM. Arno |
From: Panayotis K. <pan...@pa...> - 2010-03-16 17:55:10
|
> > (3) for the versions of XMLVM for which we issue the linking > exception, > the usage is not limited to the aforementioned 6 months. I.e., 6 > months > after you made your contribution you may still use older versions of > XMLVM for commercial purposes. Only if you want to benefit from new > features introduced to XMLVM after those 6 months, you will need to > make > another contribution to XMLVM to extend the duration of the linking > exception. I'll comment at first this part, how long this exception will be. I don't believe this is fair enough. I believe it is fair, if this exception will last as long as the patch will last. If you continue to use a specific patch (or in other terms, this patch is useful to you), then I believe you should grand the linking exception to the person who sent a patch (or in other words, you should be useful to him). Moreover I think 6 months is a very limited time period. Usually licenses last (at least) a year. And still, I have this question, which I posted in a previous post of mine: for example today I work in a company and I send a patch. In (let's say) a month I go to another company. Can I still develop with xmlvm or should I do something else (like making them to pay or send another patch or whatever) ? |
From: Arno P. <ar...@pu...> - 2010-03-16 16:26:35
|
Guys, I was fortunate enough to get invited by Google to talk about XMLVM as part of their TechTalk series. If you are interested, there is a recording on YouTube: http://www.youtube.com/watch?v=TG-NIt2O5J8 Here is a link to the slides: http://xmlvm.org/slides/android2iphone-google-mtv.pdf Arno |
From: Arno P. <ar...@pu...> - 2010-03-16 16:16:35
|
Guys, there have been some questions regarding our licensing model. I would like to take this opportunity to express our (i.e., the XMLVM Core Team) intent. Before I go into details, I want to point out that our goal is to create a fair model that serves both the XMLVM Core Team as well as contributors. We acknowledge that some of you are interested in using XMLVM for commercial purposes. We ask you to acknowledge that we have legitimate business interests as well. The goal is to find a balance that works for all of us. XMLVM is and always will be Open Source. We use the GPL license and as many of you know, this license is very restrictive. The GPL license requires you to put your own source code under the GPL license. If you are just doing Open Source work, this is usually fine, however, if you want to develop commercial applications, this is not acceptable for obvious reasons. That is where the idea of dual licensing kicks in. We offer a second, commercial license, that will allow you to develop proprietary products based on XMLVM. Note that the idea of dual licensing is not new. Projects such as MySQL and JBoss have been doing this for a long time. Our commercial license is a non-transferrable GPL Linking Exception (or just linking exception for short) that takes away the 'viral' component of the GPL. This means, if we grant you a linking exception, you are *not* required to release your own application that is based on XMLVM to the Open Source. This linking exception is not transferrable. You cannot transfer this right to your customers. What is somewhat new with XMLVM is that we still want XMLVM to be a community project. That means, we hope and encourage the community to make contributions to XMLVM. It is important to us that we do not leave the perception of exploiting contributors via our commercial license. For that reason we have come up with a way to 'reward' outside contributors: If you make a (non-trivial) contribution to XMLVM, we will give you a commercial license (i.e., non-transferrable linking exception) that will allow you to develop a commercial application with XMLVM without sharing your proceeds with us. Of course there are some details that need to be clarified and there have been some questions on the mailing list regarding the details. Let us make a specific example: you send us a patch to XMLVM that is non-trivial (lets not get into the discussion on what is a non-trivial contribution. There is obviously no objective way of measuring the quality of a contribution. We will make that call on a case-by-case basis). If we (the XMLVM Core Team) agrees to merge your patch with the code base of XMLVM, we will give you a non-transferrable linking exception in return. In terms of the scope of this non-transferrable linking exception, there are several components: (1) to which version of XMLVM does the linking exception apply? (2) who is the recipient of the linking exception? (3) what is the duration of the linking exception? Let me address these issues individually. (1) we do not maintain an official versioning scheme for XMLVM. Things happen so fast in our code base that we do not plan to introduce official version numbers. In the future we might change this, but for now, we simply refer to the Subversion revision numbers. The linking exception is issued for the version of XMLVM that includes the contributors patch and any version of XMLVM released in the following 6 months. For really significant contributions we are willing to extend that time frame. (2) the linking exception is issued to the contributor of the patch. This can be an individual or the company for which the contributor works. This will allow the individual/company to develop applications that can be sold to their customers without having to share revenues with the XMLVM Core Team. The linking exception *cannot* be transferred to the customers of the contributor. (3) for the versions of XMLVM for which we issue the linking exception, the usage is not limited to the aforementioned 6 months. I.e., 6 months after you made your contribution you may still use older versions of XMLVM for commercial purposes. Only if you want to benefit from new features introduced to XMLVM after those 6 months, you will need to make another contribution to XMLVM to extend the duration of the linking exception. I would like to start a discussion with you guys on the mailing list to refine these rules. Again, we want to strike a balance between your legitimate commercial interest and ours. Let me know what you think. Arno |
From: Sascha H. <sa...@xm...> - 2010-03-15 17:43:20
|
FYI: Current HEAD should work again. // Sascha On Mon, Mar 15, 2010 at 6:22 PM, Sascha Haeberling <sa...@xm...> wrote: > You can send us the well-commented and formatted patches the usual way via > the review tool. > > I am currently taking a look at the breakage. > > // Sascha > > > On Mon, Mar 15, 2010 at 6:16 PM, Panayotis Katsaloulis < > pan...@pa...> wrote: > >> Hello again! >> >> I'd decided to send you my latest patch with tons of improvements in >> the obj-c compatibility layer. >> But I've seen that the current SVN release is broken. >> Can I just send the patches the usual way ? >> >> >> ------------------------------------------------------------------------------ >> Download Intel® 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-15 17:23:22
|
You can send us the well-commented and formatted patches the usual way via the review tool. I am currently taking a look at the breakage. // Sascha On Mon, Mar 15, 2010 at 6:16 PM, Panayotis Katsaloulis < pan...@pa...> wrote: > Hello again! > > I'd decided to send you my latest patch with tons of improvements in > the obj-c compatibility layer. > But I've seen that the current SVN release is broken. > Can I just send the patches the usual way ? > > > ------------------------------------------------------------------------------ > Download Intel® 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-15 17:16:23
|
Hello again! I'd decided to send you my latest patch with tons of improvements in the obj-c compatibility layer. But I've seen that the current SVN release is broken. Can I just send the patches the usual way ? |
From: Wolfgang K. <wol...@xm...> - 2010-03-11 19:17:23
|
Panayotis, I just checked the code you mentioned. I agree - retain shouldn't be called. I committed this change to SVN. -- Wolfgang Panayotis Katsaloulis wrote: > in the initialization of "org_xmlvm_iphone_AVAudioPlayer.m", there is > this code: > > return [[[AVAudioPlayer alloc] initWithContentsOfURL: url error: > &(outError->error_org_xmlvm_iphone_NSError)] retain]; > > Why there is a need for a second retain there (the first is the alloc > itself) ? > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
From: Arno P. <ar...@pu...> - 2010-03-11 17:39:58
|
as of now, it is the rule. Arno On 3/11/10 8:50 AM, Panayotis Katsaloulis wrote: > > On 11 Μαρ 2010, at 6:09 ΜΜ, Arno Puder wrote: > >> >> right now we have the rule that ownership of an object that is >> returned >> as a result of a method invocation is passed to the caller. That is >> why >> we have as a general rule a retain on references when returning them. >> The caller then decides what it wants to do with the reference. If the >> caller ignores the result (which the callee cannot know) it will do a >> release. >> >> I will be adding a patch in the next few days that will get rid of >> NSAutoreleasePool. Those memory management rules won't change, but the >> code should be much more efficient. >> >> Arno > > So, practically it is always important to "retain" the object when > creating the objective-c library connection with java, right? > > I am asking this because I am working on a patch which will take care > of nil objects returned by various property glue functions, and I want > to make clear that it's a _rule_ to always retain an object before > returning it. > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users |
From: Panayotis K. <pan...@pa...> - 2010-03-11 16:50:21
|
On 11 Μαρ 2010, at 6:09 ΜΜ, Arno Puder wrote: > > right now we have the rule that ownership of an object that is > returned > as a result of a method invocation is passed to the caller. That is > why > we have as a general rule a retain on references when returning them. > The caller then decides what it wants to do with the reference. If the > caller ignores the result (which the callee cannot know) it will do a > release. > > I will be adding a patch in the next few days that will get rid of > NSAutoreleasePool. Those memory management rules won't change, but the > code should be much more efficient. > > Arno So, practically it is always important to "retain" the object when creating the objective-c library connection with java, right? I am asking this because I am working on a patch which will take care of nil objects returned by various property glue functions, and I want to make clear that it's a _rule_ to always retain an object before returning it. |
From: Arno P. <ar...@pu...> - 2010-03-11 16:10:11
|
right now we have the rule that ownership of an object that is returned as a result of a method invocation is passed to the caller. That is why we have as a general rule a retain on references when returning them. The caller then decides what it wants to do with the reference. If the caller ignores the result (which the callee cannot know) it will do a release. I will be adding a patch in the next few days that will get rid of NSAutoreleasePool. Those memory management rules won't change, but the code should be much more efficient. Arno On 3/11/10 5:20 AM, Panayotis Katsaloulis wrote: > > I've seen that in the code produced by xmlvm, every time an object is > returned, this object is at the same moment released. > Thus usually in properties we see something like: > > return [[self propertyname] retain]; > > So, can we say that this is a general rule? > I mean, that in any case, no matter what, when the thin library obj-c > layer is required to return an object, this object should be *always* > retained? > > Is this valid also for objects like usually retrieved with selectors > like > [UIFont systemFontOfSize:fontsize] > ? > > I have made some tests with the last one, and even if I don't retain > it, there is no segfault (which, ok, this doesn't mean anything). > > > So what is optimum (concerning memory management) ? > > Thank you! > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users |
From: Wolfgang K. <wol...@xm...> - 2010-03-11 15:37:30
|
That's actually a good question. I'll check that. -- Wolfgang Panayotis Katsaloulis wrote: > in the initialization of "org_xmlvm_iphone_AVAudioPlayer.m", there is > this code: > > return [[[AVAudioPlayer alloc] initWithContentsOfURL: url error: > &(outError->error_org_xmlvm_iphone_NSError)] retain]; > > Why there is a need for a second retain there (the first is the alloc > itself) ? > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
From: Panayotis K. <pan...@pa...> - 2010-03-11 13:20:33
|
I've seen that in the code produced by xmlvm, every time an object is returned, this object is at the same moment released. Thus usually in properties we see something like: return [[self propertyname] retain]; So, can we say that this is a general rule? I mean, that in any case, no matter what, when the thin library obj-c layer is required to return an object, this object should be *always* retained? Is this valid also for objects like usually retrieved with selectors like [UIFont systemFontOfSize:fontsize] ? I have made some tests with the last one, and even if I don't retain it, there is no segfault (which, ok, this doesn't mean anything). So what is optimum (concerning memory management) ? Thank you! |