I need access to an HP-UX system for testing libsmbclient builds

John E. Malmberg malmberg at Encompasserve.org
Tue Jul 3 20:28:55 GMT 2001


On Sat, 30 Jun 2001, Richard Sharpe wrote:

> John E. Malmberg wrote:
> 
> > I have pulled over yesterdays CVS tarball, and will attempt to get todays
> > before I go on a 1 week isolation from the Internet and E-mail.
> > 
> > Is the libsmbclient stuff in that?  I could not find it in the 2.2.0
> > release.
> 
> Yes, it is, but it does not yet build by default. Once I have the issues 
> sorted out in the head branch, I will go for getting it into 2.2.x CVS.

It did not seem immediately obvious to me at a quick glance, but maybe
once I look closer.

On OpenVMS, I can not use the Configure script, so I must build the
makefile and config.h by hand.

Well, the config.h is now about 80 percent built by a script that reads
the .in files and does the tests in a VMS specific manor.

This has exposed some minor bugs in the Config.h.in file and some of the
modules where either they are not obeying the config.h file, or they need
something to exist, so it is a waste of time for configure to test for it.

I do not know if anyone wants a list of these, as I have posted about that
before and no-one followed up.  Obviously I am the only one affected.
  
> > All I really need is a list of routines that are exported to the user of
> > the shared library.
> 
> Hmmm ...

On OpenVMS, the only real difference between a shared library and a
non-shared library is that a shared library is linked with a transfer
vector containing the publically exported symbols.

All the compilers on OpenVMS by default build the object files in a
compatable method.

As I have stated before though, all symbols must be resolved at link time
through either the routines contained inside, or another shared image.

>  
> > Also RMS latest interpretation of the GPL may severly limit the use of
> > libsmbclient shared image to other GPL products.  The only escape clause
> > seems to be something about if it is considered part of the operating
> > system.  I am a bit confused, and my guess is others may be to.
> 
> libsmbclient is made available under the GPL. There is no other choice. 
> See below for reasons.
> 
>  
> > It would seem to possibly also preclude non GPL open source programs along
> > with commercial programs from using it.
> 
> Yes, there are problems for commercial interests who want something like 
> libsmbclient, because it must be released under the GPL. This places 
> them in jeopardy if their business model requires that they not releases 
> their source code.
> 
> Since libsmbclient links against existing Samba code (libsmb) that is 
> already GPL'd, libsmbclient must be GPL'd.

As I read the GPL license V2, there is a clause where the holder of the
copyright can give permissions for the use on a case by case basis.

Such would be the case as with non-GPL open source products.

Before RMS's latest interpretation, software developers were of the
opinion that something like PERL or PYTHON that was not necessarily GPL,
but a different Open source license, could dynamically load in a GPL
license module with out a license violation.

It is real muddy now, since many "scripting" languages on some
platforms can auto magically extend themselves to use any shared library
that is on the system.  Some of these languages are not open-source.

Any user of these scripting languages can use any feature of any shared
library on the system, if they know the interface to the library.

If a non-GPL product is designed to use "plug-ins", it is now apparently a
violation of the GPL if the vendor supplies a plug-in that either is GPL,
or open-source and built on a GPL library.

However if some independent person does, is it still a violation?  And
can the vendor of the non-GPL product supply that independent person's GPL
plug in free with out being in violation of the GPL?

A realworld case would be a commercial package that needs to authenticate
a user.  This is already done for a variety of networks such as NETWARE
and such through plug-ins.  The interface for the plug-ins is publically
documented.

If someone where to write a plugin that uses libsmbclient for this
authentication, how does that play with the license?

The same would be true of any program that will browse files that will
dynamically accept a plug in.

RMS seems to exempt things like the libc library in LINUX from this as it
is an operating system component.

Is there some way that the SAMBA team can, assuming that they can reach
aggreement on this, put a clause in the license to use libsmbclient that
non-GPL code can dynamically link libsmbclient?

Something like:

"non-GPL programs can dynamically link in libsmbclient as long as
libsmbclient is only used to provide SMB protocol access, and that
the non-GPL program does not depend on the existance of libsmbclient to
have material value."
 
> Since Microsoft have decided to attack the GPL, we can conclude that 
> they think it (the GPL) can be defended in court.
> 
> While I can appreciate that there are commercial interests who would 
> like access to a non-GPL'd version of libsmbclient, it will require that 
> such a thing be written from scratch and not use any Samba code. While I 
> can do such a thing, I do not currently have the time, unless someone 
> sponsors me (ie pays). It would be nice to see a version with a 
> BSD-style licence.

I personally have no funds for this, but if I find someone who does, I
will pass your name along.

Regards,
-John
Personal Opinion Only
wb8tyw at qsl.network





More information about the samba-technical mailing list