Many did not get irked in this case when someone else steal another's IP and gets away with it. Reason is that this crime is buried in some smart twist of words and license carpeting. This should be a clear case with OpenBravo absolving Compiere's expensive technology of the application model and design (see http://www.openbravo.com/product/others/relationship-compiere/). That is all left of Compiere's epitaph, in some products/others/relationship wasteland.Without Compiere's (I reemphasise) very expensive investment in coming out with an application model that encompass functional and metadata, of which is fondly called Application Dictionary, w
e wouldn't have figured out in 10 light years how best to come out with an Open Source ERP product without investing tons of money.When OpenBravo won an estimated USD18million (so far) for the launch of its operations, this cannot have happened if the players and investors have known the above fact and acted out of conscience and ethics. Those angels should have given to Compiere to add the sugar coating packaging instead and do history justice.
Of course Open Source licensing allows you to fork and start off your own project but not to commercialise it lock, stock and barrel without homage or proper credence to the true owner and patron behind all those hard work. All OpenBravo left Compiere with are the following disrespectful words:
Our current code base is almost entirely comprised of original, Openbravo-developed code that is continually evolving. By our estimates, less than 10% of this code can be attributed to Compiere. Any code that has not been developed by Openbravo is properly identified in the source files.What a dumb thief who took the beehive and rid off the bees! And how apt an example of another evil commercialisation of Open Source. By confusing Open Source as an effort of mere lines of codes and not true Intellectual Property of others, they have taken advantage of the poor sheep with another set of wolf's clothings, claiming to be original and free by at least 90% in their worth. Nay! I say they still owe 90%, if not more to that old sheep.
The true spirit of Free and Open Software is to always acknowledge the original copyright and authors, but instead these clothiers chose to look for loopholes in the engine chasis license and come out with their daylight but 'legalised' blowtorch.
Their intent is clearly not altruistic, and not for the public good. Theirs are for profit and they are commercially owned. One day, they like MySQL shall pull the rugs from under the flock's paws.
If they are honest to the bone community open source, then they would have paid more fitting homage or at least do what RedHat did - give away shares to Linus Torvalds, which has always been identified as the inventor behind Linux of which RedHat depends on. RedHat has no similar propounded fine printing that says it has added 90% to Linus'.
But i tell you, if you believe in Karma, those who steal shall not sleep well. In this world nor the next.
We in ADempiere that forked from Compiere through open forum put Jorg Janke the creator of Compiere on a high pedestal and always bow to him whenever we can, and even ruled to pay him honourware royalty. Without him we cease.
Until we turn a handsome profit in order to carry out our oath, I am writing this to put my arrow to bow in his honour.
8 comments:
That 90% independence has a meaning merely in lines of code. I wonder what would be the number if they could measure database schemas in a way similar to lines of codes.
I believe almost any developer, can implement an algorithm or use a tool/framework but there are only a few who can a design a gigantic application. From a broader perspective all those tools/framworks are used to implement a design, a data model. So it's obvious that in any application, what counts is the data model, not the lines of code -unless there's no data model and only design, such as OS kernels.
Therefore, IMHO, it's not fair to measure the dependency of two (business) applications only using lines of code.
For those who are still in doubt, I've got a quick solution: just check the database schemas of OpenBravo and Compiere -this is where you will cleary see that there's only one mastermind behind both!
--
Bahman (http://www.bahmanm.com)
"Let him who has done a good deed be silent; let him who has received it tell it."
-Seneca
Try and search Google for pages that link back to their statement on containing other people's GPL'ed code.
I agree with Redhuan and Bahman that more could be done to emphasise that Open Bravo bears a striking resemblance to both Compiere and (through common ancestry) ADempeire.
re: the database schemas, I guess that the SQL code to roll out a schema to an RDBMS should be no different to the Java code to implement the data dictionary. And hence, verbatim copying of GPL-'ed code would bring with it the normal GPL rights & obligations, irrespective of whether its GPL-'ed SQL database schemas or Java code.
But the ideas and the concepts behind that code ... Aha, that is another matter.
And also, check out OpenBravo's license, which is based (MPL).
Food for thought!
Izam,
Your link should not have the word 'link:' and then you can see links. Isn't that what you wanted to do?
Thanks Bahman for the emphasis about Database model design been the heart of a system.
A single idea or line or name when it is of the right value are given the highest regard and value.
That is why advertisment ideas fetch millions. And authorship copyright is assumed in universal law.
If Compiere choose to sue along such an authorship cliam i see no legal reason they do not have a case to be heard on.
MPL or GPL is a new case law, still at its primitive stage, and thus jurispudence has to fall back on the law of tort where injurious conduct has occured.
red1
However, let's also look at it from an end user's perspective:
Can I responsibly entrust the long-term survival of my organization to Compiere, or ADempiere, or OpenBravo?
I look at the ADempiere Home Page and the most recent update I see is May 2008. Clearly, ADempiere is a solution that engenders absolutely no comfort at all.
I look at the Compiere Home Page and I see things such as 195% growth in 3Q2008.
I look at the OpenBravo Home Page and I see things such as various news stories from October 2008.
The purpose of these comments is to highlight things from a customer perspective. I am afraid your complaints look like they are based on emotions and not facts. In actual fact, I thought that the OpenBravo page (http://www.openbravo.com/product/others/relationship-compiere/) on its relationship with Compiere highlights its significant gratitude to the groundwork done by the Compiere team.
To Frank:
I thought we were talking about OpenBravo using Compiere's intellectual property not how it was able to beautify that property (Compiere's) in the eyes of the customer.
The point is that OpenBravo pretends as now it's got only 10% left from Compiere which is not correct; they should have creditted the mastermind behind these awful peices of softwares (Compiere/OpenBravo/ADempiere) as much as he deserves which is, IMHO, a lot more than they did in pages such as "About US" page.
For a good example just visit http://www.adempiere.org which is ADempiere's community home page and you'll see Jorg Janke's name at the top of the contributors section spotting him as the kernel contributor.
--
Bahman (http://www.bahmanm.com)
Frank, you're comparing pears with apples.
> Adempiere Home Page May 2008
Yes - remember: THE FOCUS IS ON THE COMMUNITY. Accordingly the main game in adempiere is played in forums, trackers, wiki, not polishing a webpage - that's more for commercial parties.
Just check Adempiere forums and trackers (if you dare!) and probably you'll be out of time trying to catch the movement and speed of THIS STRONG COMMUNITY.
Anyways - your "move" is clear, you're trying to move a discussion about honouring top contributor (CONTRIBUTORS ARE PRICELESS) to a discussion about marketing.
Personally I think the "10% statement" of openbravo (and I have seen this statement in lots of marketing papers and presentations from them) is trying to minimize the relation, it's not about gratitude, it's more like - "hey, look, we're very far from them".
And putting such numbers (10%) just on code is trying to ignore the BIG fact pointed by Bahman, about database, and going deeper, about dictionary.
I would like to see a comparison of Compiere and OpenBravo application dictionaries to realize how much have they contributed to the big concept contributed by Jorg Janke.
Regards,
Carlos Ruiz - globalqss
http://globalqss.com
Hi Red1,
Well I should say I agree with most of what you said. What Openbravo does is probably legal but hardly moral. Still, I think Compiere was not a great moral example either, and you know better than us why Adempiere forked too (but today I would say that Compiere is probably cheaper than Openbravo because at least is works for real; even if Openbravo 2.40 is a bit less a vaporware).
Just like you, a while ago, I believed the "application dictionary" was the best available system for an ERP persitence system, at least if you didn't want an object database such as ERP5 nor a very static system such as Ofbiz where things can almost only happen at compilation time/code generation.
But then I discovered OpenERP (formerly TinyERP). Well I did some Ruby on Rails development myself and I should say I was very sad to work with ERP solutions that didn't get it from Rails and kept sucking.
Fortunately in a lot of ways the OpenERP platform (now called OpenObject) provides a similar productivity as Rails, even better within its ERP scope!
It deals both with extensibility, hot data model swapping (when you install a module for instance, it doesn't only add features, it can also overrides fine grained piece of code to achieve the target behavior with a very minimal code), object oriented programming and relational databases.
So, sorry I think once one understands how the OpenERP system works, he will never come back to those "application dictionaries" no matter how much money they smoked neither how great that system was 10 years ago.
On the contrary Compiere/Openbravo/Adempiere application dictionary now seems doomed because:
1) it removes the ability to have domain object oriented programming, means very low extensibility, bad complexity management. How the hell are you gonna verticalize your ERP?
2) it's very hardly scriptable all the way without even the benefit of a static language (pl/SQL has no static compiler)
So I mean it's just over to fight for the paternity of the "application dictionary". Why not look forward with us instead and smash SAP for real this time?
Just my very volatile $ 0.02
BTW, congrats for Adempiere anyway, I mean it's not because you didn't win you doesn't deserve your medal either. Thank you for you past explanations on Compiere, I learned a lot about its dark sides from you.
Oh! and an other one about lines of code... I think 60% of Openbravo schema is directly dumped from Compiere and not even used anymore (see the tables they say they will clean up in their roadmap). And in the Openbravo 2.33 or 2.35 (Q1 2008) codebase, their were still pl/SQL stored procedures referencing "tire storage" tables, directly inherited from Compiere birth in GoodYear Germany back to 2000! Not only copied, but mainly totally screwed up into on of the classical non maintainable software dead end no matter how much money unlearned investors will smoke on it.
An anonymous coward (well, I should endorse a part of the company I'm still working in, so sorry for now).
jackthripper said...
On the contrary Compiere/Openbravo/Adempiere application dictionary now seems doomed because:
1) it removes the ability to have domain object oriented programming, means very low extensibility, bad complexity management. How the hell are you gonna verticalize your ERP?
In Adempiere we generate java model Interface and Implementation of this interface. I_C_BPartner.java and X_C_BPartner which represents domain objects.
2) it's very hardly scriptable all the way without even the benefit of a static language (pl/SQL has no static compiler)
In Adempiere we have ability to write custom code in script languages. This code can be activated/invoked on diferent events: BeforeSave, AfterSave, ...
Kind regards,
Trifon
Post a Comment