ccan code breaks older build farm systems

[Michael Adam]

Hi Andrew,

Andrew Bartlett wrote:
>
> On Thu, 2011-07-07 at 13:54 +0200, Michael Adam wrote:
> > ...
> > 
> > Anyhow, since you added the ccan code so that it is directly linked
> > to virtually all samba3 binaries via the LIB_OBJ collection in
> > source3/Makefile.in, to my understanding, you need to relicense
> > the LGPL files to GPLv3:
> > 
> > http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
> > 
> > It says, it is OK to include the LGPLv3 code into the GPlv3+
> > project if you relicense the copy of LGPLv3+ code that is
> > included in samba under GPLv3.
> >
> > Generally, I think we should make it more clear in our code tree which
> > code is original samba code and which is external contributed code.
> > 
> > I think we should not put such external code directly under lib/
> > but add a contrib/ folder (or similar) to contain externally
> > contributed code.
> 
> Michael,
> 
> As to names, a contrib folder is traditionally for code that is hosted,
> but not supported by the project.  ie, contributed modules that have
> external maintainers.  Certainly another name could be chosen however.

Sure, we mmight chose a different name. It was just a quick example.

> As you know, we have quite a bit of external code in the tree, which
> maintains it's original licence headers and is not in any one location -
> we have lib/popt, source4/heimdal, source4/scripting/samba-external and
> buildtools/bin/waf*.  In most cases we have a README explaining the
> original source, but we may be missing some.  I would not favour a
> wholesale relocation of code to create an artificial line between
> 'samba-developed' and imported codebases. 

Well, I would consider it very useful.

This would make it clear right from the path to the file
which files a "normal" samba developer can simply touch and
which files one should not.

And yes, I was thinking about the above examples.
lib/popt for sure, and heimdal.
waf is different since it is the build system and not
part of our server or client tool binaries.
And scripts are unaffected to my understanding since we don't
link them to our GPLv3 binaries or do we?
(And the name "scripting-external" pretty clearly states
that these are, well, external. :-)

> I understand how you read the FSF's website suggesting that we have to
> change licence headers of imported code.

I was not speaking of suggestions!

I was understanding  from the GNU page above that we do for example
violate our own GPLv3+ license of the server code if we directly
link in the LGPL ccan code or for instance the talloc and tdb
code. It states that if you directly use LGPL code (i.e. tdb,
talloc, ccan, ...) in a GPL project, than you have to relicense
it. If you link it as a library however, that is ok.

So at least in the samba3 autoconf build, we have a problem since we do
link the plain object files into smbd if we link talloc or tdb
statically. It might be different in s4 and with the waf build.

That being said, let me state clearly that I am not an expert on
licenses, but that I am trying to understand what I read on the
GNU documents. So if anyone (Simo??) could shed some light on the
licensing issues for me, I would be really greatful!

> However, this has not been our practice in the past,

That is not an argument at all, if we do violate our own license by it.

> may be considered rude by the original authors, (yes, it happens!)

Well LGPL gives you the permission to relicense under GPL.
We might need to do that for some code portions.
If the author considers this rude, then he should not have
chosen LGPL in the first place.

> would make it harder to clearly contribute that code back.

We would have to dual-license code that we want to contribute back.

> As a thought experiment, imagine if we did that to the Heimdal
> codebase we also host!

I don't know whehter this applies at all.
If we only link in the code as a library (.so or .a) then
we can stop here. If we also use it directly, then we should
consider relicensing the corresponding pieces.

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20110707/6d498aec/attachment.pgp>