Re: The Great Licensing Discussion

[Chris Travers <..hidden..>]

On Tue, Dec 20, 2011 at 4:28 PM, John Locke <..hidden..> wrote:
> Personally I prefer GPLv2 over GPLv3. I'm somewhat agnostic about GPL vs
> BSD -- I do like GPL v2 a lot, and like its mechanism for protecting end
> customers -- but I also work on some BSD-licensed projects and have no
> qualms about a license switch.

Ok.  I am actually coming up with an idea of advocating a license
switch only on a few parts of the code at this point.  The basic
problem is we can't reasonably replace the translation files although
we could probably get in touch with all major contributors.  There is
no guarantee we'd hear back from all of them, or that this would even
work with the translations that people may currently be using.

So under all cases, the work as a whole will have to stay under the
GPL (that makes it easy for end users).

However, there are a few core areas I think a license change might be helpful:

1)  The database query mappers (eventual replacements for DBObject.pm)
2)  Perl data type <-> PostgreSQL mapper classes (less of an issue
than the query mapper functions, but may get more traction if used in
other Pg-related projects).

The reason for selecting these two is that these three together form a
useful framework for other applications, and pushing them out into a
broader license may get wider use and contribution to these areas.
The rest is pretty specific to the application and I don't really see
how we'd get much benefit or not from changing licenses to that.  Also
the database query mappers being made BSD-licensed would mean that
sample code could be meaningfully made BSD-licensed too.

One thing to keep in mind is it would be easier and result in fewer
hard feelings if we only look at new code (with at most a couple well
defined contributors) than older code with many contributors.  I don't
see changing the license there as practical.
>
> I would agree with your assessment, Chris, about derivative works -- if
> you're extending a class, then yes, that would be derivative and need to
> carry the GPL, but just talking to an API doesn't count in my book. And
> there's lots of cases of web services sample code being released under
> entirely different licenses than the code behind the interfaces they
> talk to -- both commercial and proprietary. So I think it's entirely
> appropriate to create code samples and release them under the BSD license.

Now, just to clarify what this means at present.  If the query mappers
are GPL'd and are inherited (not sure the replacement will be
inherited, but that's another issue), then if someone comes along and
makes a proprietary add-on to LedgerSMB 1.3, the only parts they have
to license under a compatible license are the Perl API <-> query
mapper bits, which is a surprisingly small amount of code in most
cases.  The workflow scripts, templates etc. end up using our API
(though unclear about ui-header.html-- might not be able to use that
one).  So in this case the GPL doesn't protect us from proprietary
addons.  Rather it protects us from someone forking the codebase and
selling it for license fee.

To be honest, in that area, it doesn't really bother me.  Software
licenses really aren't likely to work well with regard to LedgerSMB
add-ons for very long, and the cost of maintaining such changes as we
move forwards is likely to be prohibitive.  For things like payroll,
yes, software license fees might work but I doubt they would work well
enough in comparison to service contracts (keeping tables up to date
and the like) to make it worth it.  About the worst a proprietary
add-on could do to us would be to show us where there is a market for
improvement and help us get there.
>
> I do think it would be confusing for end users to have to deal with
> multiple licenses within the code base, though. I think that having
> parts of LSMB under GPL with other parts under BSD and the collection
> under GPL -- that's way too confusing to have to explain to anybody.

Explaining it to the end user is simple:  The work as a whole is
licensed under the GPL.  Feel free to give away source copies in
compliance with that license.  Don't worry about the rest.

Making sure contributors understand....  Well, we'd just want to
loudly announce that parts were licensed under a more permissive
license.

>
> This makes me think that the only reasonable way forward for the project
> as a whole is under the GPL. It's fine to release client API libraries
> and samples under BSD, but I don't see how you change the license of
> anything in the core project without a huge amount of turmoil.

Nothing that is in the core project today (in branches/1.3) can be
changed without more headache than is worth it.  I don't have every
contributor's contact info for every patch and even if I did, there is
no guarantee we'd get a reply from all of them.  A few of the files I
have done for 1.4 could be, but that wouldn't affect the "work as a
whole" bit.

One reason to do the sql function mapper stuff in a BSD license though
would be to ensure that if it is possible on PHP and Python under that
license, it's possible on Perl as well.  That may avoid hard feelings
later.
>
>
> I would think that if that's a direction you would want to go, I would
> suggest setting up a foundation to control the copyright of the code,
> and have all contributors sign a contributors licensing agreement that
> assigns the right to offer additional/changed licensing terms to the
> foundation. This way it would at least be possible, when all the legacy
> code is no longer in the project. But it strikes me that one reason to
> go BSD is to avoid the need for doing a foundation ;-)

Yeah, well, right now our whole copyright claim states it's
copyrighted by the core committee, but I would assume that includes
former members too, some of which are next to impossible to get ahold
of these days......

Best wishes,
Chris Travers