Florin, IANAL, but here is what I know so far
> Hello. > > To see if I really got it wrong, I did a bit of research on the various > licenses. I think it is useful to restate briefly what I understand from > each license. (I surely would like to see a lawyer comment on these > licensing issues.) You got it wrong at least for ASL2 and for ASL2 vs GPL. You should at least read the link Chris posted : http://developer.kde.org/documentation/licensing/licenses_summary.html > HPL/GPL: I don't see anything different in the spirit of the two licenses. > HPL seems to me more restrictive in that it specifies details which the > GPL leaves open to interpretation, but I could not find any essential > difference between the two. Both licenses require you to provide source > code to any binary you may distribute, and not charge any money for either > the binary or the source code, if you built your binary on top of or as an > extension of some GPL/HPL-ed app. They do not require you to share > whatever modifications you make to an app with the rest of the world, they > do however require that if you do so, it should happen without any > licensing fees and with anybody interested in the whole world. They both > delimit in pretty much the same way what may and may not be considered > derived work. I have no comment here (did not even read all your writing) : for me it's simple HPL is more constrained and notably more clear than GPL on usage on web > Apache license: as far as I can understand it, it allows you to > commercially license only stuff which is only coupled on interfaces > exposed by an app, such as plugins, but not stuff which replaces parts of > an app and/or implements various things differently, and which uses code > in the app to build and run - like for instance licensing ofbiz with a > module which not only provides additional financial services but also > changes whatever there already is in ofbiz. AFAIK there are no such constraints when commercialising with ASL2. ASL2 have only some restriction when it comes to commercialise. You can't withdraw the Apache name. And if you redistribute your code modified from an Apache project you must show the ASL2 header in each files (except very simple files without any "intelligence"). You must also keep the licences related files (LICENCE, NOTICE) in your distribution. > > Essentially, I see no significant difference between the spirit of the > Apache license and GPL. I'd happily listen to somebody trying to explain > this difference. Seemingly, the Apache ppl think the same way - quoting > from their FAQ: > > Is the Apache license compatible with the GPL (GNU Public License)? NO ! That's why we had to withdraw GPL libraries used in OFBiz before Apache era.You can use them if you want (refer to 1st column in Chris Howe link) but we can't distribute them within OFBiz. > It is the unofficial position of The Apache Software Foundation > that the Apache license is compatible with the GPL. However, the > Free Software Foundation holds a different position, although we > have not been able to get them to give us categorical answers to > our queries asking for details on just what aspects they consider > incompatible. > > Whether to mix software covered under these two different licenses > must be a determination made by those attempting such a synthesis. > > It may be that the GPL tries to enforce open-source-ness in a more > aggressive way than the Apache license, in that GPL forces you to share, > whereas Apache allows you to share (I found this opinion on the web, but > could not find an arugment for it in the text of the two licenses). But I > think a lawyer is needed to really point out the differences so that a > non-lawyer may understand them. But both of them are pretty much the same > to me if you _don't_ want to share. No, on a commercial POV with Apache you are allowed to do so, not with GPL > Digging deeper into the problem, I found the following on a wiki page > (http://en.wikipedia.org/wiki/Apache_Software_License - a search on the > FSF's site found it there too) - what the FSF says about Apache 2.0: > > This is a free software license but it is incompatible with the GPL. > The Apache License is incompatible with the GPL because it has a > specific requirement that is not in the GPL: it has certain patent > termination cases that the GPL does not require. (We don't think > those patent termination cases are inherently a bad idea, but > nonetheless they are incompatible with the GNU GPL.) > > IMO, this difference is not essential for what this discussion is about. > > LGPL: even this license is pretty restrictive in closing source code. > However, you can, under this license, use an open-source library to build > your own commercial solution, and keep your solution closed source. You > still have to provide notice that you used the library, and not charge > license fees for the library itself. > > What I understand that Scott's problem is, is that he expects (or at least > doesn't want to disregard the possibility) that he'll come to a point > where his custom, industry-specific solution built on top of ofbiz (or > opentaps) is so smart that he may decide to license it commercially. IMO, > neither building such a solution based on opentaps, licensed under the > HPL, nor on ofbiz core, licensed under the Apache 2.0 license, will allow > him to do this. So I see no point in him duplicating the effort which has > already gone into the opentaps modules he considers rewriting. On the > other hand, if he considers writing modules for ofbiz/opentaps, and > providing a solution where opentaps/ofbiz are unmodified, and only > extended by his modules, I see no point in restricting himself to one or > the other solution: neither HPL nor Apache 2.0 prohibit commercially > licensing pluggable components for unmodified open-source apps. No problem with ASL2, different for LGPL and even more for GPL. Consider just a thing : Opentaps is build on OFBiz, you see ? > > Our ("our" = the company I'm working for) intention is to provide > solutions to our customers based on ofbiz/opentaps. We don't want to > settle on either opentaps or ofbiz, but be flexible, and choose the one > which is appropriate for the customers' needs, on a case-by-case basis. So > we are clearly interested in licensing issues which are different between > the two. >From a commercial POV , for me ASL2 is less restrictive thant LGPL with is less restrictive than GPL with in turn is less restrictive than HPL. HTH To everybody : Please correct me if I'm wrong... Jacques > br, > > -- > Florin Jurcovici > ------------------ > Why do psychics have to ask you for your name? > > On Tue, 10 Apr 2007 10:12:07 +0300, Tim Ruppert > <[EMAIL PROTECTED]> wrote: > > > Florin, I think that your understanding of the different licenses and > > their restrictions are slightly off. I certainly am not a lawyer, > > but the GPL is not the same as the HPL (there are added restrictions > > on the HPL), the LGPL doesn't jibe with the Apache license at all and > > the Apache license is nothing like any of them. > > > > David's explanations have always made the most sense to me - maybe he > > can swing in and address your particular examples directly at some > > point. > > > > Cheers, > > Tim > > -- > > Tim Ruppert > > HotWax Media > > http://www.hotwaxmedia.com > > > > o:801.649.6594 > > f:801.649.6595 > > > > > > On Apr 10, 2007, at 1:05 AM, Florin Jurcovici wrote: > > > >> Hello. > >> > >> IMO that's not necessarily the best wasy to go - although I respect > >> your freedom of choice. > >> > >> Why do I thik otherwise? Since the HPL is a modified GPL that only > >> requires openness more precisely than the GPL - I could not see any > >> restriction in a spirit different than that of the GPL. So no > >> matter if you go with ofbiz core or with opentaps, IMO you are > >> bound to essentially the same contract. If you later on decide to > >> develop and market a product based on ofbiz or opentaps, and keep > >> it closed-source, you're stuck, no matter if you built your custom, > >> marketable solution on opentaps or ofbiz. If later on you decide to > >> publish your custom solution as open-source additions to ofbiz - or > >> opentaps - you're essentially going to do it the same way for both > >> of them. > >> > >> There is another license, which allows you to build a custom > >> solution based on open source: LGPL. However, neither ofbiz core > >> nor opentaps are licensed under its terms. As such, you have to > >> either keep your custom solution closed source and use it only > >> internally, or you have to publish it as open source. So > >> essentially there is no way you could make money from selling > >> licenses of stuff built on top of either ofbiz or opentaps. > >> > >> The only thing you' achieve by duplicating the functionality > >> available in opentaps and not available in ofbiz is duplication of > >> effort, IMO. At least that's my understanding. > >> > >> Please, anybody, if my understanding of the licensing problems is > >> buggy, correct me. The licensing issues are important for me too. > >> > >> br, > >> > >> -- > >> Florin Jurcovici > >> ------------------ > >> Why do psychics have to ask you for your name? > >> > >> On Sat, 07 Apr 2007 17:53:28 +0300, Scott A > >> <[EMAIL PROTECTED]> wrote: > >> > >>> > >>> I guess this thread really illustrates the confusion that I had > >>> originally. I > >>> didnt want to start any problems but I just want the ability to do > >>> whatever > >>> I want with the software that I help to develop. Who knows where > >>> the future > >>> leads and what we may or may not do with the software down the > >>> road. It's > >>> especially true for speciality operations that need to do much > >>> customization. You might find in 5 years time that your software > >>> is worth > >>> more than your product... That would be a real bad time to find > >>> out that the > >>> license was different from what you had thought. > >>> > >>> I'm just going to stick with the core of ofbiz and over time I'll > >>> build the > >>> extra functionality that I want and need. > >>> > >>> > > > > >
