You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Eike Rathke <oo...@erack.de> on 2011/07/19 20:41:46 UTC
Hunspell and MPL license
Hi,
I was digging a bit into 3rd party licenses for the Hunspell issue and
came across Category B: Reciprocal Licenses in
http://apache.org/legal/3party.html and noted that Hunspell is
tri-licensed also under MPL 1.1 that would be permissive as long as the
code is distributed only in binary form and the NOTICE file labels its
reciprocity, if I understood correctly.
Currently OOo needs Hunspell in source code form only because very few
patches are applied to be able to build it on Solaris, Windows and
MingW, and one patch against a stack smasher. Am I right in assuming
that if Hunspell adapted the upstream version such that these patches
were superfluous, then AOOo would be able to build against a system
Hunspell or on systems where Hunspell is not available or for binary
distributions a build could include a binary of the library if the
proper NOTICE entry is provided? To me this sounds like a solution to
the problem.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: ICU
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Jul 20, 2011 at 10:45 AM, Michael Meeks
<mi...@novell.com> wrote:
> On Wed, 2011-07-20 at 14:18 +0200, Michael Stahl wrote:
>> that is an interesting point: we currently ship binaries of C++ runtime
>> libraries in the installation sets.
>
> One thing that escapes a lot of people's notice is that most C++ app
> out there on Linux links vs. crt1.o crti.o crtbegin.o crtend.o and
> crtn.o - which are injected by the compiler to handle bootstrapping eg.
> C++ constructors & destructors Those are licensed under the GPL + GCC
> runtime library exception[1] AFAIR. I guess others around Apache discussed
> similar things before[2].
None of these (or the MSVC runtime) are likely to pose problems. They
don't prevent us from distributing the code that we develop under the
license of our choice; nor do they prevent anybody else from linking
in the runtime of their choice. If anybody here feels that additional
clarity is required on this point, simply open an issue:
https://issues.apache.org/jira/browse/LEGAL
> ATB,
>
> Michael.
>
> [1] - http://www.gnu.org/licenses/gcc-exception.html
> [2] - http://osdir.com/ml/java.harmony.devel/2005-12/msg00063.html
- Sam Ruby
Re: ICU
Posted by Michael Meeks <mi...@novell.com>.
On Wed, 2011-07-20 at 14:18 +0200, Michael Stahl wrote:
> that is an interesting point: we currently ship binaries of C++ runtime
> libraries in the installation sets.
One thing that escapes a lot of people's notice is that most C++ app
out there on Linux links vs. crt1.o crti.o crtbegin.o crtend.o and
crtn.o - which are injected by the compiler to handle bootstrapping eg.
C++ constructors & destructors Those are licensed under the GPL + GCC
runtime library exception[1] AFAIR. I guess others around Apache discussed
similar things before[2].
ATB,
Michael.
[1] - http://www.gnu.org/licenses/gcc-exception.html
[2] - http://osdir.com/ml/java.harmony.devel/2005-12/msg00063.html
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
Re: Unsubscribe (was Re: ICU)
Posted by Rob Weir <ap...@robweir.com>.
Hi Richard,
Please don't send your passwords to the list. This is a public
mailing list and that won't do anything to help you avoid unwanted
emails.
I've checked our subscriber list and I do not see
"whitehousetv@yahoo.com" subscribed to this list at all. I also
searched for any address that might look like yours, but I don't
anything that jumps out at me.
Could you forward this email, as you receive it, including the headers
(the cryptic stuff at the top of the email), to the list. Or, if you
are able, look very carefully at the email and determine what address
you are receiving it at. I don't think you are receiving it at
"whitehousetv@yahoo.com" directly, since that address is not
subscribed to the list.
-Rob
On Wed, Jul 20, 2011 at 11:58 AM, TJ Frazier <tj...@cfl.rr.com> wrote:
> On 7/20/2011 09:42, Richard E. Breed IV wrote:
>>
>> Hey folks...a friend used my laptop, and I am getting tons of emails I
>> do not understand from a really smart& interesting group of
>> folks...but, I need to unsubscribe and there's no such button at the
>> bottom, can you help?
>>
>> THanks..chard
>>
>> Richard Edwards Breed IV
>> Richard Edwards Breed IV
>>
>
> Send an email to:
> ooo-dev-unsubscribe@incubator.apache.org
>
> Be sure to use the same identity your friend used.
> You should get a return message for confirmation.
> --
> /tj/
>
>
pop-quiz: What is the difference between Work, and Play?
Posted by "Richard E. Breed IV" <wh...@yahoo.com>.
The Spelling!
It is obvious you folks love your jobs...and that means you have won the game of life. Congrats!
chard
THanks TJ
Posted by "Richard E. Breed IV" <wh...@yahoo.com>.
The name he gave....? I gave them the possibles, and thanks! Keep up your good works - as the earth and the evolution of civilization is also: Open Source!
Respectfully & gratefully yours, I am
Chard
Richard Edwards Breed IV
--- On Wed, 7/20/11, TJ Frazier <tj...@cfl.rr.com> wrote:
From: TJ Frazier <tj...@cfl.rr.com>
Subject: Unsubscribe (was Re: ICU)
To: ooo-dev@incubator.apache.org
Cc: whitehousetv@yahoo.com
Date: Wednesday, July 20, 2011, 11:58 AM
On 7/20/2011 09:42, Richard E. Breed IV wrote:
>
> Hey folks...a friend used my laptop, and I am getting tons of emails I
> do not understand from a really smart& interesting group of
> folks...but, I need to unsubscribe and there's no such button at the
> bottom, can you help?
>
> THanks..chard
>
> Richard Edwards Breed IV
> Richard Edwards Breed IV
>
Send an email to:
ooo-dev-unsubscribe@incubator.apache.org
Be sure to use the same identity your friend used.
You should get a return message for confirmation.
--
/tj/
Unsubscribe (was Re: ICU)
Posted by TJ Frazier <tj...@cfl.rr.com>.
On 7/20/2011 09:42, Richard E. Breed IV wrote:
>
> Hey folks...a friend used my laptop, and I am getting tons of emails I
> do not understand from a really smart& interesting group of
> folks...but, I need to unsubscribe and there's no such button at the
> bottom, can you help?
>
> THanks..chard
>
> Richard Edwards Breed IV
> Richard Edwards Breed IV
>
Send an email to:
ooo-dev-unsubscribe@incubator.apache.org
Be sure to use the same identity your friend used.
You should get a return message for confirmation.
--
/tj/
Re: ICU
Posted by "Richard E. Breed IV" <wh...@yahoo.com>.
Hey folks...a friend used my laptop, and I am getting tons of emails I
do not understand from a really smart & interesting group of
folks...but, I need to unsubscribe and there's no such button at the
bottom, can you help?
THanks..chard
Richard Edwards Breed IV
Richard Edwards Breed IV
--- On Wed, 7/20/11, BRM <bm...@yahoo.com> wrote:
From: BRM <bm...@yahoo.com>
Subject: Re: ICU
To: ooo-dev@incubator.apache.org
Date: Wednesday, July 20, 2011, 9:31 AM
----- Original Message ----
> From: Michael Stahl <ms...@openoffice.org>
> To: ooo-dev@incubator.apache.org
> Sent: Wed, July 20, 2011 8:18:10 AM
> Subject: Re: ICU
>
> On 20.07.2011 13:41, Eike Rathke wrote:
> > The most problematic is the RPATH for URE patch, but I have no idea
> > anyway how to proceed with libstdc++.so.6 and libgcc_s.so.1 that so far
> > were distributed with the URE and are LGPL. If we don't, then the patch
> > would be moot.
>
> that is an interesting point: we currently ship binaries of C++ runtime
>libraries in the installation sets.
> i know that we do this for Linux and Windows, don't know about other
>platforms; presumably relicensing GCC or MSVC runtime under Apache license is
>not an option.
>
> i guess we can probably drop the GCC libraries nowadays, because libstdc++
>doesn't change its ABI as much as it used to, so everybody should have a good
>enough one on their system.
>
> i wonder what would happen if we drop MSVC runtime?
>
Per MSVC run-time, it is typically good practice to have the installer package
the MSVC Run-time redistributable and install it if necessary.
The redistributable is provided in two manners: (i) a full installer, and (ii)
MSI Merge Modules that you select while building an MSI installer that provides
them - e.g. Visual Studios Installer, InstallShield, etc.
The difference being that the full installer will install to the system, while
(I believe) the MSI Merge Modules put the DLLs into the application installation
only.
These are primarily provided to ensure the application runs one systems where
the user/Microsoft has not already installed the redistributables system-wide
(e.g. VS2010 redist on WinXP SP3).
Using the full installer would present the user with Microsoft's license for
acceptance; where the Merge Modules do not. For that reason the full installer
would likely be preferable from a license pov.
While it is not licensed under ASL, as that is the generally recommended
practice for Windows Installers would that still be possible via Apache
guidelines?
$0.02
Ben
Re: ICU
Posted by BRM <bm...@yahoo.com>.
----- Original Message ----
> From: Michael Stahl <ms...@openoffice.org>
> To: ooo-dev@incubator.apache.org
> Sent: Wed, July 20, 2011 8:18:10 AM
> Subject: Re: ICU
>
> On 20.07.2011 13:41, Eike Rathke wrote:
> > The most problematic is the RPATH for URE patch, but I have no idea
> > anyway how to proceed with libstdc++.so.6 and libgcc_s.so.1 that so far
> > were distributed with the URE and are LGPL. If we don't, then the patch
> > would be moot.
>
> that is an interesting point: we currently ship binaries of C++ runtime
>libraries in the installation sets.
> i know that we do this for Linux and Windows, don't know about other
>platforms; presumably relicensing GCC or MSVC runtime under Apache license is
>not an option.
>
> i guess we can probably drop the GCC libraries nowadays, because libstdc++
>doesn't change its ABI as much as it used to, so everybody should have a good
>enough one on their system.
>
> i wonder what would happen if we drop MSVC runtime?
>
Per MSVC run-time, it is typically good practice to have the installer package
the MSVC Run-time redistributable and install it if necessary.
The redistributable is provided in two manners: (i) a full installer, and (ii)
MSI Merge Modules that you select while building an MSI installer that provides
them - e.g. Visual Studios Installer, InstallShield, etc.
The difference being that the full installer will install to the system, while
(I believe) the MSI Merge Modules put the DLLs into the application installation
only.
These are primarily provided to ensure the application runs one systems where
the user/Microsoft has not already installed the redistributables system-wide
(e.g. VS2010 redist on WinXP SP3).
Using the full installer would present the user with Microsoft's license for
acceptance; where the Merge Modules do not. For that reason the full installer
would likely be preferable from a license pov.
While it is not licensed under ASL, as that is the generally recommended
practice for Windows Installers would that still be possible via Apache
guidelines?
$0.02
Ben
Re: ICU
Posted by Stephan Bergmann <st...@googlemail.com>.
On Jul 20, 2011, at 8:13 PM, Pedro F. Giffuni wrote:
> This does remind me that it's really desirable to be
> able to build OO with clang: not exactly due to the
> licensing but for cleanliness and portability.
I tried some time earlier this year, building OOo's trunk with a trunk clang on Mac OS X. Failed in various places (some were errors in the OOo code not yet flagged by any other compiler, some were issues also flagged by most recent GCC but to which OOo had not yet been adapted, some were clang errors like <http://llvm.org/bugs/show_bug.cgi?id=9421>), somehow lost interest and gave up back then. But probably worth re-evaluating.
-Stephan
Re: ICU
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
FWIW,
System libraries are covered by exceptions to the GPL
and even the FSF have written in a FAQ that those don't
taint anything in userland.
This does remind me that it's really desirable to be
able to build OO with clang: not exactly due to the
licensing but for cleanliness and portability.
--- On Wed, 7/20/11, Eike Rathke wrote:
...
>
> I'd suggest to drop the Linux general binary distributions
> anyway, there's a hell of base line involved to support
> various mixes of library versions. Providing packages for
> a few specific distributions would probably be easier,
> with those there would be no need to bundle runtime
> prerequisites.
>
On FreeBSD we take care of our own binaries: we do frequent
package builds in a cluster, and I am sure linux
distributions do the same.
cheers,
Pedro.
Re: ICU
Posted by Eike Rathke <oo...@erack.de>.
Hi Michael,
On Wednesday, 2011-07-20 14:18:10 +0200, Michael Stahl wrote:
> On 20.07.2011 13:41, Eike Rathke wrote:
> >libstdc++.so.6 and libgcc_s.so.1
>
> that is an interesting point: we currently ship binaries of C++
> runtime libraries in the installation sets.
> i know that we do this for Linux and Windows, don't know about other
> platforms; presumably relicensing GCC or MSVC runtime under Apache
> license is not an option.
Certainly not.
> i guess we can probably drop the GCC libraries nowadays, because
> libstdc++ doesn't change its ABI as much as it used to, so everybody
> should have a good enough one on their system.
I'd suggest to drop the Linux general binary distributions anyway,
there's a hell of base line involved to support various mixes of library
versions. Providing packages for a few specific distributions would
probably be easier, with those there would be no need to bundle runtime
prerequisites.
> i wonder what would happen if we drop MSVC runtime?
Won't work unless you point users to "if you don't have this and that
library in this or that version install it from ...", too great a burden
for typical Windows users.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: ICU
Posted by Michael Stahl <ms...@openoffice.org>.
On 20.07.2011 13:41, Eike Rathke wrote:
> The most problematic is the RPATH for URE patch, but I have no idea
> anyway how to proceed with libstdc++.so.6 and libgcc_s.so.1 that so far
> were distributed with the URE and are LGPL. If we don't, then the patch
> would be moot.
that is an interesting point: we currently ship binaries of C++ runtime
libraries in the installation sets.
i know that we do this for Linux and Windows, don't know about other
platforms; presumably relicensing GCC or MSVC runtime under Apache
license is not an option.
i guess we can probably drop the GCC libraries nowadays, because
libstdc++ doesn't change its ABI as much as it used to, so everybody
should have a good enough one on their system.
i wonder what would happen if we drop MSVC runtime?
Re: ICU
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
Hi Eike;
FWIW, building ICU 4.8 on FreeBSD required a patch for the
memory issue I reported in an older thread. This kind of
fixes are better handled by distributions .. and certain
OO forks already do this.
cheers,
Pedro.
--- On Wed, 7/20/11, Eike Rathke <oo...@erack.de> wrote:
...
> Hi Javier,
>
> On Wednesday, 2011-07-20 15:27:03 +0700, Javier Sola
> wrote:
>
> > If I remember correctly and unless it has changed,
> some patches were
> > applied to ICU during the build. This required a
> specific version of
> > ICU to which the patches were applied,
>
> Correct, though with the update to ICU 4.* there are only a
> very few
> patches left, see
> http://wiki.services.openoffice.org/wiki/ICU/bugs_and_patches
>
> The most problematic is the RPATH for URE patch, but I have
> no idea
> anyway how to proceed with libstdc++.so.6 and libgcc_s.so.1
> that so far
> were distributed with the URE and are LGPL. If we don't,
> then the patch
> would be moot.
>
> > and this is why the ICU
> > source was kept inside the OOo source (I believe).
>
> Yes and no, initially packages were hosted by OOo whenever
> possible,
> interfaces (API and ABI) may change between versions,
> especially
> upgrading ICU from 2.6 to 3.6 required code changes in OOo
> and still
> gave us lot of headaches later (read regressions) as quite
> some behavior
> changed. It's easier to stay with a defined version.
>
> However, in case of ICU I currently don't see a real
> problem to go with
> system ICU when available, that's what distributions do
> since ages.
>
> In fact using a more recent ICU usually has more benefits
> than
> disadvantages.
>
> Eike
>
> --
> PGP/OpenPGP/GnuPG encrypted mail preferred in all private
> communication.
> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96
> 2F1A D073 293C 05FD
>
Re: ICU
Posted by Eike Rathke <oo...@erack.de>.
Hi Javier,
On Wednesday, 2011-07-20 15:27:03 +0700, Javier Sola wrote:
> If I remember correctly and unless it has changed, some patches were
> applied to ICU during the build. This required a specific version of
> ICU to which the patches were applied,
Correct, though with the update to ICU 4.* there are only a very few
patches left, see
http://wiki.services.openoffice.org/wiki/ICU/bugs_and_patches
The most problematic is the RPATH for URE patch, but I have no idea
anyway how to proceed with libstdc++.so.6 and libgcc_s.so.1 that so far
were distributed with the URE and are LGPL. If we don't, then the patch
would be moot.
> and this is why the ICU
> source was kept inside the OOo source (I believe).
Yes and no, initially packages were hosted by OOo whenever possible,
interfaces (API and ABI) may change between versions, especially
upgrading ICU from 2.6 to 3.6 required code changes in OOo and still
gave us lot of headaches later (read regressions) as quite some behavior
changed. It's easier to stay with a defined version.
However, in case of ICU I currently don't see a real problem to go with
system ICU when available, that's what distributions do since ages.
In fact using a more recent ICU usually has more benefits than
disadvantages.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
ICU (was Hunspell and MPL license)
Posted by Javier Sola <li...@khmeros.info>.
If I remember correctly and unless it has changed, some patches were
applied to ICU during the build. This required a specific version of ICU
to which the patches were applied, and this is why the ICU source was
kept inside the OOo source (I believe).
Javier
Pedro Giffuni wrote:
>
> Hello Eike;
>
> I think you are right. I should mention that on FreeBSD, LibreO uses
> the preinstalled hunspell package so using the upstream version is
> possible already. Furthermore, we should use the same approach for ICU
> and other dependencies: if the system already has such packages, why
> not use them?
> I guess there may be problems for specific platforms like Windows, so
> there's where the binary and NOTICE files kich in.
>
> Cheers,
>
> Pedro.
>
>
> On Tue, 19 Jul 2011 20:41:46 +0200, Eike Rathke <oo...@erack.de> wrote:
>> Hi,
>>
>> I was digging a bit into 3rd party licenses for the Hunspell issue and
>> came across Category B: Reciprocal Licenses in
>> http://apache.org/legal/3party.html and noted that Hunspell is
>> tri-licensed also under MPL 1.1 that would be permissive as long as the
>> code is distributed only in binary form and the NOTICE file labels its
>> reciprocity, if I understood correctly.
>>
>> Currently OOo needs Hunspell in source code form only because very few
>> patches are applied to be able to build it on Solaris, Windows and
>> MingW, and one patch against a stack smasher. Am I right in assuming
>> that if Hunspell adapted the upstream version such that these patches
>> were superfluous, then AOOo would be able to build against a system
>> Hunspell or on systems where Hunspell is not available or for binary
>> distributions a build could include a binary of the library if the
>> proper NOTICE entry is provided? To me this sounds like a solution to
>> the problem.
>>
>> Eike
>
>
Re: Hunspell and MPL license
Posted by Pedro Giffuni <gi...@tutopia.com>.
Hello Eike;
I think you are right. I should mention that on FreeBSD, LibreO uses
the preinstalled hunspell package so using the upstream version is
possible already. Furthermore, we should use the same approach for ICU
and other dependencies: if the system already has such packages, why not
use them?
I guess there may be problems for specific platforms like Windows, so
there's where the binary and NOTICE files kich in.
Cheers,
Pedro.
On Tue, 19 Jul 2011 20:41:46 +0200, Eike Rathke <oo...@erack.de> wrote:
> Hi,
>
> I was digging a bit into 3rd party licenses for the Hunspell issue
> and
> came across Category B: Reciprocal Licenses in
> http://apache.org/legal/3party.html and noted that Hunspell is
> tri-licensed also under MPL 1.1 that would be permissive as long as
> the
> code is distributed only in binary form and the NOTICE file labels
> its
> reciprocity, if I understood correctly.
>
> Currently OOo needs Hunspell in source code form only because very
> few
> patches are applied to be able to build it on Solaris, Windows and
> MingW, and one patch against a stack smasher. Am I right in assuming
> that if Hunspell adapted the upstream version such that these patches
> were superfluous, then AOOo would be able to build against a system
> Hunspell or on systems where Hunspell is not available or for binary
> distributions a build could include a binary of the library if the
> proper NOTICE entry is provided? To me this sounds like a solution to
> the problem.
>
> Eike
Re: Hunspell and MPL license
Posted by "Richard E. Breed IV" <wh...@yahoo.com>.
Hey folks...a friend used my laptop, and I am getting tons of emails I do not understand from a really smart & interesting group of folks...but, I need to unsubscribe and there's no such button at the bottom, can you help?
THanks..chard
Richard Edwards Breed IV
--- On Tue, 7/19/11, Ross Gardler <rg...@opendirective.com> wrote:
From: Ross Gardler <rg...@opendirective.com>
Subject: Re: Hunspell and MPL license
To: ooo-dev@incubator.apache.org
Date: Tuesday, July 19, 2011, 6:29 PM
On 19 July 2011 19:41, Eike Rathke <oo...@erack.de> wrote:
> I was digging a bit into 3rd party licenses for the Hunspell issue and
> came across Category B: Reciprocal Licenses in
> http://apache.org/legal/3party.html and noted that Hunspell is
> tri-licensed also under MPL 1.1 that would be permissive as long as the
> code is distributed only in binary form and the NOTICE file labels its
> reciprocity, if I understood correctly.
Good find. You do understand correctly. Although please note that the
page you link to is an earlier draft kept for reference only. The
official document is linked from the header of that page and can be
found at http://apache.org/legal/resolved.html (specifically for MPL
you need http://apache.org/legal/resolved.html#category-b )
Ross
>
> Currently OOo needs Hunspell in source code form only because very few
> patches are applied to be able to build it on Solaris, Windows and
> MingW, and one patch against a stack smasher. Am I right in assuming
> that if Hunspell adapted the upstream version such that these patches
> were superfluous, then AOOo would be able to build against a system
> Hunspell or on systems where Hunspell is not available or for binary
> distributions a build could include a binary of the library if the
> proper NOTICE entry is provided? To me this sounds like a solution to
> the problem.
>
> Eike
>
> --
> PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Hunspell and MPL license
Posted by Ross Gardler <rg...@opendirective.com>.
On 19 July 2011 19:41, Eike Rathke <oo...@erack.de> wrote:
> I was digging a bit into 3rd party licenses for the Hunspell issue and
> came across Category B: Reciprocal Licenses in
> http://apache.org/legal/3party.html and noted that Hunspell is
> tri-licensed also under MPL 1.1 that would be permissive as long as the
> code is distributed only in binary form and the NOTICE file labels its
> reciprocity, if I understood correctly.
Good find. You do understand correctly. Although please note that the
page you link to is an earlier draft kept for reference only. The
official document is linked from the header of that page and can be
found at http://apache.org/legal/resolved.html (specifically for MPL
you need http://apache.org/legal/resolved.html#category-b )
Ross
>
> Currently OOo needs Hunspell in source code form only because very few
> patches are applied to be able to build it on Solaris, Windows and
> MingW, and one patch against a stack smasher. Am I right in assuming
> that if Hunspell adapted the upstream version such that these patches
> were superfluous, then AOOo would be able to build against a system
> Hunspell or on systems where Hunspell is not available or for binary
> distributions a build could include a binary of the library if the
> proper NOTICE entry is provided? To me this sounds like a solution to
> the problem.
>
> Eike
>
> --
> PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com