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 |