As many of you are aware, some applications built
on Interbase rely on Interbase's licensing to control
their own access. Needless to say, Interbase V6
will have no licensing, leaving the developers of
those applications in the lurch.

I bring this problem to your attention, hoping
to find a solution that is consistent with our
open source license, open source philosophy, and
a certain desire to provide real protection
rather than obfuscation.

Thanks,

Ann



Here is the most recent problem:

> > >
> > >A) Each machine running our Server needs a 'Server'
> > >license. Note that this machine can be a 'IB client-only' machine on
> > >Windows. The full server engine needs to be installed on all other
> > >platforms.
> > >
> > >B) Each Interbase 6 Server which is a source or a target for our services
> > >needs a 'Served' license. Interbase 6 Server needs to be installed.
> > >The license is installed on the actual source or target machine.
> > >
> > >C) A LIBS machine (Windows only of course) needs a 'Server Lite'
> > >license. This allows our Server to run on it, and is about
> > >one tenth of the price.
> > >
> > >D) If a machine has a 'Server' or a 'Server Lite' license, it
> > >does *not* need a 'Served' license if it is a source/target. This
> > >will usually be the case for Full Server, and always the case for LIBS.
> > >
> > >E) The above is for IB 6, since you can query a remote server for it's
> > >license mask. We cater for a separate Interbase 5 'IB5Server'
> > >license, but this needs to be installed on the same machine that is
> > >running our Server in A) above. There should be one
> > >'IB5Served' license installed for each IB5 source or target, but we
> > >go by trust, and just look for one.
> > >
> > >F) 4 'license bits' have been assigned to us:
> > >
> > >LIC_Y : Our Server
> > >LIC_T : IB6 Served
> > >LIC_5 : IB5 Served
> > >LIC_H : Server Lite
> > >
> > >G) We depend on two other existing license bits, LIC_I (Database Access)
> > >and LIC_S (Server Access) to determine whether we are a Full Interbase
> > >Server or a LIBS Server i.e:
> > >
> > > if (LIC_S)
> > > FullServer = TRUE;
> > >
> > > if (LIC_I && !LIC_S)
> > > LIBSServer = TRUE;
> > >
> > >H) We use the following logic to determine what licenses are installed
> > >on any particular machine:
> > >
> > >if (mask & LIC_S)*/
> > > LocalLicenses->InterbaseServer = 1;
> > >if ((mask & LIC_I) && !(mask & LIC_S))
> > > LocalLicenses->InterbaseLIBS = 1;
> > >if (mask & LIC_Y)
> > > LocalLicenses->ReplicationFull = 1;
> > >if (mask & LIC_T)
> > > LocalLicenses->Replicant = 1;
> > >if (mask & LIC_5)
> > > LocalLicenses->IB5Replicant = 1;
> > >if (mask & LIC_H)
> > > LocalLicenses->ReplicationLite = 1;
> > >
> > >
> > >I) To re-iterate what happens differently on Windows: If our
> > >Server finds there is no Services API available locally (i.e IB6 is not
> > >installed or is not running) then it loads the IBLicense.dll (installed
> > >with Interbase Client) to find the local license mask. Marco added a new
> > >function to this DLL to get the license mask. I have a copy of this DLL,
> > >but I am not sure (since I have not looked) if this modification made it
> > >into the proper source tree.
> > >

Here's a suggestion.

> Is my understanding wrong in that the IBServer has
> zero knowledge of this application internally? My
> understanding is that this application program is
> simply an InterBase client.
>
> I believe that the 'full_server_install' requirement
> for non-Windows platforms goes away with IB 6.0, doesn't
> it?
>
> ---
>
> Some wild thoughts below ...
>
> Has it been discussed or thought about some sort of
> open source licensing solution. Perhaps it could be
> implemented, tailored, marketed as a 'security'
> feature rather than an ugly 'licensing' mechanism.
>
> Perhaps implemented via SQL security.
>
> GRANT [ FUNC ] CONNECTIVITY remote TO <node_name> KEY <xxx>
> GRANT [ FUNC ] REPLICATION replicator TO <node_name> KEY <xxx>
> GRANT [ FUNC ] USERS 50 TO <node_name> KEY <xxx>
> GRANT [ FUNC ] DDL on TO <node_name> KEY <xxx>
>
> Maybe we implement server functionality much like
> SQL security in that it has no ability until you GRANT
> it permission to behave this way or that?
>
> Or perhaps we could we implement a 'Secure Server' concept. Like:
>
> GRANT [ FUNC ] SECURE_APP/VAR_NAME <code/name> TO <node_name> KEY <xxx>
>
> The default behavior out of the box or off the net would
> be zero functionality until GRANTed. The VAR could develope
> their application in such a way that it encodes security.
>
> Perhaps add a parameter to isc_attach_database(). The default
> client behavior (out of the box or off the net) would be to
> send <null>. If <null> is received by the server it assumes
> its not a secure application. If the client sends a
> <crypt_code>, the server attempts to match the VAR provided
> server_side <code/name> to the <key>. If they don't jive
> error out and exit.
>
> I am sure this has weaknesses and could somehow be spoofed
> by an open source hacker. The idea I was working towards
> was the ability to write a reasonably secure 'application'
> vs. us providing a completely theft proof, secure 'server'.
> Doing so in such a way that all the server was doing was
> accepting and validating values passed by the client (hard
> wired to the app by a VAR) with some value applied to the
> server by a DBA or embedded install (supplied by the VAR)
> to his/her paying customer.
>
> I am not sure we can protect our VARs from theft of their
> product as an open source vendor anyway you slice it. But,
> we could offer some sort of feature to give them the false
> sense of security/enforcement that they enjoy today. My
> guess is that a consumer purchasing a shrink wrapped VAR
> solution is not likely to often be the malicious open source
> hacker that is going to go the extra mile to rip off their VAR.