Re: [xmlvm-users] Clarifications on the Linking Exception

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

Hi,

Thank you for sharing / clarifying your licensing strategy with us.

We at MattaKis Consulting have been working on improving XMLVM in order to
enable us using it in real projects. We have already contributed a pretty
large set of patches, and more patches are in the works internally.

Unfortunately, we have some major concerns with the current licensing
strategy.

1. The current state (maturity) of XMLVM
Although XMLVM is improving rapidly (thanks to both the core team and also
to the dedicated external contributors), it is not a mature product yet. The
Core Team seems to acknowledge this in the licensing strategy by not
specifying a release cycle, instead of using exclusively a time based model.

Realistically, if you want to use XMLVM currently for anything serious, you
will have to "pop the hood", and start developing into the runtime library
the missing parts that you are using. My optimistic estimate is that it will
take at least 1.5 - 2 years for this situation to change, when you can take
a non-trivial Java/Android program, and it will output a reasonably well
working Objective-C/Iphone version.

However, the current licensing proposal means that those who make the
essential contributions now (like implementing java_lang_String methods ...
etc.) that led to the mature XMLVM will be in the same position as any
newcomer. Their linking exceptions will have long run out by then. The
problem is, that this asymmetry is not solved by simply extending the length
of the linking exception.

2. Unclear legal status of the project
When we are signing the CLA, we are signing the rights to "XMLVM". This
issue has been brought up last year on this list. Right now it is not clear,
who is XMLVM? Is there a commercial entity? Is it the 3 Core Team members?
Who will "own" the code, that is contributed? Who will grant the commercial
licenses?
The core team members work at large software companies / US universities.
It is not clear if these entities have any legal basis of "taking XMLVM",
and saying that the previous "linking exceptions" are invalid, and starts to
sue the users of XMLVM. This all depends on the work contracts of the core
team members, and also the relevant US and EU laws.

I know that this seems like a slim chance right now, but stranger things
have happened, especially when there is money involved.

3. Absence of a real commercial license
Since the linking exception is non-transferrable, essentially, our clients
will have to somehow obtain a commercial license (In many cases you also
have to deliver the source code and all necessary tools to your clients.) It
is not realistic, that each of those clients will be able to do a
contribution. Also, as the project matures, it will be harder and harder to
contribute something that is valuable enough for a linking exception. It is
also "funny": You take a future, mature XMLVM version, it works flawlessly
for your project, but then you have to go and implement something completely
irrelevant to your project, just to get a linking exception.

This was also brought up earlier, and then the Core Team mentioned something
about 2-300 USD for a linking exception license, but the specific details
were never really worked out.

4. The current license strategy encourages minimal contributions
With this 6  month time limit, contributors are not encouraged to contribute
as much as they can. Instead they are encouraged to contribute the "minimal
amount necessary", and then to contribute a small amount again, when their
linking exception runs out. Even if they are required to release all their
changes under the GPL (see next point), these code dumps cannot be used in
XMLVM, because they were not contributed to the project.

I think this hurts the XMLVM project as a whole, including the Core Team and
any current and potential contributors.

5. It is still not clear what the linking exception will allow and what not
I was actually pretty surprised when in a later email Arno wrote, that even
if you have the linking exception, you have to release any changes you make
in XMLVM under the GPL. Clearly, the Core Team has a very different notion
of what the linking exception allows, than us (MattaKis Consulting), and
this gets us back to the "Unclear legal status" and the "Absence of
commercial license" points.

6. Very asymmetric relationship between the Core Team and the contributors

The contributors have to grant all rights to the XMLVM project, more
specifically the Core Team. This means that the Core Team is free to change
the license of the project, sell the project to the highest bidder ... etc.

At the same time, the contributors get only a limited time non-transferrable
"license exception".

This is already an issue now (judging from the many questions regarding
transferrability ... etc.),  but in 1 - 2 years, when XMLVM will be a mature
project, and will worth much more than currently, it will be a huge issue.

The current contributors are adding significant value to the project, and
that value will still be used then. It is unrealistic that the essential
runtime features that we are working on now are going to be thrown out: you
cannot do it too much differently. The contributors are doing everything
from alpha- and beta-testing, to adding essential features and to
participating in design discussions here on the mailing list which form the
direction of XMLVM significantly.

By the time XMLVM becomes mature, the current contributors will have no
valid linking exceptions, so they will need to buy a commercial
license...for something that they in part (and it is a significant part,
because they received a linking exception for it) created.
And there is no say how much will a commercial license cost then. We don't
know who will be in control of the project.

My proposal:
XMLVM has 2 major components for each source -> target permutation:
1. The compiler, which takes the input and generate the output for the
target
2. The runtime library which implements the API for the platform to make the
compiled code usable.

>From what I have seen in the last months, the compiler itself is mostly
worked on by the core team. We, the contributors, only touch it, when we
have to fix a bug, or we need to put in a missing part for a feature of the
runtime library.

On the other hand, the runtime library has already received significant
external contributions, and it is my estimate that this will only increase
in the future.

Now we have two components that cannot be used without the other.
My suggestion is to:

- Make the license of the runtime library (Java & Iphone API) more liberal,
since it is written in a significant part by external contributors.

- Keep the current dual licensing scheme for the compiler. As far as I know
the code generated by the compiler is still GPL - so you need a commercial
license for using it in commercial project. I am not a lawyer -- if this is
not the case, then you might consider changing the compiler license
accordingly.

- When someone contributes to the library, you at your own discretion may or
may not grant commercial license to the compiler. This way you sponsor the
development of the libraries without actually using hard cash.

- For those who cannot contribute for any reason, please offer a commercial
license for a fee. (I am deliberatly not using the "linking exception",
because I think it has become a way too ambiguous term.)

- If someone contributes directly to the compiler, then the Core Team (or
better yet, the commercial entity behind the project) would agree with them
on a reasonable compensation (this can be also a specified number of
commercial licenses, or later money). Of course it should be well documented
how to negotiate (who to contact...etc.) such agreements ... etc.

The advantage of this proposal is that it clearly separates the community
developed parts, and the commercial parts of the project, while still taking
the commercial interests of all parties into consideration.

What do you think about all this?

Best Regards,
Gergely

2010/3/16 Arno Puder <ar...@pu...>
[...]


-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622