- How was IBM's Common License selected over the alternatives?
- The fact that developers' "full legal names" are required would seem to imply some type of legal obligation under the agreement (although I'm a litte fuzzy on how providing a name would be considered a binding legal commitment in the U.S) What are those obiligations?
- Why would TMG license its Genbridge technology to a competitor who has the goal of crushing it like a little bug? (I see several other problems with the Genbridge proposal, but that's the licensing piece)
Hmmm, short easy answer is I work for IBM - but not as a developer and this project is not associated with my employer in any way.
The major advantage to this license is that at any time, anyone can take the code and do with it what they please (including expanding it into a commerc ail product) and the original contributers will bear no liability. I think the license is clear and readlily understood. It also is an OSDN approved license, meaning this is a fully open-source project.
I doubt this product would squash TMG or any other program "like a bug" - frankly, the extra work around GenTech's model may be more than even most serious genealogists are looking for - although that is part of our challenge - can we ease the use of this model without compormising it?
Genbridge is two-way and of course Wholly Genes gladly allows any product to get it's data into TMG unscathed by the treacherous GEDcom mutilation. On the other hand, there may be licensing and/or other issues to preclude us using GenBridge on this project - more research will need to be done here.
The biggest problem that I see with the IBM license is that, unlike an MIT style license, it's not GPL compatible because of the patent provisions. This may be a deterrent to some developers.
In common with MIT style licenses it basically allows any use of the code commercially which is something I have mixed feelings about. On the one hand, profiting from someone elses work without having to pay for it is very attractive, but the prospect of someone else doing the same to me is much less attractive (not that I think there's much money in genealogy software).
There actually isn't a "legal name" requirement. What it says is that contributors must identify themselves "in a manner that reasonably allows subsequent Recipients to identify" them. This could be more or less than a full name. I suspect it's more.
By publishing using this license each contributor granting rights, making warranties that they own copyright in the code, etc, so this should probably be prominently highlighted in the developer guidelines.
Leif Biberg Kristensen
it's nice to find a group of people who actually plans to implement a GDM application, and who is still alive and kicking after several weeks :-) Hope I can be of help.
As far as TMG goes, writing a plain data conversion routine eg. in Perl is a trivial task. In fact, I have done so myself, dumping a subset of the data to SQL command files. The code is available from http://solumslekt.org/source/tmg2sql.tar.gz along with some semi-working PHP scripts to display the data online.
Probably any genealogy program data format in existence might be munged in a similar way to provide "native" input to another program, given that the data architecture of the receiving program is reasonably transparent.
The Genbridge technology is hardly rocket science, and any half-decent Perl hacker could probably come up with a better script than mine to do essentially the same job.
I think that Bob Velke drove the point home rather succinctly a couple of weeks ago on GenealogyXML on why genealogy software developers in general _really_ don't want their users to share data with each other. Bob V. himself is of course a very honorable exception.
Since we are still in the planning stage, much of what we have are things that will either take further deep research or enough progress to make what we need clear.
I suspect that use of GenBridge will hinge less on it's licenising and more on whether we need or can use its functions.
I am very careful to point out the CPL license and it's impact whenever a developer joins the project. Adding it to the developer's guide would help bring the point home as well.
The CPL provides provides the liability protection and future use protections that would allow the contributers (and otheres) to roll any or all the code into a commercial product. As you point out, this makes it GPL - incompatible, since the GPL would not allow commercial re-use in this manner.
I would be tickled pink to see any or all of this effort in a commercial product, but the narrow focus of this may mean it would be hard to eek a profit from it. Talk about a minority market: the intersections of - (1) serious genealogists (2) Linux or cross-platform users (3) GenTech GDM process advocates. Heck, the developers alone might be half the market <grin>
If the developers are the bulk of the market, that would argue strongly for using the GPL. Personally I'd be pissed off if someone were to take my code and make a profit from it without paying me and I suspect many other professional software developers may feel the same. I think the risk of this happening is relatively small, but I'd have to decide it was acceptably small before contributing code of any value.
I didn't explain what I was talking about with the GPL incompatibility very well. Not only can GPL code not be reused in GeneaPro to save implementation effort, which is obvious, but GeneaPro couldn't be incorporated in GPL project (e.g. a bundle of GeneaPro and some new plugins), whereas MIT-licensed code could.
Leif Biberg Kristensen
I agree very much with Tom here. The code should be free, in both senses of the word. If that means that there are some libraries which can't be used, so be it.
I'm not sure I agree that CPL code can't be used in a future GPL products, and would appreciate an explanation. I do understand we can't use GPL code in GeneaPro, since we would then entangle our code into the GPL requirements.
My concern (as I think was IBM's when they created the CPL) was that the developers who contribute can in the future do anything they want with the code, incuding full commercialization. The GPL prevents this (and is the right thing for many projects).
I'm having the feeling if I matrixed in everyone's preferences, we each would have our very own project with just the right license, GUI, language, approach, etc. I'm hoping that each of us can see this project as the closest thing to our "perfect" set, and work with each other to get something worthwhile to us all.
IBM's CPL has certain requirements for any redistribution or reuse which are not included in the GPL. The GPL requires that any GPL-licensed code be released under an umodified GPL, thus there is no way to meet the additional requirements of the CPL.
Personally I think it's much more important to be able to integrate with and reuse other GPL'd Java genealogy code than it is to preserve the ability for someone to make a profit from free labor.