On Tue, Dec 20, 2011 at 4:28 PM, John Locke <[email protected]> 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 ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
