Re: Proposal for LedgerSMB 1.5: Refactor and move some utility functionality to CPAN

[Chris Bennett <..hidden..>]

On Thu, May 23, 2013 at 11:20:22PM -0700, Chris Travers wrote:
> Hi everyone;
> 
> After 1.4 is released I would like to start moving the following
> functionality to CPAN:
> 
> 1.  Stored procedure call interface (call_procedure)
> 2.  Stored procedure-> object property mapping interface (exec_method)
> 3.  Moose wrappers around these, and
> 4.  User permissions discovery
> 5.  Helper modules (LedgerSMB::PGDate, LedgerSMB::PGNumber)
> 
> There are a number of reasons why I think that this would be a good idea:
> 
> 1.  These are all potentially generally applicable pieces of code.  They
> are potentially reusable well outside LedgerSMB, and they provide potential
> integration points for other applications.
> 
> 2.  They may be of interest to other developers.  To the extent that they
> are, they represent a potential source of outreach for LedgerSMB
> 

I like this idea. Other users outside of LedgerSMB may find flaws or
suggest new features that might be useful. I have occasionally found
some things in other CPAN modules and had a good response from the
author.

> 3.  Over the years, a good deal of cruft has built up in the interfaces.
>  It would be good to redesign, generalize, and modularize these so that we
> can have better contracts between elements of the program.
> 
> My current plan is to create what is essentially a toolkit for
> incorporating stored procedures into objects in Perl and then have our
> current interfaces be basic wrappers around these.  The wrappers will still
> be necessary because many decisions we have made regarding tracking things
> like application state between modules can't be assumed in other
> environments.
> 
> A few questions I have for folks here:
> 
> 1.  Licensing.  In general I have been trying to put new language bindings
> under permissive (BSD-style) licenses for the simple reason that it gives
> people more peace of mind if they are integrating proprietary applications
> with LedgerSMB.  This also has the advantage of following what the
> PostgreSQL community is generally most comfortable with.  Are there any
> concerns about this?  Our actual object framework would still be GPL v2 so
> no changes of licensing in our project.  It would just mean that there
> would be integration points available under more permissive licenses.  The
> other option is "under the same terms of Perl itself" which protects us
> better against proprietary forks, but I am not at all sure that is much of
> a fear.

I always prefer BSD or even more permissive licensing.
If someone can then sell a proprietary version, they might be willing to
submit a module with the same kind of licensing. No guarantee of that,
of course. But why not?

There is something else that does happen. Companies close. People
retire. A contract for their software may end. Sometimes people die.
This actually happened to me during one project.
All of their proprietary software may suddenly become available with a
BSD license.

Chris Bennett