Dev - Jar files that doesn't seem to be used
Locked
Dev - Jar files that doesn't seem to be used
 
|
Re: Dev - Jar files that doesn't seem to be used
|
|
Re: Dev - Jar files that doesn't seem to be used
|
|
Re: Dev - Jar files that doesn't seem to be used
|
|
Re: Dev - Jar files that doesn't seem to be used
|
|
On Jan 29, 2006, at 3:04 AM, Andrew Yager wrote: > Hi, > > This all got me thinking and hunting around the MySQL website for > information about their licenses. According to http://www.mysql.com/ > company/legal/licensing/foss-exception.html it seems that we should > be able to distribute the MySQL client libraries with OfBiz, as long > as OfBiz remains under an approved "other" license. > These licenses include, but are not limited to, the MIT and Apache > license. If you make changes to OfBiz which you then don't release > under some form of license, then you could not use this. > > I could be reading it wrong... but yes :-) circle) the MySQL FOSS exception only carries so much weight. This exclusion that they mention on their site is what I was referring to when describing the MySQL issues and is the reason why we have been including it in the past, even though anyone doing any sort of change to OFBiz and making it available to others (even users of the application) without releasing it under an open source license is open to some pressure from MySQL AB to buy a license. It is nice of MySQL to post the exclusion on their web site, but that isn't a part of their actual license and can be changed at any time. Partially for this concern and partially for principle I don't like this so much... They used to release the JDBC driver under the LGPL license but changed it for the specific purpose of being able to put more pressure on people to buy licenses. MySQL has certainly gained in-roads into all sorts of areas over the years, but the thing to keep in mind is that the game has changed. In recent years MySQL has grown into a real company with real investors, and companies like this must be fed and have a good appetite for licensing revenue... -David > Andrew > > On 29/01/2006, at 2:43 PM, Chris Howe wrote: > >> In regards to Mysql's licensing; Because OFBiz is >> database agnostic, one can develop Ofbiz apps using >> Mysql. They just shouldn't be using Mysql in a >> production environment, without a commercial license, >> if their web application is commercial in nature, >> placing all things equal except for licensing, >> correct? >> >> The reason that I find mysql easier is that I started >> coding (or whatever you want to call it) using an >> apachefriends XAMPP installation. No configuring >> anything, just start hacking away at someone else's >> hard work. Mysql is part of the XAMPP setup and the >> tools available for mysql are abundant. I think this >> is a path a lot of hobbyists take, especially if you >> have no computer science background. >> >> In regards to backwards compatability vs progress, I >> totally agree. But then I'm working in a >> semi-production environment that is current with SVN, >> so I'm a little biased. As far as my setup, as long >> as you don't mess with the data model too much, it >> won't break my setup too badly, regardless of what you >> do with backwards compatability. However, the average >> Ofbizer out there created their apps by copying the >> entirety of an app that gave similar functionality, >> and so their app lacks awareness of changes to the >> project after they made the copy. >> >> Just to complete the speculation....pretend like you >> are now the lead singer of Barnaked Ladies and can >> write a song entitled "now that i have a million >> dollars", What would a non compatible Ofbiz look like >> and how dificult would it be to produce? >> >> --- "David E. Jones" <[hidden email]> wrote: >> >>> >>> On Jan 28, 2006, at 6:36 PM, Chris Howe wrote: >>> >>>> Wow, used to have to buy a response on the >>> weekends. >>>> lol a lot of action today. >>>> >>>> Unless I just totally miss the point of "backward >>>> compatability", we shouldn't be taking any of the >>>> libraries out unless there's a very good reason >>> to. >>>> The idea of backward compatability in an open >>> source >>>> project isn't just keeping support for things that >>> the >>>> project has used out of the box. It also includes >>>> keeping support for the functions that were built >>> and >>>> someone may have taken advantage of, so that when >>> that >>>> person goes to update and get back into the >>> community >>>> from being in a production environment, their >>> stuff >>>> doesn't break. Ofbiz is very much a project >>> where >>>> most of us are standing on the shoulders of >>> giants. >>> >>>> Many of the people who use Ofbiz have the skills >>> of >>>> making Ofbiz say "Hello, you big beautfiul world", >>> but >>>> have no idea how or why Ofbiz said "Hello, world" >>> in >>>> the first place. If this type of person utilized >>> one >>>> of the libraries without knowing what exactly that >>>> library did, and when they update it, the libary >>> is >>>> gone, they're going to be in a pickle trying to >>> track >>>> down what they did wrong. Many times this person >>> will >>>> simply give up on Ofbiz because of it. That's an >>>> outcome that you guys have at least attempted to >>> avoid >>>> by worrying about compatability. >>> >>> The difficulty with is a little-known law of the >>> universe: progress >>> with full backward compatibility requires >>> omniscience. In other >>> words: if had been sufficiently omniscient to know >>> it would change we >>> would have done it the latter way in the first >>> place... >>> >>> So, in general backward compatibility must take a >>> back seat to >>> progress because the sad truth of OFBiz (and please >>> don't spread this >>> around too much!) is that we are woefully short on >>> omniscience these >>> days... ;) >>> >>> Still, for the jars I listed in that list email (if >>> you are referring >>> to the same I'm thinking of), there really aren't >>> any backward >>> compatibility issues. If someone is using those they >>> would generally >>> have to write code or do very low level >>> configuration in order to do >>> so. These won't affect the general functioning of >>> OFBiz, so most will >>> never notice or have to worry about them. For those >>> who are using >>> them they will be able to remove the explicit >>> instructions not to >>> build them in the build.xml files, and add the >>> desired jars. >>> >>> >>>> As far as the database jars, I imagine there will >>> be >>>> sufficient documentation for anyone wondering >>> around >>>> to figure out what went wrong as the database >>>> independence is Ofbiz's flair. But when the >>> libraries >>>> that the project itself doesn't directly take >>>> advantage of start disappearing, there won't be >>> any >>>> documentation available. >>> >>> Downloading and installing database drivers, in this >>> case JDBC >>> drivers, is a common requirement for setting up a >>> new database. This >>> is necessary for pretty much any JDBC-based database >>> tool, including >>> admin tools and all sorts of things. >>> >>> We won't be removing any jars that are directly used >>> or needed for >>> general functionality, unless they are LGPL and then >>> we have no >>> choice. For all the good that the GPL and LGPL have >>> done, for certain >>> types of software I think it is more detrimental >>> than helpful. And >>> the irony is that with dual-licensing the GPL has >>> fueled a world of >>> semi-open source software. I don't know what >>> Stallman and Moglen >>> think of that twist on things, but in my opinion it >>> is a sad >>> bastardization of the ideals that they are working >>> toward... >>> >>>> If this idea to maintain backward compatability is >>> no >>>> longer an issue, then just take a chainsaw to the >>>> bloat in the project and release a non tested >>> Ofbiz >>>> 4.0. Make everyone's life easier. >>> >>> "If I had a million dollars, if I had a million >>> dollars, I would buy >>> a new OFBiz, but not a backward-compatible OFBiz >>> that's too messy..." >>> >>>> P.S. in regards to dropping database jars, IMO >>>> dropping the mysql jar is a bigger issue than >>> dropping >>>> the Postgres jar. Mysql will attract more people >>> who >>>> have played with PHP and would more easily >>> contribute >>>> back to the project faster. But with proper >>>> documentation(ie, go download the jar and drop it >>> into >>>> xyz folder), I don't think dropping any of the >>>> database jars is an issue. >>> >>> This may be true... However, the irony is that the >>> MySQL jar is that >>> main one that we HAVE to get rid of because it is >>> GPL licensed... In >>> fact, I usually discourage clients from using MySQL >>> if they are >>> worried about intellectual property issues because >>> while MySQL has an >>> exclusion for open source projects, if you modify >>> OFBiz and >>> redistribute it under a non-open source license >>> (which by MySQL >>> standards making an application available to the >>> public, ie via the >>> internet, can qualify for this...), then you are >>> breaking their terms >>> and must buy a commercial license to avoid being in >>> violation of the >>> GPL license... >>> >>> Risky? For some perhaps. A major pain? For sure... >>> >>> -David >>> >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/dev >>> >> >> >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
smime.p7s (3K)
Re: Dev - Jar files that doesn't seem to be used
|
|
In reply to this post by cjhowe
On Jan 28, 2006, at 8:43 PM, Chris Howe wrote: > Just to complete the speculation....pretend like you > are now the lead singer of Barnaked Ladies and can > write a song entitled "now that i have a million > dollars", What would a non compatible Ofbiz look like > and how dificult would it be to produce? It would look like OFBiz now except with me on a nice island somewhere... perhaps enjoyed a bit of BNL. ;) There is a lot of legacy stuff in OFBiz including in the service engine, in the simple-methods, in the entity engine, and in various places in the data model as well that would be nice to toss and replace with the newer/cleaner tools. The general concepts and overall structure of the project is fine, but these cleanups would require a LOT of code changes within the project and for others. We are trying to do these slowly over time, but it is slow and trying not to rock the boat too much it goes on and on. Also, there are a lot of bugs and areas where small improvements could make a very big difference. It would be nice to clean up all of these little issues in OFBiz, and put in some good automated testing framework and a complete set of tests, and remove the older testing stuff. Not all of that has to be backward compatible, but various parts of it certainly are... -David _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Jar files that doesn't seem to be used
|
|
Re: Dev - Jar files that doesn't seem to be used
|
|
Re: Dev - Jar files that doesn't seem to be used
|
|
Re: Dev - Jar files that doesn't seem to be used
|
|
| Free forum by Nabble | Edit this page |