[Mono-dev] Using Mono Assemblies under terms of LGPL

[Rafael Teixeira]

For starters some background info:

http://www.mono-project.com/I18nGettext  -- Show how to use GetText# which
exposes an Gnu.GetText namespace and thus presumably should package such a
Gnu.GetText.dll as discussed in this thread.

Perusing the released sources of gettext (gettext-0.17.tar.gz), I've found
that GNU.Gettext.dll is built from it (excerpt from
gettext-0.17\gettext-runtime\intl-csharp\Makefile.am):

GNU.Gettext.dll: intl.cs
    $(CSHARPCOMP) $(CSHARPCOMPFLAGS) -o $@ $(srcdir)/intl.cs

So it is not part of Mono, and probably it is just some byproduct of some
native packages dependencies, as you guessed.

More relevant to this discussion is that the license from intl.cs is GPL
2.0, without mention of a linking exclusion clause

 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU Library General Public License as published
 * by the Free Software Foundation; either version 2, or (at your option)
 * any later version.

So your app should be GPL-licensed to comply, which is an even worse
situation for you.
I recommend you to implement your own catalog reading code, reading from the
documentation (sic) of the .po format, and then if you could open source it
under a more sensible license such as MIT/BSD or at least MS-PL it would be
very nice.

Using Mono.Posix will leave you with a native lib dependency with a
GPL+Linking exclusion license, which is probably not that much desirable,
but at least Mono.Posix you can either sign it yourself or just copy-paste
the small wrapper class (Mono.Unix.Catalog) in your own lib as it is MIT/BSD
licensed.

Hope it helps,

Rafael "Monoman" Teixeira
---------------------------------------
"To be creative means to be in love with life. You can be creative only if
you love life enough that you want to enhance its beauty, you want to bring
a little more music to it, a little more poetry to it, a little more dance
to it."
Osho


On Wed, Mar 3, 2010 at 7:44 AM, Jacques Beaurain <jacques.beaurain at gmail.com
> wrote:

> Hi,
>
> Thanks for the response but this does not solve my issue...
>
> On Tue, Mar 2, 2010 at 4:12 PM, Jonathan Pryor <jonpryor at vt.edu> wrote:
> > On Tue, 2010-03-02 at 12:21 -0500, Jacques Beaurain wrote:
> >> ...  The issue that we face is
> >> that this assembly is not signed and we need to be able to place the
> >> assembly in the GAC of Microsoft Windows systems. What is the
> >> recommended way to handle this situation?
> >>
> >> In particular we are interested in the GNU.Gettext.dll assembly.
> >
> > Er, what?  I don't see this assembly in my GAC (both the distro-provided
> > and my trunk installation), nor do I see a GNU.Gettext.dll assembly in
> > my source tree.  Where are you seeing this assembly?
> >
>
> It is in the lib tree of the current Mono release build. My guess is
> that the build process builds it by pulling in the gettext sources.
>
> > To answer the original question, the answer is: don't.  For the love of
> > all that is good and holy, don't strong-name an assembly that isn't
> > strong-named and install it into the GAC.
> >
> > Strong-naming is an indication that the API won't change in an
> > incompatible manner, possibly ever.  Upstream likely won't even know you
> > did this, will eventually break API, and cause all manner of pain.
> >
> > (Case in point: Mono has two separate copies of SharpZipLib because they
> > changed their API in an incompatible manner.  I don't know who
> > strong-named it -- i.e. was it it Mono being bad, or were they screwing
> > things up -- but it's not a good situation to be in.)
> >
> > YOU have sources and a compiler toolchain.  If you need a strong-named
> > assembly, fold it into your own assemblies and strong name *those*, so
> > that responsibility for maintaining API compatibility is clear.
>
> This is exactly the issue, the assemblies that need to use it is
> strong named already and can only reference strong named assemblies. I
> would love to fold the functionality into  my own assemblies but are
> not allowed to do so under the terms of the LGPL. Anyway my solution
> is gravitating to not using this assembly at all and using interop to
> the unmanaged gettext libraries instead which should allow us to abide
> by the LGPL terms.
>
> >
> >  - Jon
> >
> >
> >
>
> Jacques
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100303/569fb4ae/attachment.html