Round Table on Licensing

Markus Kemper: I've been studying the MPL, GPL and LGPL licenses a bit. I too am in agreement with the use of the MPL 1.1 license.

The one point that I am leary about is the fact that a product licensed under the GPL license cannot be integrated with a product that is licensed with MPL.

The community seems to like GPL quite a bit. Could our license be ammended to allow for this or is that a huge can of worms to do something like that.

Ann Harrison: My understanding is that there are two groups trying to define the future of software development: The "Free Software" group, Richard Stallman as US champion, and the "Open Source" group, Eric Raymond as US champion.

Stallman believes that software should be free. The GPL follows his model. Basically, anything you build that includes any code from a source licensed under GPL must be free. There's a special exemption for the C++ runtime that allows developers to charge for software written in GNU C++. If there weren't, every GNU C++ program would be required to be free.

Under a GNU license, it would be possible to write code that used the server and keep it proprietary, because you don't actually use the server code. Thus, for example, software written for Linux is not required to be free, since it uses Linux but does not build it in. However, the gds32.lib (which I believe is the client side of the remote protocol) would cause problems.

The MPL follows the Raymond model - you can build on it and charge for what you build. As I said before (quoted below), if you change the source code, you must publish your changes. However, you can call the code, or cause it to call your code, without publishing your code.

In short, the two licenses attempt to achieve different ends. I happen to think that developers write better code when they get to eat from time to time and see no way to insure that other than to protect the ability to sell code.

You might be able to come up with a compromise like licensing the server under GPL and gdslib32 and the utilities under MPL. That would certainly discourage others from trying to build what Jason calls "Enterprise InterBase."

However, it would also stifle other, worthwhile and symbiotic (well, not biotic, but sym) projects. I'd stick with Mozilla.

As an adendum here, I believe, for example, that one could remove a module from the current InterBase (e.g., OPT.C, the optimizer), create a new module OPT2.C, replace the calls to OPT_xxxx with OPT2_xxxx or add new calls, without publishing the source for OPT2.C. The only caveat is that there should be no code from the old OPT in the new OPT2 - better yet, the person writing OPT2 should not see the OPT source.

Pavel Cisar: I vote for the compromise model. IB itself is a quite complex piece of code and technology and i'm sure that no one who is voluntary involved in its improvement would like see that someone get big money and advantage from his/her work without paying back to the community.

GNU license scheme (copyleft) ensure that no one can do that. Using GPL for IB server itself still allow that others can create enterprise IB or IB for PalmOS or whatever and sell it. Only marketing model must be different.

GDS32 and tools are different beasts. They must/want be incorporated in "larger work", but above anything they DEPEND on IB. It's definitely better to depend on OPEN code rather than CLOSED, proprietary one. This dependency on closed, proprietary code managed by single entity is the greater disaster of IT industry for years (by converting customers to hostages of their suppliers). By my observations, this is angle of view at least half of open source community.

BTW, i understand your point quite well (i've develop for living too), i love ESR's angle and MPL as well, but over time i realised that in some cases, the GNU is far better (including the commercial and IT industry point of view).

Ed Popkov: Compromise model is great. How 'bout going a bit further and turn it into `competition model'?

Here's what I mean. Server and libgds must be GPL'ed. Source must be available gratis to everyone. All the tools may or may not be released. In fact, it doesn't matter. Why? Because as long as server and interface is open any company, or group, or individual can develop their own set of tools and release them under terms and conditions they prefer.

Producing a decent toolkit is hard but not impossible. I have a working prototype of WISQL for Linux. It runs under X, can connect and execute returning and non-returning queries. It shows the results only in LIST ON, and can't do stats of metadata, but hey, that was me alone, and it took me 2-3 weeks to hack it together. This xv_isql is based solely on examples provided along with IB 4 for Linux and xview toolkit and its never been released before.

I believe a group of 4-5 developers will be able to release the first version of IB tools within 2-3 months. Just a wild suggestion. If Inprise believe they can make money off IB support, let it be so, but this must be a fair play.

Pavel Cisar: Yes, why not ? MPL/GNU pair can be seen from that angle too (they work that way). I have only two additional notes:

• GDSLIB can't use GPL (maybe LGPL), because is linked into your application (AFAIK), so your application will be "infected" by GPL. LGPL haven't such drawback, but library must be in separate binary file, so static linking into application is not possible. MPL allow static links into single binary.
• I guess that IB tools (gback etc.) owned by Inprise should be opensourced (at least for educational purposes). In this case you'll need some license for them.

----

Markus Kemper: Forking may be attractive to some and there will always be 'bad boys' out there.

Ann Harrison: This is really strange. I'm basically a socialist - or was when I last checked - and believe that capitalism looks good on paper, but in practice its dynamically unstable. And here I am, arguing for the power of the market. How age does make fools of us all!

For the "bad boys (and girls)" out there, it doesn't matter much what license you use. If the source is available, they'll use it and all you can do is catch them and sue them - a real no-win situation. So, for the moment, lets ignore the pirates.

Pavel Cisar: It's not about pirates. In open source world, piracy doesn't exist at all (in opposite, you are encouraged to get stuff and use it, no entry barriers). It's about money (what else ? :o).

Ann Harrison: What I meant by "pirates" is organizations that use open-source code in proprietary products, licensed for a fee.

Pavel Cisar: I see. But i guess that it's great difference when someone steal some routines (yes, that happen) and steal whole RDBMS engine. I guess that no one can hide IB in larger work without smell of smoke perceptible from outside :o)

....

In open source, you've trade your work (commodity) not for money, but for mass market penetration and "snowball effect" in product improvement and rapid rise of new business opportunities etc. You'll make money not directly from use of goods (license fees), but from products and activities what are needed to (or are created by) use this commodity.

Ann Harrison: I guess I'd be happier with that if I understood what products and services could fund a major software development effort. Let me give you an example. The InterBase ODS is heavily redundant, intentionally, so that many serious corruptions can be fixed. Or rather, could be fixed if the utility to repair databases had ever been completed.

I think it would take someone about a year, given the InterBase sources, to create a very powerful tool - extremely useful to the community.

Since it would require using parts of the InterBase server code, under GPL or LGPL, the developer couldn't charge anything for the tool, but only from the "products and activities" needed to use it. A book, a course, perhaps a trained wizard who comes to exorcise your database. A well-designed and implemented tool wouldn't require any of those. From my point of view, those licenses encourage the production of obscure and hard to use software and, in the end, cost the customer more than the simple license fee.

Pavel Cisar: No, the opposite is true. Show me any widely used open source product what is obscure and hard to use. I'm sure that you can't. But there is a lot of closed ones. In simple case, no one will use modified IB only to use closed product regardless of its advantages. It's only raise a "pressure" to make open one in community :o) No way. But there is a possibility to tie up such modifications to really vital (closed) technology (operating system services, for example) what users are forced to use. Then your IB will die by horrible death, because no one can use it and you have not access to such closed technology.

Ann Harrison: Under MPL, the developer would publish changes made to the parts of the InterBase source included in the product but could profit from the value of the original work.

Pavel Cisar: Definitely not true. You CAN sell open source software. Of course, some added value is good to justify the price. Let me give you an example. You'll have such tool you're mentioned. You can sell CD with your tool and few non-opensourced goodies + user's guide (not a printed copy of on-line help) for $40. Most of serious IB users will buy it instead download it, because they:

1. get a good media (not a downloaded file somewhere on HD) -> backup copy
2. save time for download
3. get full distribution at once, i.e. version for all platforms, binary + source
4. printed book. Yes, eBooks are good for everyday work and info lookup, but for learning, the paper books are still far better.
5. few bonus goodies, not available elsewhere (for example, special add-ins for your tool)

Then add next advantages:

1. You'll get great credibility for good product (worldwide).
2. You'll get contributors (if 3% of users will contribute, do the simple calculation yourself).

BTW, it's complete different approach based on broad shift with deep roots in whole society (you can look for these roots into Alvin Toffler's books, The Third Wave, for example has good explanation).

----

Pavel Cisar: When anyone decommoditize your product (that is, embrace and extend to closed product), and/or hurt "snowball effect" (main reason why forking is bad), you'll sustain serious damage in your business.

Ann Harrison: I think that the MPL protects the original product quite well - Only the original code can be protected. If someone else can produce enough original code to make a new version of the product so attractive that people will buy it rather than use the free version - that sounds like healthy Darwinian capitalism to me.

Pavel Cisar: Well, and this new, shining, (even partially) closed version hurt (or kill) the open one. I wonder why anyone should contribute to open and free version to give advantage to proprietary one ? I do not.

Please, understand this. If i open my code, this doesn't mean that creation and further development of it doesn't cost me the time, money etc. I still need some kind of payback to cover my expenses. This payback come from wide market penetration (so i can sell distributions. BTW, only small count of Linux users actually download it, most people buy distributions), save expenses from development (user's contributions to codebase) and from opportunities created from product use what i can exploit.

All these are connected containers that make "snowball effect" of open source. When the snowball is large enough, i'll have a fat living, but i'll fail miserably if snowball is too small to pay my expenses. So anyone and anything what steal users etc. and finally hurt showball works against me.

Licenses (and open source ethics -> for example fork taboo) are here to keep flames away from snowball as much as possible. There are always some smoke, but snowball can't survive in hell.

This same apply when i'll keep for me rights to close product etc. No one will contribute to my code to give me an unfair advantage from his work (contributors also expect payback for their efforts, at least as improvements that help them in their business).

Ann Harrison: And I'm not at all sure that LGPL (or even the GPL) protects the original product any better. Since, in the world of free software, return on effort comes from ancillary products and services, the rewards available to a company that forks the product are just as great as those available to the original developer.

Pavel Cisar: No, not at all. Initial developer is still owner of the product (as long as he doesn't resign on it). This fact is widely respected. As long as owner maintain the product and serve needs of customers, he has a community support.

This vendor/customer+developer community is very strong. Look at Linux kernel or Apache or any such project what use GPL/LGPL. Of course, there are forked alternatives, but they fill a niche only. When product give full satisfaction to 80% of users, there is no way for anyone to fork it and survive, because there is not need to switch from users. In opposite, users will stay with OWNER and flame forking party to death. Forking is really rare thing on stable products with large userbase (and IB IS stable product with large user base already).

....

Pavel Cisar: Open source works great as development model and as business model as well (but on different background than business model prevailing today), but all market participants must play with the same set of rules. These rules are set by licensing scheme which protect goods from to be de-commodised (BTW, the "Halloween documents" describe this process quite well).

Ann Harrison: The GNU products seem very solid and good, but I don't understand their economics at all. A quick survey of the Linux market shows that most of the companies are eating their capital. That's not abnormal in a rapidly expanding market, but it's not a great business model in the long term.

Pavel Cisar: Look, nowadays an operating system or a web browser are almost regarded as commodity (no one expect to make big bucks from direct sales). Of course, some OS'es are for money, but other OS'es do not. We are in "transient state" in OS business, web browser business is always commoditized.

Ann Harrison: I'm not sure about operating systems - NT certainly isn't free - Linux appears to be the only "commodity" operating system. Are we drawing general conclusions from a single (moving) data point?

Pavel Cisar: Uh-oh. It's only example, one for all. There is also Hurd, BSD etc. You can also look at Apache or few hundred of web servers, FTP clients and servers, mail agents etc. They are here, i can mention them all :o) Of course, most haven't serious profitable business build on top of them. But single good (i.e. satisfy needs of 90% of potential customers) version of some software (FTP server for example) distributed for free can remove this kind of application from the market and destroy business based on license fees for it. In addition, opening the sources is the way to give a momentum to reach 90% user's satisfaction really quickly.

Ann Harrison: I'm going to ignore IE because the economics of Microsoft are unique and deplorable. Netscape offers a free browser and a low-priced but not free version. That version has features that their free version does not. If there were only a free version, would those features show up in it? Possibly not.

Pavel Cisar: Understand, that IT world five years ago is completely different from IT world two years ago and its current state is completely different than its state two years ago. You can't mix them. Most actions taken two/five years ago have slightly different meaning and impact today from its origin. Actually, MS decision to giveaway IE for free finally went to born and wide acceptance of Open Source two-three years earlier than it could be expected (i can explain why, if you'll be interested). It's funny.

....

Now it's right time to commoditize RDBMS (at least for personal use). MS is always on that way with MSDE, and we're speaking loudly to Inprise to do that with LIBS for years (without success). [BTW, when you'll count IB users, you can realize that significant count comes from free LIBS bundled with Delphi 1]

....

Please, understand that we are on begining of big, wide shift in the IT industry. Linux have been officialy, worldwide accepted as REAL THING only since last year and the Open Source is here only since 1998. We'll see the completely different world in five years from now :o) You'll be sure that opensourcing IB will be evaluated as bold (if not boldest) step on that way (like Linux born or foundation of Mozilla project) by return.

You should also take into account that "commoditizing" full scale RDBMS cause serious damage to other RDBMS vendors. Sybase will be completely out of business in two/three years, MSDE as well, SQL server & NT server will get serious sales damage and probably get out of business (SQL server) in a year or two from release of IB Enterprise edition. Centura will be a history, etc. Do you think, that these vendors will stay and watch it ? Of course not. By putting IB in open source, Inprise actualy declare a war to them. We'll see a really interesting season :o)

....

Opensourcing IB to change DB server to commodity (distribution for free aspect of open source) is bold advance in industry what bring us boost in market based on top of RDBMS (generate new opportunities, job positions and business).

This step will be for sure assaulted by those, who have business based on old model. Those are "the bad guys (and girls)". They can try to "embrace, extend" and then destroy (or at least damage) this shift by reverting it back to old model. That is the main rationale behind use of GNU license for IB server.

Ann Harrison: Perhaps you could explain how the GNU license is better for that purpose than the MPL license. I really don't see it.

Pavel Cisar: Under GPL, no one can revert whole movement back and/or take advantage from it without actually join it. MPL allow that (in case of IB server).

----

Markus Kemper: My personal thoughts are that we need to find the most appropriate license that will satisfy the greatest mass of InterBase and soon to be InterBase developers.

Ann Harrison: That's true, but I think we should consider the needs of both those who develop applications on InterBase and those who would improve and enlarge InterBase itself. For example, the V6 replication was written by an outside contractor, I believe. So it probably won't be open source. Why require that someone who creates a better replication engine must release source?

Or UDF libraries? Or new collation sequences? Or perhaps someone would like to lift everything above the cache manager and put it on a more modern engine. That won't happen if the developer can't charge for his labor. It could be a great boon to those who develop applications on InterBase.

Pavel Cisar: Open source and "classic" (sorry, i don't know the proper term in english) business model are different and don't work too well when they are "deployed" side-by-side without clear border delimited between them. Open source license draw this border in terms of "source code file" and "larger work". It's not perfect, but work quite well for many, and i guess that we should not try to draw new lines right now.

Ann Harrison: The transport layers are very separate from the core InterBase. Perhaps someone would want to write an interface designed for high bandwidth, high latency networks?

Pavel Cisar: Why not ? Open source licenses like GNU family doesn't prevent anyone to do that.

Ann Harrison: They don't prevent them from doing it, they merely keep them from profiting by doing so, unless the find a way to make their software so complex that it requires a book or a course to use. Perhaps the next generation of programmers works only for glory ...

Pavel Cisar: No, if their software will be too complex, no one will use it. They must find the way to multiply userbase and sell distributions and/or added value. There are 1000+1 ways to make money from open source.

----

Markus Kemper: If persons/groups fork the code with the intent to compete with InterBase then I think that we have failed as a community who is trying to promote the awesome InterBase technology.

Ann Harrison: Only the most utopian (and ephemeral) communities exist without laws and police. We're still a good community, even if we have different goals and visions.

Pavel Cisar: Agreed :o)

Ann Harrison: More pragmatically, under the Mozilla license, any modules from the original source that are used in a new product must be open source. Only the code written for the new product can be protected, so it's not a question of someone slapping a new label on InterBase and selling it against NewCo. To compete, another organization must start with the same sources, add significant value, and release all changes to the sources it received. That sounds like a good thing ... and unlikely since NewCo will have all - or most - of the experienced developers.

Pavel Cisar: I would not like see slightly modified IB engine burned into MS Windows 2010 core and wired to 100+1 proprietary, closed services utterly needed for my business. This will get away all advantage from opensourcing IB (at least for me).

Ann Harrison: GNU would prevent that - unless Microsoft was prepared to make their entire operating system open source ... actually, not an impossible outcome of the anti-trust case. But even if Microsoft did that under a Mozilla license, they would have to expose the interfaces to the server code. Other people could write other, better services.

Pavel Cisar: Really ? Are you sure that people can ? MS can make modification to MPLed code (of course, public) to call and use only THEIR proprietary code. Also bear in mind, that I SHALL distribute my open services to environment, where such services are already. What i should tell to my customers ? I will be in same situation as now when i sell & deploy LIBS to customers with MSDE already installed as part of MS Office, or IB on servers where SQL server is. Not impossible, but it's hard to penetrate such environment.

Helen Borrie: In the event that someone were able to produce plug-in products (to some aspect of the transport layer, for example) that wouldn't have been possible were the source closed, and didn't need to redeploy any of the core product, isn't it thereby possible to say that the new product is not touched by the license?

Ann Harrison: Certainly it would be under MPL. I think it would not under GPL or LGPL because, at a minimum, the code would depend on InterBase (server) header files.

Ed Popkov: E.g, we have a GPL'ed InterBase- server and libgds. The latter provides all necessary API calls to make a plugin. 3rd party plugin, that calls these API functions make a larger work together with IB. Under GPL, this plugin also must be GPL'ed. Under LGPL it's not necessary.

However, AFAIK, neither of the licenses prevents authors to deploy the same product under several different licenses, even absolutely incompatible. Something like that is being done by MySQL team. Their Linux version is fully gratis GPL, whereas Windoze version has some restrictions, and IIRC is paid/shareware. Well, IANAL, that's how I understand it.

Also, neither (L)GPL, nor (to my knowledge) [MN]PL have ever stand in court. Everyone says they are good and protective, but noone knows how effective they are in different jurisdictions.

Ann Harrison: For the reasons I've already explained, I favor the Mozilla license.

Ed Popkov: Just a few thoughts:

1. As per MPL FAQ, this license exists in two incarnations, NPL and MPL. The former allows Netscape to incorporate 3rd party code into their closed, commercial products
2. The fact that no one is known to sell software under GPL. It allows charging for distribution and extra warranties.

It also must be GPL, because it requires either to open everything or to distribute nothing. So much on that.

Proprietary code control is not bad if it's reasonable and client part is available under the same license as IB itself. If it's not possible, let it be a tarball.

Jason Wharton: I am opposed to measures that tie the hands of people who want to commercially add-on products. For an obvious reason I have this opinion because I don't want to be forced to GPL my own product. I am still considering the virtues of doing such and may not be opposed to it. If NewCo wants to acquire IBO, then I really am not worried about how licensing will affect. Perhaps someone could spare a moment and share their perspective on what I should do with IBO as regarding its licensing.

I'd also like for it to allow at some future time a closed source Enterprise version of InterBase to be created and marketed.

Helen Borrie: OK, now, I'd like to get some comment back from Ann, Pavel and Ed about this situation. If the new co becomes liable to meet Inprise's contractual obligations, and these include the replication engine and IBConsole (not to mention the OLEDB driver) aren't these modules intrinsic to IB6? And if they are, doesn't that mean they have to be open-sourced along with the rest of the kit?

Can the companies that took those contracts be forced to OS the modules?

What are the implications of 'Yes' and 'No' answers to these questions?

Ann Harrison: It is unlikely that NewCo would become responsible for contracts made with Inprise. A more likely case would be that Inprise would hold the contracts and pay NewCo to service them. That serves both NewCo and the customers - NewCo isn't responsible to them and they can sue someone with money.

As far as I know, there's no clear definition of what is "intrinsic to IB6", but the decision is not necessarily (or likely) based on features promised to individual customers. Since the IBConsole and the OLEDB driver are easily separable components, I would expect either Inprise or NewCo to sell them. I don't know how separable the replication engine is ...

Even if the replication engine is integrated into the InterBase kernel, neither Inprise nor NewCo can force the authors to make it open source. It's possible that they would do it - either from the goodness of their hearts or for some compensation. If not, and if the replication code is heavily integrated, it must be removed. Netscape was full of other people's proprietary code when they decided to go open source. It took months to remove all of it, but that's what they did.

Pavel Cisar: My feelings and opinion are the same as Ann's comments above. Exactly.

About IB licensing, i didn't change my initial opinion, i.e. GPL for server, MPL for GDSlib and tools.

Paul Beach: IBConsole could be open sourced - we own the code

IBReplicator cannot be open sourced unless Synectics wanted to do this. We don't own the code.

The ODBC Driver cannot be open sourced unless someone else other than Merant writes an ODBC Driver or if Merant open sources the code

An OLEdb driver doen't exist at this point in time.

All of these products are separate to the base engine and can be sold / open sourced as separate items.

Ed Popkov: I am biased towards GPL, because it's known, widely used and easy-to-understand to everyone. Also, it's more strict than NPL/MPL- if you can't open all the code, you can't distribute anything. No way to be a little pregnant.

Unlike GPL, Mozilla is a slippery reptile. It allows to partially open the code and re-use contributed work in closed products. Probably it's good for `business', but hey, the business is over, it's Open Source time.

What I say is not a qualified advice- just sharing personal position. However, if new developers are needed, it must be considered that they are unlikely to be lawyers as well. In Open Source world we don't have legal advisors, everyone responds for himself and if I make a mistake, I pay with blood, sweat and tears for it. Mentioned liquids are essential for my body to operate normally, so I'm trying not to spend them too much :)

Helen Borrie: Well, that is exactly the rationale that makes me opt against the GNU licences. I believe GNU is a near-ideal solution for an environment where everything that touches the code can be GNU also. LGPL shows that the time has not yet come where the idealist restrictions of GNU are 100% practicable.

Ed Popkov: We see this from different angles. To me the fact of LGPL existence means that GNU is OK, but people are just not ready to open their minds. Direct sales practice is dying. Turn current business model upside down and you'll get a practice at least twice as profitable just because it's new, save its other advantages.

Helen Borrie: I do Delphi front-ends to my DB apps. When we have Kylix, my front-end IDE will still be oPascal. What happens to the Interbase API if the licence is GNU? Presumably it makes it illegal to upgrade things like SQLLinks and the BDE and the IB components in Delphi.

Ed Popkov: Huh, dump Kylix and get Lazarus or FPK. Why spend $$$ on proprietary compiler if there are _two_ open? Port your frontend and _sell_ it. Under GPL. In doubts?

<<You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.>>

From GNU General Public License Version 2, June 1991. Afraid someone will pass it forward gratis? Why's that if they paid you?

Helen Borrie: So, even from Inprise's own point of view, GNU would be a can of worms.

Ed Popkov: Yes. Got it. What main benefit is expected from opening the source of IB? Let's leave share-healing hype aside by now. I suggest that it's attracting numerous of developers who will be working on IB to make it more, and more, and more, until it's the most.

Great. What kind of skills will be required? C/assembly, good math, networking, threads, text processing etc. There are hordes of talented people in GNU world. But they are selfish. And if we don't play their rules, we won't see them.

Helen Borrie: Not to mention excellent proprietary tools out here like Marathon, which has been upgraded against the 6-beta. It is too much to expect the third parties to turn over their source code overnight, whilst *their* products are still on the low end of the "commoditization spectrum". I'd seen the generalized opening of third-party peripheral products as occurring in parallel with their commoditization, not in anticipation of it.

If IB were solely for Linux, I'd be at least spiritually in sympathy with Ed's point of view.

Ed Popkov: I'm not talking Linux. What I said is that if we have IB open ASAP, this could ease the tension around toolkits. They can keep them if they let people start now. But if we must wait until July....

Do you remember /. article about opening IB? They have already forgotten about it. Now there's a new hit- Transmeta's Crusoe. Next week will bring yet another one.

Also, development teams of MySQL and PostgreSQL are not sleeping. They are working. Right now. While we are forced to sit and wait.

Helen Borrie: For the present, though, MPL has fewer imperfections than BSD does (it's less encouraging for free-riders) and it does allow the existing peripheral products to continue evolving through the commoditization spectrum. It doesn't block us from interfacing with the M$ and other closed APIs for writing non-Linux drivers. This bete-noire is still with us for the time being.

So - if there has to be one licence, then it has to be MPL.

Dalton Calford: No, not just the MPL is a viable platform for business, QPL is also very effective. Different licenses could be applied to different sections.

Helen Borrie: What is QPL and how can we find out about it?

Dalton Calford: But from a different point of view, if the server is fully GPL and the client code is released as examples to connect to the server, then there is no need for a client license.

Helen Borrie: I don't get that. Surely for server-to-server/passthrough solutions, GNU-licensed server code would be just as problemmatical.

Dalton Calford: The client code is simply used as an example starting point for people like Jason to talk directly with the remote server or for someone to develop a ODBC driver that talks directly to the server. No more concerns about GDS32 being multi-threaded or handling events badly.

Helen Borrie: I still don't think this covers the problem of the server code API which is what many third-parties are going to be interested in (not everyone wants to get back to knife-and-fork C progamming...)

Dalton Calford: A no-license approach would allow developers to concentrate on thier own products without worrying about what license is affecting them. It also allows the Database team to concentrate only on the server side.

Helen Borrie: What is a no-license approach? Can you expand on this?

Dalton Calford: A small OS/HW platform that only needs limited client abilities would not need to include the full functionality of the client libs.

Helen Borrie: Surely we ought to be aiming for a situation that doesn't stop any honest endeavour around Interbase but does encourage producers towards opening their source eventually.

[....continuing....]