Skip to Content.
Sympa Menu

mace-opensaml-users - RE: dependencies licensing question

Subject: OpenSAML user discussion

List archive

RE: dependencies licensing question


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: dependencies licensing question
  • Date: Fri, 13 Apr 2007 19:18:09 -0400
  • Organization: The Ohio State University

> I suspect nothing can be done for OpenSAML 1, but is there anywhere
> where I can plead a case of switching the logging and unit testing to a
> framework with license that is liberal enough and compatible with yours?

You can plead your case, but I have basically no time to spend on this right
now and I have strict requirements for:
- shared library and dynamic loader friendliness
- thread safety
- Windows compatibility and "attitude-friendliness"
- no-hassle builds across Linux, Solaris, Mac, etc.

> I know boost has both frameworks under MIT-similar license,

Boost is unfortunately a non-starter until they stop relying on Jam to build
it. Without autoconf support, it isn't something I can use. The last time I
saw somebody ask about that a few years back, somebody involved indicated
that they weren't interested in whether people used their code in
distributed projects, it was a testbed for future C++ standard submissions.
That's great for them, but not so great for me.

Aside from that, I'm not sure what logging you're referring to. I see a test
package, but nothing to do with logging.

> Pantheios is another logging framework
> that actually allow you to extend it with log4cpp and such but itself is
> under BSD-style license.

I glanced at it a while back, but it pulls in a major dependency that is
going to stress C++ compilers, and is nothing at all like log4cpp, so it's
not like it's a simple change. And this would affect Shibboleth moreso than
this code, so it's not something I can treat lightly.

> Either that or wrapping the logging around conditional statements so the
> library could be build without any logging to avoid LGPL polution.

Wouldn't the presence of such code be enough to trigger whatever paranoia is
underlying this? Some of the anti-LGPL issues seem to be based on the
question of whether having method signatures inside the code triggers
licensing concerns even if you don't distribute the actual library.

As far as unit testing is concerned, I like this one a lot, it's a painless
thing for source builders to install on Unix, and I don't have time right
now to go learning something else. We could just omit the tests from the
build with some minor makefile changes. I used to do that and it's not as
though I'm any good at writing them anyway.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page