- App Store
To free or not too free, that is the question
To be more specific ... the question we would like help answering is would xTuple be better off changing the CPAL license on its core PostBooks project to the GPL license, or an extremely permissive license like BSD or MIT?
Anyone who works with open source software knows that one of the most-discussed aspects of an open source project is its license. The license of a project you incorporate into your own can impact the licensing of your own software. This is because licensing can dictate not only the legal terms under which the code you are incorporating must be distributed, but the legal terms under which the entire body of code into which it was merged must be distributed.
There is something of a religious debate about what the "free" in free and open source software (FOSS) means. Let's dive in...
To many people, free means that the body of code underlying open source software must be distributed free of charge - and that related code "should" also be free. Richard Stallman is the most prominent advocate of this point of view. He created the GPL license, enforcing the notion of copyleft protection. Essentially, a copyleft license mandates any derivative works that use GPL code must themselves be GPL compatible. Apparently a lot of people agree with Mr. Stallman, because GPL is the most widely-used license in open source software.
However, just because software is free from a monetary standpoint doesn't mean it is free from all points of view. Generally speaking you are not free to do whatever you want with GPL licensed code because you are tightly restricted in what kinds of projects you can incorporate it into. Most notably, you can not use GPL licensed code inside any projects that are proprietary or have commercially licensed components or extensions. This can sometimes have a dampening effect on corporate contributions to open source projects.
What xTuple uses today for PostBooks is the Common Public Attribution License (CPAL). This is a "mild copyleft" license recognized by the Open Source Initiative that is similar to the GPL, with the additional stipulation that you must provide attribution to the original licensor, in our case the words "Powered By xTuple" included in any splash screen that precedes the launch of a graphical interface. Our logic for requiring this was because we felt that in all likelihood people that use our code are likely to use the entire PostBooks framework as their baseline, and we didn't think it was unreasonable to ask for a little name recognition in exchange for the substantial functionality we make available at no cost. Though it is officially sanctioned, this kind of license is sometimes derogatively referred to as "badgeware" in some open source circles.
Now that we've explained what all the options are, why are we asking you about this? Because with the ever increasing maturity of our new Mobile Web client, we are becoming more interested in ways that we can increase participation in and grow our open source community. We recognize that copyleft licenses can often have a chilling effect on the interest of would be developers (they do on us!). On the other hand, GPL is the most popular open source license there is, and many feel a project isn't "real" free and open source unless it's guaranteed to be free in the monetary sense. Finally, we suspect CPAL may discourage participation because A) it is relatively unknown and B) neither people who prefer copyleft or permissive licenses particularly like the idea of being forced to provide attribution in their own works.
So we'd like to hear from you. Would you prefer the xTuple PostBooks project move toward the copyleft GPL, or a more permissive license? If so, why? Or is CPAL just fine the way it is? Or does anyone even care about the open source license debate anymore?
Wed, 03/19/2014 - 12:25#1
John,Have you opened a door!
Have you opened a door! "Religious" how about "religious zealot's".
In the past I always felt that sharing my code was a good thing and all I asked was I received credit - leave my name in the source code. That is until I met Richard Stallman. In the thirty second discussion he and I had he all but called me a name for asking for my name remain in the source code. It was many years ago and at the time many were asking for changes to the GPL license. My guess - he saw me as another trying to change the license. I say so because my reading of the GPL license does not prevent my name being in the code. And today the "Free Software Foundation" has endorsed several of the newer licenses as "compatible" with GPL.
I bring that up because I have since moved away from GPL. To be honest I moved away due to one customer. The customers argument was simple - "I paid for this work and I'm not willing to share it". In my mind that seemed reasonable. Of course I could have just lied or not approached the subject. But I have always been up front about my code with all my customers (I have worked for at least 300 different customers in my 30 years).
Since I have always felt it fair and just that my name be kept in the code I lean toward BSD (but I think it a little over the top. Almost like forced advertising) and of course CPAL. Apache licenses demands so many rules be followed that I thought it was over the top too. MIT licenses are interesting in that it protects author from being exploited in advertising.
In the end I have removed all license statements from my code. I realized that the code I write is so specific (IOW only usable by one customer) that is almost not usable by others. That said, I did find my code in another coders "FoxPo" program. I was disappointed because I did not see my name.
In your case I believe that it is fair and reasonable your name be acknowledged. I'm not sure where or how but it should be. This is just like when we were in school writing a paper where we had to site our sources.
Wed, 03/19/2014 - 15:34#2
When to GPL
John, thanks for bringing this up publicly. I've contributed to and founded various free software projects, covered by a variety of those licenses you mention.
There are a few trends that come to mind first:
a) github - distributed development and "social" coding, which is what Github calls it. As in any social context, there is a lot more momentum when you go with the flow.
b) packaging - Packages make it easy for people to try your software the first time, before they commit to things that make money for you (like training or attending your conference). Packages give you market share and take market share from your competitors: in a zero zum game, that is important. Packages also mean more businesses choosing xTuple as their first accounting solution and so it stays with them when they grow.
c) contributor agreements - this is an issue related to licensing, but not quite the same thing. They are not essential. Done badly, they can hurt (just look at the recent criticism of Ubuntu's proposed contributor agreement). Your strategy for licensing and contributor agreements need to engage people.
d) dual / concurrent licensing - as the project founder, it is quite possible you could simultaneously release the code under both CPAL terms and GPL terms and require all contributors to agree to both licenses. Somebody reusing your code under the GPL terms can mix it with other GPL products but everything they do is published as open source (so you can see it and benefit from it)
There are various other things that come to my mind as well:
- various companies are successful with GPL, look at Digium, the promoters of the Asterisk PBX
- a "badgeware" style license is not essential to promote your brand: packages in Debian, Ubuntu and Fedora may well give you a much bigger profile in the long run and they clearly identify your brand. We even created a pkg-xtuple group in Debian to link all your packages.
- bad licensing can backfire: look at the Firefox license. To comply with the license, Debian is not able to call it Firefox, and so it is renamed to Iceweasel. This is because Mozilla has a clause that insists that distributors can't include any patches and still use the Firefox name. There are essential patches Debian has to apply to make it fit cleanly within a Debian machine so it is renamed Iceweasel to comply with the license. This is not the same as the issue with CPAL, but it does demonstrate that licensing strategies that don't engage the community can work in ways you don't intend.
- look at Linux itself. Android is Linux. If Linux was CPAL, then Google would have to display the Linux penguin logo (Tux) on every Android phone. Has Linux missed out because they don't do CPAL? No, because everybody who cares about this kind of thing knows that Android is based on Linux anyway.
- this brings me to the last point: leadership. As long as xTuple is blazing a trail in this area, you are always one step ahead of those who would fork your product and distribute a version under a different name. Once again, this is where community gives you advantage too - the bigger your community and the more prominent your packages, the harder it is for people promoting a product under a different name to get a share of the market.
Wed, 03/19/2014 - 17:30#3
>d) dual / concurrent
>d) dual / concurrent licensing - as the project founder, it is quite possible you could simultaneously release the code under both CPAL terms and GPL terms and require all contributors to agree to both >licenses. Somebody reusing your code under the GPL terms can mix it with other GPL products but everything they do is published as open source (so you can see it and benefit from it)
I'm not sure I agree that both CPAL and GPL can be used for the same code even for contributors. The "Free Software Foundation" does not consider CPAL compatible (could be wrong here). So, explain how that would work? Recall the GPL requires that you provide all the source necessary to build the software. You are not in compliance by just providing a means in which to download. xTuple has to deliver the source because in the code they have to make a written offer to do so. GPL is not a the best for a commercial company that will publish to the public. And even worse for a dual setup such as xTuple.
As far as Linux and the GPL goes all the distro's today provide a means to download and install non-GPL software and that includes Debian. Yes it maybe true that xTuple may not be included in the standard "free" install of some distro - but it is also true that it could be available in the non-free downloads that all distros have available.
If you are concerned with forking then be even more concerned. The desktop version is written in C++ which requires that someone with at least a little programming background compile the source. The same is not true of the web client. It might be harder to install but much easier to steal. Stealing will not happen if the community is strong and feels xTuple is going in the right direction. But I suggest that could turn on a dime. Example openERP and Tryton, Joomla and Mambo. Most of the forks I can recall are with web code and the forks were almost always because of disagreements over direction. An open rebellion would hurt the partners directly and dilute the economic future of xTuple. No GPL is not the way IMO.
Wed, 03/19/2014 - 18:46#4
Sorry guy - I have not a clue
Sorry guy - I have not a clue what happened to the font in my reply. Everything was suppose to be the same - no bold or font changes at all.
Thu, 03/20/2014 - 08:09#7
I started with open source
I started with open source software in 2008 coming from using and promoting propriety software applications for 12 years. For me it was not an issue of "free" software but rather community involvement and support. I first started with Untangle (Firewall appliance) and then Magento. Both of these software projects are well funded and and have great leaders behind it.. For me it is important that an open source project has good support options, paid and free. I want to be able to promote a solution knowing that I don't have to know everything about it there is to know. So xTuple was a natural choice.
My recommendation is to use whatever licensing method that will maximize involvement at many levels
Thu, 03/20/2014 - 10:17#8
Thanks, everyone, for the
Thanks, everyone, for the comments so far. Let me wade in a bit, with some thoughts on what xTuple's interests here are.
First, I'll echo the theme that we're definitely looking to expand the community of developers/contributors/users. Even since moving to Github, as Daniel alludes to above, we've seen a greater level of engagement by what I'd call casual developers - not necessarily hard-core ERP users, but people interested in the code. We want to ramp that up, for sure.
Second, Daniel is quite right that we have the option to dual-license (we do today - PostBooks is available under a commercial license, and we have a number of customers who have opted for this, both on-site and in our cloud service). We can only do that, of course, if we hold copyright to 100% of the code, which of course brings us to ...
Copyright assignment. When you submit a patch today (typically via a bug report, but also via GitHub), you are agreeing to assign copyright (which can be loosely conflated with "ownership") of that patch to xTuple. This can sometimes be a controversial concept in open source - particularly in projects where there is a wide diversity of contributors, and no real central force in the community. I hope/believe - and our experience so far has borne this out - that in the case of xTuple, people are willing to do that, because we built the whole darn thing at the outset, and decided to open source it. So there would have to be some truly massive contributions from other parties to even threaten to tip the scales there.
It's all tied up in the larger questions of leadership that a couple of people have discussed. Our overarching goal, particularly with the new mobile web technology, is to truly make it a platform on which people can develop add-on solutions. We've certainly had a number of successful examples of that in the Desktop client - Dave Anderson's fixed asset suite is a good example - but by and large, we think it's probably been too hard for people. Hard to say how much of that is technology (Qt client/server), license questions, or just the fact that ERP is complex and messy.
But we're going to be making a concerted effort with the new mobile web platform to knock down as many of those barriers as we can. If you've been reading John's other blogs, and particularly if you've gotten your hands on the code yet, you'll know that it's much, much more modular than the Desktop client ever was (or likely could be). You can turn on, or off, as much or as little of the application as you want - yet it will all be there if the developers need access to it. So, for example, a medical office management system might just need the basic accounting modules and CRM, and develop their industry-specific add-ons themselves.
And regardless of how we decide to license the PostBooks core (and user contributions to it), it will be possible to draw clean lines of separation between open source code and modules that you develop for your own business needs. Of course, we hope that anyone interested in doing that will engage with us as a partner, and potentially license a commercial version of PostBooks. That's the best way to get both developer-to-developer support, and (if desired) level three support from xTuple for your end-users.
Happy to answer any questions anyone has about the above, but in the meantime, let's keep hearing from you on the license question!
Thu, 03/20/2014 - 10:41#9
The copyright assignment issue is a sensitive topic. Everybody has a different position on it.
If you give people a plugin or module API and they develop plugin code they don't need to assign copyright. This means anybody can publish their plugin on their own terms. Look at the success of Drupal: it has thousands of plugins. Ganglia also saw exponential growth after adding a plugin API in version 3.1 - most of that growth was Python plugins.
There has even been research in this area, have a look at for papers from Gaston Llanes about topics such as "Mixed Source", suggesting that having an open source core and allowing proprietary plugin development offers an interesting combination.
On the specific details though, some contributors will be prohibited from some types of assignment based on their workplace. E.g. if somebody works for a non-profit or a Government agency and they make some contribution to your code they may be prohibited from assigning copyright to a commercial entity. Some projects solve this problem by placing the open source code ownership under the umbrella of a non-profit.
There are also people with political/personal preferences, e.g. some people refuse to contribute to GPL projects and some people insist on copyleft (like GPL) and won't contribute to something like BSD. This is one problem you can't completely solve and shouldn't lose any sleep over - as long as you give people a good plugin/module API, they can often do their own thing in that space.
Thu, 03/20/2014 - 12:40#10
GPL and RMS
The GPL does not prevent you from charging for distributing software - the Free Software Foundation used to make money by selling tapes with GPL software on them. What it does prevent is preventing others from distributing said software so you can't achieve the monopoly price normally associated with copyrighted works.
Thu, 03/20/2014 - 21:10#11
On Free Software licensing
Soliciting opinions openly is a good way of getting feedback from the
community. And I feel it also sends a strong signal to the community
about your stance on collaboration. So thanks for that.
But it isn't true that you are not allowed to distribute software
licensed under the terms of the GNU GPL for a fee. Here is the FAQ
entry on this question directly from the Free Software Foundation:
And here is an article from the Free Software Foundation championing
the idea of making money off of your hard work on software licensed
under the terms of the GNU GPL:
I hope this is of help in the discussion.
Mon, 03/31/2014 - 17:24#12
Ah, yes. Technically you can
Ah, yes. Technically you can charge to distribute GPL software.
The problem is that any GPL distribution is required to include all the original code and the right to freely redistribute the original code and any new code built around it. So while technically you can charge to distribute GPL code, effectively you can not because it is so cheap and effortless to distribute software you are all but guaranteed to find somebody who will let you download said code at no cost. Why would anybody pay for that?
I believe that while this technical argument exists that you can charge to distribute GPL software, the real intent is to make sure people and businesses will not, and this is by and large the case in the real world.
Tue, 04/01/2014 - 00:49#13
There is one exception to all that: dual licensing. As the copyright owner, you can license an enhanced version of the software to customers for some additional charge.
As the copyright owner, you are only under the burden of GPL terms if you have used dependencies that are GPL. Even in that case, you may find the author of that dependency may strike a deal with you for dual licensing and you can then sell some enhanced version of your product without distributing the source code.
However, simply releasing your own code as a GPL project does not burden you, the author, with the GPL terms. You are simply imposing those terms on everybody else.
A carefully designed modularization strategy can also let you mix and match GPL code. For example, lets say that you had some process that does a risk analysis on the outstanding debtors each night. This code uses some GPL statistics library. As long as the code is a standalone binary and reads and writes directly from PostgreSQL, it doesn't put GPL obligations into other binaries, etc.
People are doing this modularization in many ways: sharing data over REST APIs, through message queues or through database tables. As long as you keep the third-party GPL elements at arms length you can still mix-and-match components to suit your business strategy.
Tue, 04/01/2014 - 09:51#14
Right. We get dual licensing
Right. We get dual licensing and the benefits of operating under that premise. That is why we use CPAL today on our open source project, with copyrighted extensions available for purchase. We are happy to talk to anyone about dual licensing who wants to build an extension on our framework that they can charge money to license.
What I think we're most interested in understanding is the perspective of the developer community on that in their decision making process. From our standpoint the CPAL license works just fine and solves all our problems... but does it work for you? Does the attribution clause create disincentive to adopting our platform? Is the copyleft nature of CPAL and GPL a disincentive? CPAL is not as well known as other licenses, does that spook would-be developers?
I'm not sure anyone on this thread except johnf., who likes CPAL, has clearly stated their preference. Mostly what I see is people weighing the pros and cons similar to my original post. What we'd like to know is if you think CPAL is fine, or if not what license you all think we should be using and why. If folks are generally ambivalent or indifferent to the license, we're likely to leave things the way they are.
Wed, 04/02/2014 - 02:52#15
impact on developers
I don't want to suggest exactly which license is best for you but the feeling I get from your comments on the forum is that you prefer a copyleft style of license that makes it hard for somebody else to redistribute the product in a binary-only format. I suspect GPL is more likely to help you in this way.
For my own most immediate use cases, copyleft (either CPAL or GPL) doesn't propose an immediate problem
If you went from CPAL to GPL, this wouldn't create any new problems for me either.
There are specific problems for me with CPAL although their effects are indirect:
* CPAL is not GPL compatible. There is a lot of GPL code out there but very little CPAL code. So using CPAL prevents me mixing-and-matching code on the fly if I ever need to do so. Another impact of this is that it stops people sharing code: it is perfectly OK for me to mix your code with GPL code for use on a specific project. The license terms simply prevent distribution/sharing of the code that I have been produced, it can only be used where it was developed.
* CPAL is not well known - this may undermine attempts to get community collaboration. As a developer, I want to be using products that are the outright leaders in their fields. Maximizing community involvement appears to be a compelling way to achieve and retain a leadership position.
* Packages: currently, xTuple has official packages in Debian and derivatives like Ubuntu. They will be in the Ubuntu LTS 14.04 release and hopefully Debian 8 early 2015. However, the Debian community has previously showed mixed feelings about the CPAL. Look at http://bugs.debian.org/442032 about OpenProj - in the end, the product was never packaged at all although there was no final decision on CPAL itself. While it is quite possible for any Debian Developer such as myself to create a package that meets the technical standards of Debian, it is the Debian FTP master team who have the final say on whether a package is included. If the FTP masters were to reach a consensus that is consistent with those who are more conservative about CPAL, then the packages could be removed from the archive. It is the risk around this area that is most troubling for me, as I wouldn't like to see the packaging efforts go to waste.
In 2008, the Fedora/Red Hat people confirmed that CPAL does meet the Fedora definition of free. That does not always guarantee that it is free for every Linux as everybody has a slightly different policy on licenses and badgeware is one of the more contentious issues. https://lists.fedoraproject.org/pipermail/legal/2008-April/000245.html
I've also started on the analysis for getting xTuple web into an official package, you can find my initial comments on that here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742996 - there is clearly more work for the community to make an official set of packages (including all the tools you rely on) This will also go a long way to boost quality, ease your own development processes, engage with community development and let new users get started even more quickly. The exposure that this gives your brand outweighs the benefits of the CPAL badgeware clause. However, having the uncertainty about CPAL in some distributions (including Debian/Ubuntu, which are now the biggest in market share) has a negative motivational impact for any developer who would collaborate on these official packages.
You've asked about the impact that the license has on developers - but there is one other interest group worth considering, the unscrupulous people who want to profit from your work without respecting your terms. It is worth considering the fact that these people don't actually care whether you have CPAL or GPL or any other license, they are just going to do as they please anyway. If you are thinking about a complete move to GPL, I don't think you should worry too much about whether the more unscrupulous people out there will be any more or less likely to change their behavior.
Wed, 04/02/2014 - 07:34#16
That's some really good
That's some really good feedback, Daniel, and exactly the sort of arguments that I was hoping would get put on the table. Thank you for taking the time to research and post this information.
In any case, this feedback is great. Thank you.
Mon, 03/31/2014 - 18:37#17
> you are all but guaranteed
> you are all but guaranteed to find somebody who will let you download said code at no cost. Why would anybody pay for that?
Software licensed under the terms of the GNU GPL cannot be sold the exact same way as proprietary software, that is clear.
Since businesses may want to integrate the product into their own proprietary offerings the GPL would provide those businesses a strong incentive to either distribute under the GPL, and therefore help the community, or purchase a proprietary license from xtuple for a copy of the software under terms approptiate for their business model. With a non-protective license such as the Expat or Modified BSD, proprietary businesses have no incentive to purchase from xtuple (they can just turn everything proprietary) and no incentive to share with the community (for the same reason).
Finally, I can imagine that at least some people would be willing to pay for software that they can get somewhere else for free as long as they get it from the people who actually developed the software, who offer support, and are a respectible, well regarded business (I can't imagine saying to my boss: "I didn't buy it from the company, I just found a copy online for free somewhere, got that instead, and installed it on our servers... I'm sure it's fine!)
Those are just my thoughts. Hope that they are of some interest or use.