is db4o completly free ? - db4o Developer Community - Forums - English Forums

Developer Community db4o open source object database, native to Java and .NET

Unanswered Active Topics

Forums

Forums > English Forums > db4o User Forum

is db4o completly free ?

Last Post 04 Nov 2005 06:30 PM by mkarnati. 23 Replies.

Sort:

Prev Next

You are not authorized to post a reply.

Page 1 of 2

Author

Messages

flyingman

New Member

24 Oct 2005 12:03 PM
Hi i am planing to develope a software with a free Object Orinted database. is db4o completly free ? Thank.

patrick_roemer

New Member

24 Oct 2005 04:30 PM

flyingman wrote:
is db4o completly free ?

It's as free as your software is. :)

Please check:

http://db4o.com/about/company/legalpolicies/gplinterpretation.aspx

Best regards,
Patrick

yellow_emperor

New Member

27 Oct 2005 11:26 PM
Patrick's reply is not the whole story. The GPL interpretation preferred by the db4o developers is, in certain regards, contrary to the canonical interpretation published by the Free Software Foundation. Citing the four elements from the URL listed in Patrick's post (that force 'your software' to inherit the GPL): You compile your software against the db4o software; Your software contains specific references to the db4o software; Your software requires the db4o software to work; or Your software uses the proprietary API to the db4o software. The first point is generally agreed upon by the open source community and by the FSF in particular. Statically linked library compilation causes portions of the library code to be written into the final executable binary file produced by compilation. Thus, it is argued, that the resulting binary is inseparable from the library code, making it a derivative work. In the interpretation of the FSF, dynamically linked library compilation has been included in this conception for various reasons. (It is easy to argue the contrary for DLLs, and, by certain extension, for SLLs, but the FSF's interpretation is likely to be the one accepted by an official arbiter such as a judge in civil court.) However, any separation of function that extends beyond code-linking does not force inheritance of the GPL. Let me point to an example given by the FSF in association with the GPL to make this clear: the Linux kernel is licenced under the GPL, but neither a command-shell nor a text-file editor written for Linux must necessarily inherit the GPL. Any shell must be capable of executing commands and exploring the file-system. To do this, it must execute system-calls. System-calls are a kernel's API for performing tasks of all kinds. In the Linux world, extensions to the POSIX API exist that could arguably make the Linux API proprietary. (See the fourth point cited above.) Because of this system-call dependence on the Linux API, any Linux shell is so dependent on Linus's kernel that it could not run on any other POSIX compliant kernel without a new compile from source, and in some cases, source modification. With general agreement, any particular binary distribution of the shell would require the kernel it was compiled for in order to work. (See the third point cited above.) Much of the same applies for a text-editor. Beyond the system-call level, the text editor may even use facilities provided by its calling shell, including invoking other commands using a POSIX (Bourne shell, 'sh') compliant or more proprietary (take 'bash' extensions to 'sh' for example) shell language. In the case of the shell or the editor, invocation of GPLed components via proprietary command-line or system-call interfaces counts (in any meaningful sense) as a specific reference to that GPLed software. (See the second point cited above.) Keep in mind that open source, and specifically GPLed software of all kinds can be interfaced with using the network layer or the command-line, and the code that does this is NOT considered a derivative work by the FSF, or anyone who credibly interprets the GPL. Consider MySQL AB. They publish their RDBMS under the GPL, but their connectors (interface DLLs) under the LGPL. The connectors are not required to inherit the GPL. The LGPL is a little more relaxed, allowing you to link covered code into your own. By a strictly literal interpretation of the GPL, a product like db4o may be used without particular concern, providing that you have not edited db4o code into your code, and you have not modified db4o code. (A scenario where your software could be installed, and a stock db4o package could be installed, and neither product needs to make changes to the layout or content of the other to function.) Because of this reality, an individual or organization considering the release software under the GPL should consider it roughly equivalent to giving the software away. Be warned though. The writers and maintainers of the GPL (the FSF) have a different opinion. They draw the line past SLLs and through DLLs. The FSF is likely to define reality in a legal setting. But there is still ground to stand on. Because using db4o is tentatively in the SLL/DLL camp, you could produce a GPLed component that exposes db4o functionality in some other way (e.g.: command-line, or more likely: TCP/IP for localhost or remote use, or even a web service or other SOA exposing service). Then anyone could use that GPLed component as an interface to db4o from their own software (proprietary, for sale, BSD, Apache2, GPL, LPGL, whatever). At very least, the second, third and fourth statements cited above are not consistent with the GPL or valid interpretations of it. An individual or organization desiring those caveats should not release the software under the GPL. Instead, a new license should be written or a new licensing scheme should be devised.

Christof

Veteran Member
Posts:1170

28 Oct 2005 01:47 AM
Yellow_emperor, thanks for your extensive discussion of the GPL. What is important to know is that db4o's GPL version is free of charge, but not free of obligations: If you use GPL software, you have to give back under the GPL. Now, as you point out, there is a range of interpretations of the triggers for inheritance of the GPL. To be able to give our users a clear guideline we have asked one of the word's most knowledgeable law firms, Fenwick & West, that has done plenty of GPL litigations, to provide this statement. I am pretty confident that these guidelines are not contradicting the GPL. Let's take a step back: The GPL version of db4o is for those developers that are members of the open source community. Open source is about sharing - give and take. What you are really discussing are hybrids of open source and closed source software and how to walk the fine line to circumvent the very spirit of the GPL. I think, if you decide not to open source your software, usually for commercial reasons, then you should really not free-ride on open source offers. For this case, we offer an alternate, very affordable commercial license. It runs at cost which are much lower than any incumbent, closed-source software alternative. These small license fees enable the team to provide a great product, great support and an ecosystem around the db4o platform. If you still take the risk and use open source software without giving back, you should not be surprised if both, the open source community as well as the db4objects' team, will not be happy about it. Does that make sense? Christof

yellow_emperor

New Member

28 Oct 2005 09:13 AM
What is most desirable for db4o and their licensees is the existence of harmony between the db4o business model and the db4o software license. I suggest that this may not be the case. One evaluation of db4o's desire (based on claims made on their web-site) is, in simple terms, that everyone except commercial users should have access to their software under the GPL (and that commercial users should have to pay). One obvious way to realize harmony in a case like this one is to subordinate the GPL to a larger licensing scheme. An approach could be formulated that would say explicitly that non-commercial use of the software is subject to the GPL, but commercial use (which would require some work to formalize) is subject to separate license terms. Any potential sticking points for this model in the GPL or in the FSF interpretation could be circumvented by referencing the GPL as a licensing model, but making explicit the fact that a different license, including certain caveats, applies. It should be noted that stating an interpretation of a software license is not the same as explicitly defining a license that would apply as those interpretations suggest.

erdsah88

New Member

30 Oct 2005 02:08 PM
I am confused..... if the company is going to use the db4o only in one server ?What does it pay? if there a place that we can look for licencing.... (sorry it took me 6 months to understand SQL and oracle licencing please help)

Christof

Veteran Member
Posts:1170

30 Oct 2005 05:17 PM

erdsah88 wrote:
if the company is going to use the db4o only in one server ?What does it pay?

If you download db4o under the GPL, develop an application and use this application including db4o inhouse only (i.e., no redistribution), it is fine to use the GPL'd version of db4o without you being obliged to open source your "derivative work" (i.e., the application itself) under the GPL to the public.

The trigger for the GPL obligations are the redistribution.

In short: No redistribution, no GPL constrains. If there is redistribution, you either go GPL yourself or choose the affordable commercial license of db4o.

erdsah88 wrote:
if there a place that we can look for licencing....

http://www.db4o.com/about/company/legalpolicies/gpl.aspx

http://www.db4o.com/about/company/legalpolicies/gplinterpretation.aspx

http://www.db4o.com/commercial/purchase/policy.aspx

or inquire sales: http://www.db4o.com/commercial/purchase/enquiry.aspx

Christof

mkarnati

New Member

03 Nov 2005 11:39 PM
Please say YES or NO. I have a website and I make my living out of it by selling ads and goods and services from that site. I am planning to use db40 as a backend datastore for that. I have developed a java/dotnet based web application and I am using db4o for my datastore. I am under the impression that I don't need to buy any commercial license for this purpose eventhough I am making money out of my website. And also, if somebody asks me to share my application code with the public, since I am using GPL license, I am not legally obliged to share my application code.

mkarnati

New Member

04 Nov 2005 12:00 AM
Sorry I hit the post button before I complete my second scenario: Scenario 2: I have developed a Java/C# application and used db4o as a datastore. I want to sell my application and make money. But, here, I have not changed any code of db4o. I am simply using its .jar file. That's it. And, what ever I am charging my user, I am charging for my labor on my application code and I am not giving him the source code of my application. In this senario, I need to go for a commercial license of db4o eventhough I am not changing any code. Because I am distributing db4o along with my application to the user, and my application is dependent on db4o as a datastore. Scenario 3: I have developed the above application (mentioned in scene 2) and just sold it to my users without distributing db4o database with it. But, I will advise them to download the GPL version of db4o and use it with my application. Since I am not distributing db4o along with my application, I don't need to buy any commercial license for it. And also I don't need to share the source code of my application with the public since I consider it as proprietary and my own and I am charging only for what I have developed.

Christof

Veteran Member
Posts:1170

04 Nov 2005 12:15 AM

mkarnati wrote:
Please say YES or NO.

I always like to say "YES", but...: What is the question? Wink [;-)]

mkarnati wrote:
Scenario 1:

I have a website and I make my living out of it by selling ads and goods and services from that site. I am planning to use db40 as a backend datastore for that. I have developed a java/dotnet based web application and I am using db4o for my datastore. I am under the impression that I don't need to buy any commercial license for this purpose eventhough I am making money out of my website. And also, if somebody asks me to share my application code with the public, since I am using GPL license, I am not legally obliged to share my application code.

I am not a lawyer. If you want peace-of-mind, you need to go and get legal advise or become a (commercial) dDN member - the latter is cheaper and also helps us to continue to invest into the product and to make our living.

In general, though, the classical question is two-part and goes like this:

a) Am I obliged to buy a commercial license of db4o for this use case?

Answer: No.

You can (always) use GPL licensed db4o.

b) When I use the GPL version, am I obliged to share my application code ("derivative work") with the community?

Answer: No.

Unless you re-distribute your application code - in this case you need to open source it under the GPL and notify all users about it and link to where the source code is available. Redistribution could include shipping your application to a provider, a subcontractor or to any other third party... there's a wide array of legal interpretations.

Also keep in mind that the GPL 3 is on its way which will address a couple of issues, specifically with respect to using GPL'd software in Web services.

Scenario 2:

I have developed a Java/C# application and used db4o as a datastore. I want to sell my application and make money. But, here, I have not changed any code of db4o. I am simply using its .jar file. That's it. And, what ever I am charging my user, I am charging for my labor on my application code and I am not giving him the source code of my application. In this senario, I need to go for a commercial license of db4o eventhough I am not changing any code. Because I am distributing db4o along with my application to the user, and my application is dependent on db4o as a datastore.

Again: You can use the GPL version for free, but you must open source your application under the GPL. If you don't you will be in breach of the GPL license terms.

Or: You buy a commerical license which gives you the right to redistribute db4o and derivative work close-source.

The trigger is the redistribution, not whether you have modified the db4o source code (that is something that applies to the LGPL, but not the GPL)

Scenario 3:

I have developed the above application (mentioned in scene 2) and just sold it to my users without distributing db4o database with it. But, I will advise them to download the GPL version of db4o and use it with my application. Since I am not distributing db4o along with my application, I don't need to buy any commercial license for it. And also I don't need to share the source code of my application with the public since I consider it as proprietary and my own and I am charging only for what I have developed.

This scenario is the same as 2.

You hit all 4 triggers we specifically spelled out for the GPL applicability (db4o specific interpretation of the GPL):

You compile your software against the db4o software;
Your software contains specific references to the db4o software;
Your software requires the db4o software to work; or
Your software uses the proprietary API to the db4o software.

What you really do with this setup is to circumvent the spirit of the GPL, which is: If you use open source GPL components, you have to be GPL yourself. Take and give. Give and take.

What's so bad with sharing a small fraction of your revenue with someone who provides a major component and saves you tons of time? Also, your small contribution puts us in a situation to provide support, continue the product development and also take into account specific features that you need (as opposed to other dDN members).

Christof

yellow_emperor

New Member

04 Nov 2005 01:23 AM
According to accepted interpretations of the GPL, if you separate your code from GPLed code in a way that does not involve compile-time dependence on GPLed components, you are not required to apply the GPL to your code. By this interpretation, any component that interfaces directly with db4o must inherit the GPL if it is distributed. ('Distributed', in this context, means made available for license outside of the organization that produced the code in question.) This is because such code must include the db4o interface classes (to interface with the engine or with the client access connector, both available under the GPL). It is conceivable that some projects might achieve a level of separation from db4o that would not require them to inherit the GPL. For example, a team could study the db4o client-server protocol, and produce a complete implementation of a db4o client that could replace the db4o client, or exist as a component of a larger project. As long as the client code does not contain db4o source, it is not required to inherit the GPL. Another team might decide to include db4o inside a web-service or eventing framework. An interface to an object-persistence layer could be conceived, designed, implemented (as Java classes for example) and published to the public domain. A module that adapts the db4o interface to the framework interface would be required to inherit the GPL if distributed. But other modules that worked within the framework would not be required to inherit the GPL, even if they had to compile against the (public domain) interface. The 'distribution' qualification introduces other possibilities for individuals or organizations desiring to use GPLed code as components of their own software without inheriting the GPL. In some cases, clients pay firms for access to their software resources. In cases like these, software does not count as being distributed. Also, one firm could rent usage of computer hardware from another, and run software on that hardware without it qualifying as redistributed. Worse, if a company can tolerate selling licenses to use their source code (and not compiled binary forms), then code that would include GPLed code during a potential compile process is not necessarily required to inherit the GPL. A client could then build the code against the GPLed code (using prepacked 'make' procedures), and could use the resulting product in-house. (The client in this model is not able to distribute the result unless the purchased source code license allowed them to re-release the purchased code as GPL.) These caveats get even worse when you consider scripting languages. In cases like these, a make procedure is often not required (because the source code is the operational form of the program).

Christof

Veteran Member
Posts:1170

04 Nov 2005 02:37 AM
Yellow_emperor, I appreciate you sharing this. Just take a step back, though: You explain with a lot of diligence how commercial, closed source companies try to circumvent the intention and spirit of the GPL and use free, GPL software components without neither giving back to the community nor pay for it. I agree with you that there are many interpretations of the GPL out there. The entire thread here and the calls for "plain English" reflect that very well. Because this is not very user friendly, db4objects has introduced the GPL interpretation policy which eliminates all this disturbing and economically risky ambiguity. This concise framework is still within the boundaries of the GPL, but without the ambiguity of its interpretations. I respect that someone might not like the outcome (i.e., that there are less free-riders on this ambiguity), but I think we all agree that we're better off having a clear policy in place rather than ambiguity which will then just end up wasting our time discussing over licensing issues and/or even paying lawyers for it. We at db4objects prefer to invest in good software and service rather than lawyers. So everything is very simple: If you are open source, we are open source and share all we have freely with each other. If you are closed source (i.e., commercial) we ask you for a small contribution once and not until you ship (distribute) your software, i.e., when you collect money from your own customers and when you are in a position to pay your suppliers. As a result, db4o's dual license policy is IMO: concise and unambiguous and fair because the product is very affordable (much lower unit prices) and cash saving to those that make money using db4o (... and we can only afford this because we have much lower cost than conventional vendors by leveraging db4o's open source status) the product is free for those that can't afford paying for software (like students, faculty, researchers, evaluators, community projects etc.) but who can retribute their own work instead because they don't need to protect commercial, proprietary IP If someone cannot agree to this, he/she is better off to look for alternatives to db4o. Christof

mkarnati

New Member

04 Nov 2005 06:30 PM
Thanks Christof for your quick response. I totally agree with you. In fact these questions were asked by one of my friends and simply rephrased his questions by creating scenarios. I gave almost a similar reply for his questions, but he was not convinced. So, I wanted to check my understanding . Thanks, Mallesham Karnati

yellow_emperor

New Member

05 Nov 2005 05:18 AM
For the benefit of the db4o team, I am on their side. I want to see open source technologies succeed, and business models that allow organizations to be profitable and continue to contribute to the open source community are of particular use in a market economy like ours. For the success of such businesses and the projects they support, careful business execution is valuable. One domain that calls for particular care is the choice of a licensing model. Hence my previous comments in this thread. A week ago, I sent this message to the law firm you mentioned: -------------------------------------------------- I was recently reading through the community forum provided on the db4o web site, and discovered a reference to an interpretation of the GNU General Public License endorsed by the db4o developement team: http://db4o.com/about/company/legal...ation.aspx In the same context that this reference appeared, the forum poster (Patrick Roemer) indicated that your law firm was responsible for this interpretation. In what sense is Fenwick and West responsible for this interpretation? I ask because the interpretation, specifically the four bullets indicating circumstances under which software must inherit the GPL are misleading. By strictly literal interpretation of the GPL, none of the statements actually applies. The Free Software Foundation publishes a body of work explicating their interpretation of the GPL. By FSF interpretation, only the first statement applies. The other claims simply hold no bearing on the reality of code released under the GPL. The FSF does not appreciate misinterpretations of the GPL. Overly liberal interpretations do not provide important restrictions necessary to protect accepted implementations of technology standards. (As is the case here,) overly conservative interpretations promote misunderstanding of the intent of the GPL and allow organizations who are not interested in the meaning of the GPL to gain benefit by affiliating themselves with it. Worse, an organization might rely on a conservative interpretation of the GPL to protect their software, where such protection is not actually afforded. (Commercial protection is not the intent or in the spirit of the GPL.) The best scenario is one in which the GPL is applied as intended by organizations who understand its implications. For projects where the GPL does not match the business model well, a different license or licensing scheme would be applied. Ultimately, a world in which free software is allowed to flourish under terms equally acceptable to its users and developers will provide the greatest advancement of humanitarian and humanist goals. -------------------------------------------------- I have not yet received a reply. I do not dispute the reasonable nature of db4o pricing, and I would argue for the usefullness of a financially supported db4o team. I am suggesting that a license should be applied to db4o that protects it in a way that the db4o team can accept. (An interpretation of a license's terms is not the same thing as a license that satisfies such an interpretation.) An organization that desires to license their software similarly to the GPL but under a specific and controversial interpretation is in a position that is best resolved by devising a new license. If such an organization applies the GPL anyway, the organization implicitly accepts that licensees can and will use the software under the terms of other interpretations of the GPL; and that these interpretations may not agree with the interpretation endorsed by the organization. It appears as though db4o may be in this position. While it is nice to consider what individuals and organizations should do in a situation, it is not reasonable to anticipate that these concerns will dictate behavior, especially in a business setting. If the debate is over the perception of license applications by the community, it should be noted that the intent or spirit of the GPL is often framed in a particular way. It is commonly believed that the GPL is designed to protect standard implementations of information technologies from becoming proprietary. In this view, the danger is not that commercial organizations will use the standard or sell products built on it. (In fact, this is even desirable if it means that the standard technology receives support and acceptance.) Instead, the danger is that a proprietary solution might be able to borrow from the standard, produce a better product, and then supplant the standard in common use (thus taking control of the standard away from the community). In this spirit, the GPL is intended to give an implementation away, and entrust it to the community. Interpretations of the GPL have flexed to incorporate other intentions in certain domains, but it could be argued that this flexing has a negative impact on the community by spreading uncertainty and fear about the use of GPLed standards. For example, the spirit of the GPL can be maintained even when incorporating a statically linked GPLed library into a proprietary product. In this case, the product vendor might be under some onus to explain to its clients that a given binary executable included object code generated from GPLed source code. (This covers the obligation not to claim the code as the vendor's creation, but even better, generates visibility for the GPLed library.) Now that interpretations of the GPL prevent this behavior, the FSF has brought us the LGPL. A good thing, but it should be unnecessary. Now we have more licenses and more confusion.

mpc823_99

New Member

03 Feb 2006 04:59 AM

yellow_emperor wrote:
Another team might decide to include db4o inside a web-service or eventing framework. An interface to an object-persistence layer could be conceived, designed, implemented (as Java classes for example) and published to the public domain. A module that adapts the db4o interface to the framework interface would be required to inherit the GPL if distributed. But other modules that worked within the framework would not be required to inherit the GPL, even if they had to compile against the (public domain) interface.

Wow, this is exactly my question. I am actually building an event framework using the eclipse rich client platform (RCP). I have a general framework for accepting events into the system and triggering registered listeners. Because I'm using the RCP, I have designed the system to be very modular. With the basic framework in place, one module that I am now writing is a listener that registers to receive all events and stores them in a database. DB4O seems well suited to this task.

My question is then what licensing restrictions, if any, fall onto the framework? Certainly I have no problem GPL'ing the database module itself. However, GPL'ing the general framework would not be looked on favorably at my company. My reading of this thread, the GPL, and DB4O's interpretation lead me to believe that I only would have to GPL the particular module, not the entire framework. But what happens if I provide an API for others to use (utilizing extension points)? Do other modules that use that API then fall under the GPL?

Christof

Veteran Member
Posts:1170

03 Feb 2006 06:00 AM

More information here

Without being able to make a final assessment from this point, there is one trigger ("Your software uses the proprietary API to the db4o software") that seems to apply here.

mpc823_99 wrote:
However, GPL'ing the general framework would not be looked on favorably at my company.

That is the key point:
If your company doesn't subscribe to the ideals of the open source movement and deems open sourcing software under the GPL as a negative thing, there is IMHO a strong point in also not relying on free GPL'd input components to write this software in the first place. This is really a form of free riding on the work of other people that give great software out there for free, provided that you give back great software, too.

I suggest to get a commercial license at sales at db4o dot com to prevent that your proprietary, closed source IP becomes subject to the rules of the GPL, i.e., making the entire source code publically available.

Christof

Eric Falsken

Advanced Member
Posts:924

03 Feb 2006 07:23 AM

mpc823_99 wrote:

My question is then what licensing restrictions, if any, fall onto the framework? Certainly I have no problem GPL'ing the database module itself. However, GPL'ing the general framework would not be looked on favorably at my company. My reading of this thread, the GPL, and DB4O's interpretation lead me to believe that I only would have to GPL the particular module, not the entire framework. But what happens if I provide an API for others to use (utilizing extension points)? Do other modules that use that API then fall under the GPL?

Well, mpc823_99, this is an interesting case. But I could draw a very similar case that will certainly clear up the issue for you. What would happen if you wrote your own db4o adapter. Let's just say, for simplicity, that your persistance layer didn't actually persist anything, but worked as an adapter so that you could "plug-in" different persistance solutions...of which db4o may only be one of them.

Then let's say you sold your persistance framework under a closed license. It has no db4o bindings, correct? You could use it with any form of database. Fine.

Now you have your "db4o adapter". You've got a choice. Personally, you prefer not paying for db4o. So you choose to GPL your adapter. But your adapter requires your closed-source framework to work. (Does the GPL allow you to include non-GPL requirements? I'm not sure. But let's move on...)

Ok. So now, someone can pay for your framework. But when then want to use db4o, then they've got to make the same choice. They're using your db4o adapter....which is offered via the GPL. Gee. I guess they have to either GPL their application, or buy commercial licenses for ALL of their included components....including your adapter. (I hope you are dual-licensing it.)

The trigger in this case is that they are including GPL code in their application. Even if they are using it indirectly.

It's rather simple. You either like the idea of free software, and offer yours for free also. Or you pay for software you use, and charge for your own. (if it pleases you)

mpc823_99

New Member

03 Feb 2006 04:57 PM

Thanks for the responses so far, I appreciate it. I'm not actually out to get a free ride, but trying to figure out what is the best course of action, given that what we want to do is encourage third parties to add to the framework.

Eric Falsken wrote:

Well, mpc823_99, this is an interesting case. But I could draw a very similar case that will certainly clear up the issue for you. What would happen if you wrote your own db4o adapter. Let's just say, for simplicity, that your persistance layer didn't actually persist anything, but worked as an adapter so that you could "plug-in" different persistance solutions...of which db4o may only be one of them.

Then let's say you sold your persistance framework under a closed license. It has no db4o bindings, correct? You could use it with any form of database. Fine.

Eric Falsken wrote:

Now you have your "db4o adapter". You've got a choice. Personally, you prefer not paying for db4o. So you choose to GPL your adapter. But your adapter requires your closed-source framework to work. (Does the GPL allow you to include non-GPL requirements? I'm not sure. But let's move on...)

Well, I personally don't have a preference one way or another. My company may prefer whatever leads to encouraging third parties the most.

Eric Falsken wrote:

Ok. So now, someone can pay for your framework. But when then want to use db4o, then they've got to make the same choice. They're using your db4o adapter....which is offered via the GPL. Gee. I guess they have to either GPL their application, or buy commercial licenses for ALL of their included components....including your adapter. (I hope you are dual-licensing it.)

The trigger in this case is that they are including GPL code in their application. Even if they are using it indirectly.

It's rather simple. You either like the idea of free software, and offer yours for free also. Or you pay for software you use, and charge for your own. (if it pleases you)

And I think this argument highlights why it may be preferable to do a commercial license. But what I originally wanted may have gotten a bit lost. Your initial scenario is fairly accurate - that is, we build a framework that has nothing to do with any particular database at all. Now, if we or a third party comes along and uses DB4O or something else that's GPL'd, my thought (and hope) is that is does not affect the framework at all. It will affect that particular module and perhaps any other module that uses it. From helping make business decisions, it is helpful to know exactly what things get affected by use of a plugin that utilizes GPL code. My motivation was not how I could get a free ride, but how I could accurately determine the effects of using GPL code in order that the best business decision could be made.

But I think you've accurately captured it. In order to give the most flexibility to third parties, a commercial license makes the most sense.

squeebie

New Member

10 Feb 2006 08:16 PM

Christof wrote:
If you download db4o under the GPL, develop an application and use this application including db4o inhouse only (i.e., no redistribution), it is fine to use the GPL'd version of db4o without you being obliged to open source your "derivative work" (i.e., the application itself) under the GPL to the public.

The trigger for the GPL obligations are the redistribution.

In short: No redistribution, no GPL constrains. If there is redistribution, you either go GPL yourself or choose the affordable commercial license of db4o.

Sorry to rehash this, but what counts as redistribution?

DB4O says:
"In all of these situations, if you distribute or publish your software, you will have to make available source code for your software, in addition to meeting other GPL requirements for your software."

If I have a website that makes money from ads or membership, and my site uses DB4O as a data store, do I have to GPL or buy a license? I'm not sure if having a website that uses DB4O counts as "redistribution" or "publishing".

Thanks in advance.

Christof

Veteran Member
Posts:1170

10 Feb 2006 08:57 PM
Hi Whether you make money or not doesn't count at all. Whether a website is a redistribution is controversial. We as vendors believe it is, but most out there don't (just think of how many websites are run with MySQL using the GPL version). The GPL 3 is set to clarify this. If you want to make sure, you have a proper license, please contact sales and you can enjoy the benefits of a properly licensed db4o, free updates, and 24/7 support - all bundeled into an affordable dDN membership. Christof

You are not authorized to post a reply.

Page 1 of 2

Forums > English Forums > db4o User Forum

Active Forums 4.2