Re: [Mono-dev] Using Mono Assemblies under terms of LGPL
Hi, Thanks for the response but this does not solve my issue... On Tue, Mar 2, 2010 at 4:12 PM, Jonathan Pryor jonpr...@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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Using Mono Assemblies under terms of LGPL
Hi, On 03.03.2010 11:44, Jacques Beaurain wrote: 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. As Jon already stated: the library seems not to be part of Mono. Where did you find it? Anyway, if the library is LGPL and you need to strongname it then you'll have to publish the public key. If you don't publish the key, the same strongname cannot be rebuilt and the library cannot be replaced. This basically means that you'd violate the LGPL which enforces that the library can be replaced at any time and by anyone. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Using Mono Assemblies under terms of LGPL
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.beaur...@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 jonpr...@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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Using Mono Assemblies under terms of LGPL
Hi, Thanks for all the replies. Signing the assembly and making the private/public key available was one option we were considering, but I think the final and easiest solution is writing our own assembly with native interop to libintl. Interestingly the gettext documentation does not state the license for the GNU.Gettext.dll assembly (http://www.gnu.org/software/gettext/manual/gettext.html#Licenses) and Rafael pointed out that the actual source code was marked GPL. I am questioning whether this was intentional since that assembly pretty much performs the same function as libintl (which is why I assumed it will also be LGPL). Cheers, Jacques ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Using Mono Assemblies under terms of LGPL
On Wed, 2010-03-03 at 10:16 -0500, Jacques Beaurain wrote: I think the final and easiest solution is writing our own assembly with native interop to libintl. We already have such a thing: Mono.Unix.Catalog, in Mono.Posix.dll, which is MIT/X11 licensed (no LGPL worries) and is already strong-named (and thus can be installed into the GAC): http://go-mono.com/docs/index.aspx?link=T:Mono.Unix.Catalog You'll still need to place INTL.DLL into %PATH% (or some other location so that LoadLibrary() will find it); Catalog just wraps INTL.DLL. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Using Mono Assemblies under terms of LGPL
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? 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. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
