The Open Source model – and by Open Source we mean products that adhere to the Open Source Initiative (OSI) guidelines – doesn’t, and may never, work for many important software domains. All religious fervor aside, this is a reality because customers say so. We may want it to be otherwise, but the ultimate arbiters in the Open Source versus proprietary debate are customers.Editorial Notice: All opinions are those of the author and not necessarily those of osnews.com
We founded Dark Horse in December 1999. Our business at that time was solving interesting customer-related challenges for our clients, and specifically through the use of information technology. And because we’d had considerable experience using OSI products we assumed we could deliver as part of our value a compelling Open Source CRM that would save money and meet the needs of our clients. But we were mistaken. For while there were great OSI products at the lowest levels of the software stack (e.g. Linux and Apache) and quality stuff in the middle (e.g. MySQL and PostgreSQL) the application layer was disappointing. There simply weren’t any enterprise-class, Open Source CRMs that we trusted could serve as the foundation for a robust customer management platform. And in our humble opinion, there still aren’t.
So necessity being the mother of innovation, we embarked on creating our own version of an “open” CRM. Taking our customers’ lead, we worked with them to create a solution that put in the important stuff they wanted and left out the rest. Our approach became equal parts building what they were willing to pay for while doing what we thought was best. It’s now four years and many engagements later and working jointly we’ve created Dark Horse CRM. It’s a robust, continually evolving, customer-defined, enterprise-class CRM licensed under what we refer to as “Community Code”. And from our customers’ point of view – which is what matters most to us – it looks a lot like Open Source. They have access to source code, they can add to it, they’re part of a community of business users (and with tools to support them) and improvements flow back for the benefit of all. But our license doesn’t precisely follow the OSI guidelines. Why? Because Community Code better fits one of our clients’ top requirements of us – that we remain a viable commercial enterprise that continues to aggressively advance the product and is there to support it. The Open Source model, at least in the space we’re playing (CRM), didn’t allow us to evolve the commercial side of our business to the degree our stakeholders require. Our customers want control of code; they don’t want to be held hostage; and they want a fair price. They also want an application that is rapidly evolving; they want it to run on both commercial and OSI platforms; and they want somebody they can turn to for support 24 X 7. To live up to these expectations we needed to modify our business model… and by extension the core licensing approach that underlies it. Thus was born our Community Code approach and our initial product, Dark Horse CRM.
How the Community Code model works
As the term implies, organizations that license Dark Horse CRM effectively become part of a community. And two characteristics are common to most communities. First, they’re formed of individuals with like interests. And second, they provide value compelling enough to entice members to join. In the case of the Dark Horse community, companies share an interest in better managing and servicing their customers, and specifically through the use of technology. The value that compels these organizations to join is access to software that approaches in sophistication that sold by proprietary vendors, significantly surpasses in design discipline and rate of development the OSI offerings, but which adheres to many tenets embodied in the latter. For instance, similar to OSI, the Community Code model allows users to extend the product at the source code level. As well, members of the community pay neither initial licensing fees nor for upgrades. The ethos of Community Code therefore is a cousin to OSI; members have ultimate control of their software destiny – which access to source code allows – while not forced to pay for that which has already been developed.
But healthy communities have rules. And the principle rule of the Dark Horse CRM community is similar to that which forms the basis for the GNU GPL – the mother of all OSI licenses. And that is, all extensions and improvements which users (i.e. members) make to the product come back to others in the community. The reason for and fairness of this rule is easily understood. In first becoming a part of our software community members have the right to use, for free, that which is already there. In effect, they have access to the combined development of those who have joined and contributed previously. This is a considerable benefit for joining. The quid pro quo, however, is an agreement to provide back to the community all improvements to the code you as a member might (but aren’t obligated to) make going forward.
And successful communities also require discipline, processes and infrastructure to operate. That is, there are real costs to running them. The Dark Horse community is no different. Accordingly, the use of Dark Horse CRM and belonging to the community is not free. Users are obligated to assist in the ongoing support of the software and community by paying a maintenance fee. This obligation, which takes the form of an annual payment, looks similar in scope and form to that which proprietary vendors also call maintenance. In the Dark Horse model it’s mandatory, at least for some period of time.
More about us and our approach is found at www.darkhorsecrm.com.
the GNU GPL – the mother of all OSI licenses.
Wouldn’t that technically be the BSD license?
Wouldn’t that technically be the BSD license?
The BSD license was more of an ideal rather than a mentality. The GPL is what really gave birth to the “open source movement”. I think that’s what this statement is referencing.
Now if only GNU would update the GPL to take into account the existance of things like… the Internet… and dynamic linking.
As these guys are doing, open-source and proprietary can co-habitate fine. They’re using an open-source infrastructure
and adding on to the software stack. The people that are value-adding to the software stack get their pay and the open source projects get enhancements from these vendors, while the people that are working at the open source level can eventually move up to some hybrid proprietary/open solution at a later time if selling services isn’t cutting it. It’s great for business.
It sounds like Dark Horse is being creative with their business model. Their stakeholders get control of the code and and they’re using open source solutions lower down on the software stack. Good for them.
Thought provoking editorial. I actually spotted this CRM app on freshmeat a day or ago & didn’t think too much of it. However now I have some questions. Where is the license that governs this Community Code? I would like to look at it, examine it to see if it has merit and make sure it is a sound license before considering myself to be bound my its terms. I checked the site & its seems to ask for me to fill in a form. I do not want to download/register or sign up for anything just to read a license. Why link to opensource.org if opensource.org does not have your Community Code license? I understand that Dark Horse CRM is new & may not have had time to get crawled by search engines but I used google & did not turn up anything insightful about their product & its license.
Also, what is the this maintenance fee that is mentioned? How much is it? Is it contingent on users/usage/CPUs/accounts? Does the maintenance fee guaranteed support? Many proprietary & FLOSS program’s license/EULAs indicate that there is no warranty or guarantee. I am all for paying money for things that are necessary like health insurance, food & software and I expect to be paid for work performed. Therefore a maintenance fee is not unusual.
I suggest that Dark Horse backup their claims with easy accessible FAQs. Or perhaps just some links to the license.
“The Open Source model – and by Open Source we mean products that adhere to the Open Source Initiative (OSI) guidelines – doesn’t, and may never, work for many important software domains. All religious fervor aside, this is a reality because customers say so.”
A similar argument could be made for proprietary software, nothing profound either way. Anyway the important thing about OSS isn’t that it will fill your present needs (as nice as that is) but that it has the potential to fill them in the future. Customers change, and their needs and wants right along with them. Todays no could be tommorrows yes.
I’m a big believer in open code, and I think this model might be a great compromise for types of software where there isn’t enough developer interest, or skill, to sustain a top-shelf Free Software product. There is enough developer interest (and skill) to turn software markets like e-mail apps, etc, into commodity markets, but the same is not true for markets like high-end 3D modelers. With a model like this, companies can make their money, but the open code community is still preserved. Something like t his is in stark contrast to “initiatives” like Microsoft’s Shared Source program, which are basically “look, but don’t touch!”
The GPL needs two updates:
– Internet
– Patents
The FSF will be working on GPL v3.0, so hopefully these things will be addressed in that release.
The GPL already addresses dynamic linking. Dynamic link is fully equivilent to copying code. Otherwise, the GPL would be pointless — you could just put GPL’ed code in a .so and use it “copying” it. The FSF already takes into account those who want to release libraries that can be used by non-GPL-compatible licenses. Its called the LGPL.
The GPL already addresses dynamic linking. Dynamic link is fully equivilent to copying code.
No, this doesn’t address the issue at all. By such an overly simplistic explanation, dynamically linking GPL code with something like, say, the Solaris libc, would be illegal. But in this case it’s not. Why? Because we informally decree that system libraries are exempt? What’s the legal justification? Because the Solaris C library is no more a derivative work of a GPL application than a proprietary application running on Linux is a derivative of glibc? Wouldn’t glibc interfacing with the Linux system call make glibc a derived work of Linux, and thus using glibc on Linux mean that glibc was technically licensed under the terms of the GPL at that time, thus linking glibc with proprietary applications is illegal? Or should we say that the Linux system call is an open interface and thus not subject to the terms of the GPL. If so, what prevents someone from releasing a set of interfaces to a proprietary application under the terms of the GPL, then writing bridge code between a GPLed library and the GPLed set of interfaces. If this code were, say, compiled into a “plug-in” library, and a proprietary application were to say, have plug-in support and provide a means of downloading plug-ins, and were to download this plug-in (which would provide a copy of the GPL and links in its on-line help to the complete modified plug-in source code including the GPL library, the GPL interface definitions, and the GPL glue code, would such a situation be in violation of the GPL? You may, as a layman, have a gut feeling about any of these situations, but looking at the actual wording of the GPL (which is extremely ambiguous on these sorts of matters) it’s not possible for a layman to determine whether or not any of these particular situations are in violation of the GPL.
Otherwise, the GPL would be pointless — you could just put GPL’ed code in a .so and use it “copying” it.
Determining exactly where the barriers between applications lie is a very tricky problem. Would it be against the GPL to release GPL code which links with a library and talks to a proprietary application over pipes? What if instead of pipes, a mechanism like CORBA is used? Do you define dynamic linking as two programs running in the same address space, or communicating via a standard ABI. Does CORBA count as a standard ABI? If so, should writing a protocol to pass commands to GPL code over pipes violate the GPL? If so, wouldn’t a proprietary application invoking a GPL application from a script technically be in violation of the GPL?
You’re really stretching the wording to say outright that dynamic linking is forbidden, and analyzing the actual wording to determine a particular interpretation in the specific situations I’ve mentioned is outright impossible for any layperson… the answers to those questions would only come through weeks of litigation in a court.
There is no definitive interpretation on these matters, and this is what is desperately in need of an update.
The FSF already takes into account those who want to release libraries that can be used by non-GPL-compatible licenses. Its called the LGPL.
There are many GPL libraries out there, and there are many ambiguous cases for combining LGPL, BSD licensed, and GPL code.
You claim that open source is necessarily incompatible with certain domains yet provide not even anecodtal proof.
This isn’t even an editorial, its an ad for your CRM system wrapped in a flimsy pseudo-intellectual skreed on licensing.
with all the buzz words throw in. I mean you can buy propriety software nowaday with source code supplied. What’s this community code different from propriety software come with binary and source code together?
Stamp a ‘community’ on it does not make it any less propriety.
Yet another company trying to look like great benefactors to the ‘community’, while at the same time being too scared to offer their product in a normal open source license.
This crops up all the time, people that feel they would be run over if somebody else could use their code. Is this because they know someone else could do it better?
A good supplier would loose nothing on releasing it truly open source, but could gain a lot! Your market share could skyrocket, giving you guys a unique position as the original authors. But no, you (as many before you) do not have the guts.
This is a waste of bits people, just another company that does not believe in open source, but who wish to god they ‘sound’ like they do.
Best of luck to you.
Because we informally decree that system libraries are exempt? What’s the legal justification?
———–
Its not an informal decree. There is a specific clause addressing system libraries:
“However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs”
Wouldn’t glibc interfacing with the Linux system call make glibc a derived work of Linux,
———–
That would be the case if Linux was purely GPL. But its not. Its GPL with a clause that says that applications using its system-call API, as well as drivers, are not derived works.
Do you define dynamic linking as two programs running in the same address space, or communicating via a standard ABI.
———-
The definition of dynamic linking isn’t under question. Dynamic linking means creating a shared library and linking against it. The only reason dynamic linking even qualifies as “copying” is because of this clause:
“If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.”
Its unreasonable to consider a program an “independent and seperate” work when it:
a) Directly includes copyrighted header files from the library in question, and
b) Won’t even link without the GPL’ed code!
and analyzing the actual wording to determine a particular interpretation in the specific situations I’ve mentioned is outright impossible for any layperson…
———
I think we’ve got a definition mismatch here. I would agree that those situations need to be clarified, but would also say that they have absolutely nothing to do with dynamic linking! They are examples of the question “well, what happens when you talk to GPL’ed code over a protocol?” This situation is really just a generalization of the networking situation, which does need to be clarified.
There are many GPL libraries out there, and there are many ambiguous cases for combining LGPL, BSD licensed, and GPL code.
———
Exactly why do you think its ambiguous? It seems perfectly logical to me. GPL’ed code can link against BSD libraries, and vice-versa. In the case of dynamic linking, the resulting binary (which only exists are a run-time image) must be redistributable under the terms of the GPL.
It seems it would be wiser to stick to BSD which is obvious to everyone and has all the benefits of an open source license anyway.
It’s madness to use GPL, since not even the great of the great seem to realize its implications. And when you think about RMS and the likes, you figure out quite quickly that a lunatic is behind it.
Howabout keeping things PD or BSD or MIT and simply don’t suffer from all the problems GPL brings…
The GPL, for all its complexity (much of which, of course, exists only in the minds of those in other camps), has one virtue: it demands that code be open. For a lot of people, their code isn’t a gift, or a charity. Its their contribution to the community. They believe that if someone wants to use their code, they should contribute back to the community. For a lot of developers, especially corporations (paradoxically), this is an important aspect of the GPL. Individuals like it because it fosters a community, and companies like it because it makes it difficult for competitors to take advantage of their contributions to the community.
The BSD works on a different philosophy. Developers who want their code to be a gift, a charity, use it to allow others to use their code however they want, no strings attached. This thinking, too, has its place.
There is a very good analogy between GPL : democracy and BSD : (peaceful) anarchy. The GPL creates something of a social contract. It ensures freedom for the community by creating certain rigid rules that limit certain freedoms. The BSD license assumes that everyone will be a good citizen and play together fairly. If your goal is to create a community of free software developers, and make no mistake, that is the goal of the GPL, than history (both the GPL’s and that of democracies) shows that the former approach is more successful in practice than the latter.
Is there a well written explanation of Linking, in reference to the GPL?
Why I am not clear is this :- Say I wanted to write a new GUI for an existing GPL’d application, and possibly add some new functionality, the options I may consider would be:
(A) I take the application’s source code, remove any existing GUI code out of it, and simply code a new GUI, code some new functions, and then compile/link the application and my code statically. Would this be in violation of the GPL?
(B) I take the application’s source code, remove any existing GUI code out of it, package it’s remaining functionality as a library, and then compile/link this library dynamically with my new GUI code and functionality. Is the library in violation of the GPL? Is the new GUI code and functionality in violation of the GPL?
(C) I take the application’s source code, remove any existing GUI code out of it, package it’s remaining functionality as a daemon/process, and then code my new GUI code and functionality to communicate with the daemon/process via shared memory. Is the daemon/process in violation of the GPL? Is the new GUI code and functionality in violation of the GPL?
(D) I take the application’s source code, remove any existing GUI code out of it, package it’s remaining functionality as a daemon/process, and then code my new GUI code and functionality to communicate with the daemon/process via local IPC (COM, CORBA, Named Pipes, SYSV Msg, etc.). Is the daemon/process in violation of the GPL? Is the new GUI code and functionality in violation of the GPL?
(E) I take the application’s source code, remove any existing GUI code out of it, package it’s remaining functionality as a daemon/process, and then code my new GUI code and functionality to communicate with the daemon/process via TCP/IP (HTTP POST, SOAP, XML-RPC etc.). Is the daemon/process in violation of the GPL? Is the new GUI code and functionality in violation of the GPL?
I really would appreciate people’s thoughts on this. As I see it, there must be a point between A and E where my new GUI code and functionality stops being in violation of the GPL – Where is this point? If all the above options are in voilation of the GPL, then a large chunk of the internet is voilating the GPL :- Every time a Web Browser (new GUI code and functionality) makes a request for data from a GPL remote application it would make the Web Browser in voilation of the GPL. In effect a Web Browser and the Web Application Software it is accessing are option (E).
The GPL is good for certain things, such as compilers and kernels and not so good for other things. At the end of the day developers have to make money and if you think that you can make a living licensing your code using GPL, BSD…then go for it. These guys have chosen a business model that works for them. At the lower end of the software stack they’re using open source products which is a good thing. The use of open software along with proprietary software lowers the barrier of entry for developers who otherwise would have a hard time coming up with the capital for other expensive propietary products at the bottom of the software stack.
When you have to put food on the table you don’t have the luxury/burden of being idealistic/stupid about software licenses.
The GPL, for all its complexity (much of which, of course, exists only in the minds of those in other camps), has one virtue:
This is an awfully sophistic statement. First, I’d argue that the GPL has more than one virtue, but that’s really more of an ideological statment than anything grounded in fact. The second part of this statement is simply incorrect. I have no disagreement with the GPL and have worked on GPLed projects as well as proprietary ones. To suggest that those who know that there are intricate and complex intellectual property issues within the GPL are its enemies is insulting. The GPL is a legal contract, which when you abide by it, provides you certain rights. However, if you do not, then you lose your rights and may not distribute derivative works generated from GPLed software. Many of those who make a living out of practicing intellectual property law know a lot more about the complexity of these contracts. I have to confess that most of the details elude me, as I’m not a lawyer. However, I have attended presentations by people knowledgeable in such matters, and I can tell you that there is plenty of complexity for all. Considering that it’s in the interest of people who want to use the GPL to their advantage to abide by its conditions, I find it unusual that you would be so cavalier about the details.
There is a very good analogy between GPL : democracy and BSD : (peaceful) anarchy. The GPL creates something of a social contract. It ensures freedom for the community by creating certain rigid rules that limit certain freedoms. The BSD license assumes that everyone will be a good citizen and play together fairly. If your goal is to create a community of free software developers, and make no mistake, that is the goal of the GPL, than history (both the GPL’s and that of democracies) shows that the former approach is more successful in practice than the latter.
Actually, this is a specious analogy. The GPL and BSD licenses are contracts. Contracts are goverened by the laws to which the parties entering are subject. The concept of democracy involves a government that is run by the people or their elected representatives. Nothing about the GPL provides for representation, or the involvement, of the general public. Rather, you create a piece of software and release it under the GPL. Anyone may download it or use it, however, derivative works based upon the work you created must also be subject to the same licensing terms as the original work. In this case, it also means that the derivative works must be released in source-code form with original licenses attached. There is no voting or will of the people involved. These are the terms of the agreement, plain and simple. The BSD license is less restrictive than the GPL. I find your comparison to anarchy rather flimsy, as neither case appropriately addresses who is in control. In both cases, it is the original author of the software that must seek legal recourse against parties in breach of the contract. I’m also not certain you’ve completely figured out how freedom fits into all of this. Freedom is the exemption from the arbitrary exercise of authority in the performance of a specific action, and I would argue that the BSD license is more free (if you can compare such things) than the GPL. That said, there are still restrictions and stipulations as there would be with any license. Comparing software licensing strategies to forms of government isn’t really applicable or meaningful. They are concepts unto themselves, and are subject to the law. (Which in the United States involves a lot of case history as well…). I also don’t know how you propose to create freedoms by restricting freedoms. Further, nothing about the GPL suggests its intent is to create a community of software developers. The preamble to the GPL states that the license is about protecting your rights. See:
http://www.gnu.org/licenses/gpl.html
I have a lot of respect for the GPL, but please understand it is a contract. Developer communities have been created because of other factors. The GPL just plays a part in this. (As is evidenced by other development communities springing up around software licensed under different terms).
The choice is there, and it is good that there are so many alternative licensing models. Just let developers choose what licensing model they want (or need) to use and support – which may, naaturally, depend on the case too. Now, isn’t that true freedom.
As to open source, most of the time OSS developers seem to vote for GPL when choosing the license for their software. The GPL is a sort of a guarantee that the OSS developers do get their reward too from potential future enhancements of that code, and that the software shall always stay open for the benefit of everyone.
I seriously doubt whether open source movement would be anywhere near as big a thing than what it is nowadays without a license like GPL. BSD model alone didn’t make the open source movement what it is today. And what ever one may think about Stallman’s fanatic free software extremism, he with his GPL (etc.) has probably done more to help the open source movement than anyone else.
Its unreasonable to consider a program an “independent and seperate” work when it:
a) Directly includes copyrighted header files from the library in question, and
b) Won’t even link without the GPL’ed code!
If i rememeber correctly, when using .dll’s you don’t really need the header files.
As others have stated the whole comparison between the GPL/BSD and an anarchy/democracy isn’t really valid. I’ve seen you use that analogy before, and I don’t it’s a very good one. It’s just software after all.
This isn’t even an editorial, its an ad for your CRM system wrapped in a flimsy pseudo-intellectual skreed on licensing.
Funny… I thought it was a real world example of the difficulties of open source business models. Remember, religious ferver doesn’t count for much for the author 🙂
This article writes about the “Community Code” model as if it’s something new and different. It’s not: it’s the Mozilla Public License with a maintenance fee. The MPL says you contribute back changes too.
The article also implies this wouldn’t be possible with the GPL, but that isn’t true: my company enhances/customises and then sells GPL software (for much more than the cost of copying!), as it’s perfectly allowed to. We give our customers the code as the GPL says, but no-one else has to get it (the customers can in turn give it to someone if they want, but that’s their choice – the GPL doesn’t force this either). So yes, you can do software development and 24×7 support on GPL software. No big deal.
Firstly, IANAL.
Secondly, IANA currently active programmer.
But I will attempt to answer your quetions, as best I can.
As regards (A)
Most Free/Open Source software is written with modularity in mind and in most cases the UI is developed independentantly of the functionality which the software provides. There are of course many exceptions. The UI is generally developed as an implementation of the base functionality which the application should provide. In most cases the UI’s developed only impliment those functions of the application best suited for the environment of the corresponding UI. ie. The CLI UI of mplayer implements a superset of the functionality which mplayer provides, taken as a group of subprograms/libraries, as opposed to the GUI (gmplayer) implementation of mplayer. The modularization of software is apparent in the The CLI/GUI split found in most Free/Open Source software. So in most cases it is not necessary to remove existing GUI code from an application-one simply extends the code and offers the alternate GUI, which you developed, as a compile-time option.
AS long as you provide access to the unaltered source and your implementation abides by and is released under the same licensce (GPL in this case) you can develop your own GUI as you see fit.
In the case where the application is not sufficiently modularized to seperate core functionality from the implementation details of the UI you may have to further subdivide and alter the core program to make it amendable to uses as a library or group of libraries. In most cases like this it would probably be best to attempt to define the functionality which your application should provide. After doing so it would then be appropriate to look for existing libraries which fulfill these requirements. In the case where such requirements are only filled by an application where the there is no clearly delineable distinction between core functionality and UI implementation you would have to extract those particular functions which meet your requirements and mold them into a library which could then be linked to your GUI.
As to the question of removal- you may only remove a particular compiled-in GUI in your distributed binary file- ie-the binary form of the application which you distribute can contain- be compiled with- any options you wish to include or exclude. You may however not remove the pre-existing GUI code from the source code which you provide for distribution, for that would result in altering the original source which must be made available in unaltered form to any who seek it if you choose to distribute your application under GPL.
As best as I understand this situation the following scenario seems to be an answer to your question:
You hav found a program which provides the functioanlity which you desire but where the existing GUI either does not implement this functionality sufficently or implements this functionality crudely. Moreover this application is badly written for it does not internally distinguish between core functionality and GUI implmentation. So at this point you decide to “free” the functionality of the application from the ill-written GUI. At this point you should probably jsut decided to craft your own library. You would do so by dissecting the source code and identifying those core pieces of functionality which you need. Then you would amalgamte these functions into a new library-libnewfunc.so. As long as this library abides by and is distributed under the GPL and as long as you provide access to the original code from whence your library is derived there should be no problems. You would then code a GUI which implements some subset of the functionality provided by the new library. Then you would package these together either in the form of a modularized program with comple-time options or as two seperate packages-libnewfunc and libnewfun-ui. It would probably be best if you were to mention in source code comments that certain functions were derived from the application, oldfuncandui written by Joe Programmer. However I do not believe this is necessary.
In short (B) is probably the best answer to (A)- yet if you can follow the rules to which I have alluded to time and time again you probably already have the answer to (C) (D) and (E).
Or in other words. The scenarios you describe (A) through (E) are scenarios which have been played through time and time again in Free/Open Source Software. There are countless examples of applications which have gone through the various iterations which describe without ever having violated the GPL. For if at each stage the requirements that the GPL imposes(and only imposes in the sense that you agree to adhere to them) are fulfilled there is no violation of the GPL.
“As I see it, there must be a point between A and E where my new GUI code and functionality stops being in violation of the GPL – Where is this point?”
I do beleive that that there may be some work necessary in clarifying all possible contingencies as regards the GPL in connection with web ASP. Yet the question you are posing here is as such non-answerable. None of the scenarios as such represent a violation of the GPL, provided you abide by and distribute your code under the GPL. Nowhere is it written in the GPL that you cannot modify GPL code to add a different GUI. Nowhere is it written in the GPL that you cannot take other GPL code and abstract its functionality according to varying degrees of abstraction.
The wording of your scenarios and the question you pose is loaded. “Remove” is fine if you are talking about a compile-time option and you are refering to the distributed binary. “Remove” is violation of the GPL is you are refering to the source code of the application. IF you remove something from the “source”-ie. from whence something came, it is no longer available for free use by others. You do not ask:
“As I see it, there must be a point between A and E where my new GUI code and functionality would violate the GPL – Where is this point?”
You do not ask this question because there is no direct relation of GPL violation to the scenarios which you present.
I will attempt to be a bit more concrete: take Lyx for example. Lyx was originally written to use Xforms only. Lyx is a GUI only application. Recently QT support was added to Lyx. GTK2 support is planned and under development. I could not take Lyx and strip it of Xforms support and label it as Lyx. I probably could package a version of lyx, labeled Lyx-QT-only as a binary package where the xforms option was not compiled-in. Yet I would still need to supply access to the unaltered source code from whence my package was derived. I could could take Lyx and add TCL/TK support or FLTK support and release a new program called Lyx-fltK-yet I would need to submit such changes back to the Lyx project unless I decided to fork the project,but even if I forked the project, as long as my code abides by and is distributed under the GPL those participants in the original Lyx project could use the code which I added to it.
I have attempted to answer your questions in a straight-forward fashion, although I am not sure that you are being forthright in your asking. I am giving you the benefit of doubt.
Interesting comments, but I have a couple of nits to pick.
The GPL is not a contract. It is a license. It does not attempt to add any restrictions to those specifically granted by copyright law. Most EULAs do add further restrictions, and are therefore contracts.
> The BSD license is less restrictive than the GPL.
Absolutely.
> I also don’t know how you propose to create freedoms by restricting freedoms.
I think many of our laws do exactly this. Laws against theft, murder, slavery, etc…
It looks like the new Apache license might not be gpl compatible and Eben Moglen (the jr. communist legal advisor to the FSF) described free software as “a social movement with specific political goals which will characterize not only the production of software in the twenty-first century, but the production and distribution of culture generally”.
With lead FSF figures making insanse comments like that you don’t really need any critics.
“The article also implies this wouldn’t be possible with the GPL”
(An interesting model you state)
It is in MPL:
http://www.compiere.org
Compiere is FLOSS for everyone who wishes; everyone can see the code. One needs an Oracle which is supported by the contract; the contract is optional.
You stated:
“It looks like the new Apache license might not be gpl compatible and Eben Moglen (the jr. communist legal advisor to the FSF) described free software as “a social movement with specific political goals which will characterize not only the production of software in the twenty-first century, but the production and distribution of culture generally”.
With lead FSF figures making insanse comments like that you don’t really need any critics.”
The deal with the new Apache(ASF) licensce is that they were attempting to draft a new licesnce which would be compatible with the GPL. The ASF licensce was hitherto never GPL compatible. It is a shame that they have not succeed yet in their attempt at becomming compatible Eben Moglen has gone on record discussing the possibilites of incorporating the patent clause of the new ASF licensce in the GPL ver. 3.0. Apache itself says it has no problem with linking GPL applications with Apache and considering the derived application GPL. There is no real dispute here-the only problem is that the ASF includes requirements(regarding patent-free) over and above the requirements enumered in the GPL and the sixth clause of the GPL precludes any additional requirements beyond those enumerated in the GPL itself. Yet again, this is not a problem because there are no GPL applications which previously were linked to Apache-as is the case with the new XFree86 licensce. I suspect that convergance between the GPL and ASF will be reached through some combination of the following: a) changes to the GPL regarding patents planned for ver. 3.0 b) further changes to the ASF licesnce. c) the possible dual-licenscing of apache…..
But your comments regarding Eben Moglen are simply braindead. Firstly you refer to him as a “jr. communist”, which is, simply put, wrong(as if it were a bad thing if he happened to hold such values). Then you quote a description which he made of free software, albeit without reference to when, where, to whom and in what context, and remark how “insane” this description is and how this “insanity” would somehow lead the FSF into a position which due to their supposed “insanity” would relegate them to such irrelevance as to not even being subject to criticism and critics.
It is ashame that you are being blindly led into believing that your apolitical, individualistic identity is not already always being used against you as a political, social identity which is so easily manipulable due to the non-reflected, reified nature of such thought. If 50,000,000 people think like you do imagine how easy it is for others, decision makers, to use the non-uniquness of your stance against you. In the name of your individualism you become a pawn of social engineers who rule you. Yet you then point the finger at the FSF and cry foul-mistakenly confusing these people(FSF), who share much in common with you, with the real social engineers, your congressmen/senators/CIO’s etc. who dictate what you consider to be “yours” in the first place… You may hold yourself so, but you’re not being held so by others who make your decisions for you.
As regards the topic of this thread:
Unfortunately neither the article nor the web site referenced points to the actual license in question here. Although the points that the author has made seem somewhat valid and his approach to solving these issues seems quite reasonbable, without seeing the actual licensce it is very difficult to really respond what he is saying……
Open source NEEDS a decent way to provide the revenue that ensures the customer orientation and support that customers want. There are ways to make a business model with open source, but you can’t listen to people like Stallman with strong antipathies towards ANYBODY trying to make a buck in the industry.
“but you can’t listen to people like Stallman with strong antipathies towards ANYBODY trying to make a buck in the industry.”
Oh is he? Why FSF sell GNU CD’s then?
Please don’t confuse “propritary software” with “commercial software”. You can find information about both subjects as well as models and suggestions for businesses on the FSF website.
Here’s another interesting view from someone who develops ERP-like, from his point of view and how he convinced his executive: http://www.advogato.org/article/745.html
“It looks like the new Apache license might not be gpl compatible”
The old Apache license wasn’t GPL compatible either. So what’s your point?
“and Eben Moglen (the jr. communist legal advisor to the FSF)”
Oh now we see your point: Flamebaiting. I don’t suppose you would have any evidence that Moglen is a communist, would you?
“With lead FSF figures making insanse comments like that you don’t really need any critics”
They sky is falling! If we allow the public to have ANY control over “the production and distribution of culture generally,” why society will just fall straight into the abyss! Someone think of the children and how much they desparately need big corporations and industry groups like the RIAA to control & dictate our culture!
If you are so terribly threated by the GPL license, why not lobby the authors of software to NOT licesne their software under the GPL? That would seem to be far more productive, than say, authoring infantile ad hominem attacks on those who have a have a hand in the creation of the GPL license.
“Open source NEEDS a decent way to provide the revenue that ensures the customer orientation and support that customers want.”
That already exists. It is called selling the services based on the software. See IBM for examples.
“you can’t listen to people like Stallman with strong antipathies towards ANYBODY trying to make a buck in the industry.”
Have you read any of the licenses that Stallman has written? GPL commoditizes software, which would have happened sooner or later, whether the GPL existed or not. Stallman’s software licenses specifically allow GPL software to be sold. Further, Stallman’s licenses take no stand, one what or the other, on selling services based on the software.
Your argument is the equivalent of saying, well salt is a commodity so now on one can make money selling salt, while totally ignoring the existence of the commodity, which is for sale, and being sold, in the market! Perhap you need to check your sources?
What is this all about anyway? Bandwagon hijacking followed by flimsy Shared Source argumentation (“You’re part of our community but you need guidance. We own you now!”) and denial that a genuine open source solution could easily come in and rain on their parade (if several haven’t already done so).
Dark Whore CRM more like.
“And the principle rule of the Dark Horse CRM community is similar to that which forms the basis for the GNU GPL – the mother of all OSI licenses. And that is, all extensions and improvements which users (i.e. members) make to the product come back to others in the community”
Thats simply untrue, the GPL requires that you distribute the source to people you distribute the binarys to. If a company wants to modify GPL code, they do not have to release it back to the public.
To me this this “Community License” is a far worse deal for the companies involved.
Thanks for the reply Karl but you missed the point on the main.
The point was to assume that the “new GUI and functionality” would be not be licensed by the GPL, but rather be closed source.
ie. If I was to release 5 different versions of my “new GUI and functionality” in the ways described (A-E), then which, if any, of my closed source applications would be in voilation of the GPL.
“AS long as you provide access to the unaltered source and your implementation abides by and is released under the same licensce (GPL in this case) you can develop your own GUI as you see fit.”
And if I do not? This was the point of the rhetoric…
Are *all* options (A-E) going to voilate the GPL license of the original code if the “new GUI and functionality” is released under a closed source license?
If so, scenario (E) described a typical client/server session between a Web Browser (ie. Internet Explorer) and a Web Application/Service (ie. Slashcode).
My point is, that if it is shown that (E) is not in voilation of the GPL license, then how do we find the spot between A and E where voilation occurs? And where is this spot?
“If a company wants to modify GPL code, they do not have to release it back to the public.”
Afaik that’s untrue too. If they want to modify GPL code they don’t have to make their changes public. They only have to do if they distribute binaries which includes GPL code and they’re asked for the source.
So a company could extend GPLed code, use it internally, without distributing their changes to everone.
While not qualified to judge Richard Stallman mental health, and allowing for the possibility that his goals are realistically unattainable (until you are there, there is no proof that you can get there), there is one word that accurately describes the intent behind the GPL: reciprocity. In other words, you give what you get. You give code, you get code in return. You get code, you give code in return. The GPL is problematic for commercial application because profit is not, and never will be a concern of the GPL.
Beyond that, it’s your time, so you decide how you want to get paid. But if you want cash for code, abide by the GPL, or don’t start with GPL’ed code.
“So a company could extend GPLed code, use it internally, without distributing their changes to everone.”
Is that not exactuly what I said?
“””The GPL is problematic for commercial application because profit is not, and never will be a concern of the GPL.”””
It’s more of a problem of people still selling software not services.
The GPL tends to be good in some others, such as compilers and OS’s and possibly some other areas where selling services is economically viable, but to assume that everybody can make money on just services is foolish.
It’s too bad that the FSF tries to hijack free sofware as a means to its extremist political ends. Who knows how many organizations/people have been turned off by RMS and cohorts rantings and ravings about GNU/this GNU/that and their extremist political views.
Reading all these good comments motivates me to make one of my own – partially to summarize once again why we at Dark Horse have decided to manage and sell our products under our Community License, and partially to directly address some of your questions and criticisms.
First, UnderScore asks where is our license, so that he can read and evaluate it. Thanks for pointing out a problem. The license is now available at http://www.darkhorsecrm.com/Website.do?topic=Products§ion=crm-c… To those who have criticized the validity or value of this license, I can only state that attorneys from some very large customers have examined the license and found it fair, and of value. If you don’t like it, we can agree to disagree.
AC asks “So it is just another proprietary software with all the buzz words throw in. I mean you can buy propriety software nowaday with source code supplied. What’s this community code different from propriety software come with binary and source code together? Stamp a ‘community’ on it does not make it any less propriety.” Yup, it might be fair to label our product “proprietary”. I would reply that unlike normal proprietary vendors, our model provides all upgrades from both Dark Horse and any other community member who improves the application free of charge. So I think that you might view our software as proprietary, given that you do have to pay us something, but on the other hand, we’re providing much more than any proprietary vendor I know of: a great application (YMMV), a model that provides control, and flexibility, at a great price.
To the others who assert that our model is nothing new, or just plain wrong because it’s not Open Source, or say we are afraid to open our code, I’d make these points:
1. We are in business (let me emphasize the word business here) to provide software that competes head-to-head with both our proprietary and our open competitors. We think we are doing a good job based on customers who have chosen DH CRM over SalesForce.com, MS CRM, and even Siebel. I think our model allows us to do this where others do not.
2. Yes, this model is a compromise between open and closed, but we chose it because it allows us to provide excellent design, excellent code, and a product you wouldn’t otherwise be able to find at our prices. Yes, you can point to other open CRM developers who are surviving by selling support, but in our minds, they are not accomplishing the goals we have set out for ourselves.
3. Dark Horse CRM is now roughly 500,000 lines of Java code, a pretty serious investment of time, effort and cash. We think we can best support our customers’ needs by more closely managing the development of that code than we could in a pure Open Source atmosphere.
4. You are, of course, free to disagree with us, as I know many of you do.
Lastly, my thanks to Roy Batty, Me likey, Jason and others for seemingly understanding what we are trying to do and why. Others may think that we’re “just another proprietary company”, but we respectfully disagree.
Thanks for listening!
Dark Horse
I entered a bad URL. The correct URL for our license is: <A HREF=”http://www.darkhorsecrm.com/Website.do?topic=Products§ion=crm-c…
It’s somewhat simplistic to view services as only installation/service contracts (which seems to be what you are implying). As bandwidth gets cheaper there’s no reason why a majority of the software we use today can’t be migrated to some sort of service oriented architecture.
“””It’s too bad that the FSF tries to hijack free sofware as a means to its extremist political ends. Who knows how many organizations/people have been turned off by RMS and cohorts rantings and ravings about GNU/this GNU/that and their extremist political views.”””
I’m not sure you can really “hijack” something you’ve championed to the public.
It’s more of a problem of people still selling software not services.
It’s not always possible to sell a service in addition to the software (eg: games).
“Re-distribution is only allowed to others in the community.”
That makes it propritary, more like the shared source system which OpenVMS uses. Except that instead of: customer -> company -> customers it’s customer -> customers and/or customer -> company -> customers. So yes, when compared to such and even less free propritary systems it’s progressive.
However it fundamentaly different than FLOSS because with that anyone can contribute code, and anyone may distribute it to anyone. The possible community is much larger, and the openness is so too. In this project this is all only possible for a selective few; those who paid for it. Only those can learn from it, develop futher, use it. That makes it hardly an open model — imo.
Stating it’s impossible to do this with GPL or GPL-like is simply untrue because Compiere proofs it is possible and in addition the advogato link i provided shows an in-dept view of how one arranged the software he develops free as-is.
“It’s somewhat simplistic to view services as only installation/service contracts (which seems to be what you are implying). As bandwidth gets cheaper there’s no reason why a majority of the software we use today can’t be migrated to some sort of service oriented architecture.”
We do offer our software in a fully hosted “software as service”, or ASP model. If you’re saying that we should also empower our competition to offer the same service with our software, then we clearly have a difference of opinion.
Dark Horse
“””It’s not always possible to sell a service in addition to the software (eg: games).”””
Isn’t that the point of X-box live, or whatever it’s called?
“””We do offer our software in a fully hosted “software as service”, or ASP model. If you’re saying that we should also empower our competition to offer the same service with our software, then we clearly have a difference of opinion.”””
I never suggested that. However if you have to modify software existing OSS to enable your infrastructure, it’s to your advantage to contribute that back to the community, in exchange for wanted features you become free from maintaining it (specifically maintaining compatability for future versions).
“However if you have to modify software existing OSS to enable your infrastructure, it’s to your advantage to contribute that back to the community, in exchange for wanted features you become free from maintaining it (specifically maintaining compatability for future versions).”
We would certainly agree with that. We are very careful to honor the licenses of all the software we use as infrastructure. But we have not modified Tomcat, PostgreSQL, or the one or two other pieces of code we use as infrastructure. We have modified some utility stuff (though not much, and for the reason you mention), and we contribute that back. Our customers count on and deserve that we follow OSI licenses to the letter, and they could easily figure it out if we didn’t. They see the same source code we do.
Isn’t that the point of X-box live, or whatever it’s called?
It is, however:
Not every game on the market is an Xbox live game (ie: for many there’s simply no service to sell).
Not every customer is interested in the “service” of on-line play. (I, for example, have very little interest in playing on-line against other people with the current levels of technology)
In the market of non-online-multiplayer games, there’s no service to sell, there’s just the game. Such games currently make up the majority of the market. In some years they may not make up the majority, but they will certainly remain a significant proportion.
It’s all very easy to blithely wave your hands in the air and say “sell the service, not the software”, but that’s completely ignoring a) software for which there is no “service” to sell and b) scenarios where the only service that could be sold is practically valueless (eg: software support to home users who can get it elsewhere for free).
It’s really, really, really hard to see any profitable business model in selling open source (particularly GPL) software (with or without services) by anyone who isn’t a big player (like IBM) targeting medium to large to enterprise businesses or someone who is lucky enough to have found a services niche and monopolise their market. Redhat are really only starting to get by and projects like Whitebox Linux – not to mention anti-Redhat zealots – are a very real threat to their ability to stay in business.
This is before we even get into the simple fact a lot of people “into” OSS are only there to get stuff for free – so as soon as someone tries to start charging for something, a myriad of projects spring up to duplicate their product (thus devaluing it) and people start carrying on in messagegroups and other places about switching away from product X, never buying it again, the company sucks, etc (eg: Redhat’s move to focus on their RHEL products).
It’s easy for someone like Redhat (or Sun, or Microsoft) to sell me a “service” in the context of my job (sysadmin) – there’s significant value in well-defined product lifetimes and guaranteed support from the perspective of business IT. It’s practically impossible for them to sell me a “service” in the context of my non-professional usage, as the “services” they’re trying to sell have practically no value (let alone AU$700 per year) to me as a home user.
The problem you are describing is that experience by a plathora of
industries in today’s economy. Bascially, digital reproduction has
thrown a kink into the great order of things; specifically capital
needed to produce something has dropped significantly. It doesn’t
take a whole lot of capital to develop software. There is a fixed
cost associated with the equipment and the manpower, but the marginal
costs for the system are negligible (ignoring marketing and some other
expenses). Now since there is nothing special about the resources
required the entry barrier to the market is only the acceptance of the
market itself of a given product. Given this the market of software
will become dilute (as we are seeing with OSS to some extent and as it
gets more polished/refined/featureful/whatever your guage of utility,
the more dilute the market gets).
Now given this, the primary market for generic software will die with
due time. However, this isn’t a bad effect, it doesn’t mean coders
won’t be needed, and it doesn’t mean that software will cease to be
useful. This is where the traditional “hand-waving” as you put comes
in. It’s time to move to secondary markets. Once upon a time,
litaracy was considered a profession now it’s not. We still need
people who provide a service even if everyone can write (e.g. I can’t
really read legal documents). This is what everyone means. For
games, since they in general have limited utility they will probably
be restricted to media (like consoles), for most other applications
they /will/ be moved to services. There is a huge market
for turnkey solutions (like webhosting, data archiving, email,
whatever). Does this prevent me from setting up an email/webhosting server using
whatever system? No, however there is a question of maintenance,
setup, experience, knowledge base in doing so. That is what you are
selling. Is it worth the time for everyone to do this? Probably not.
Is it worth 5$ a year? Maybe. The next evolution is a race of
features, largely it isn’t worth it to solely internalize the costs of
software.
Now you keep pointing out there isn’t money in selling OSS
software (e.g. pick any distribution in all likelyhood). Exactly!
It’s not really a service they’re selling software (still). Now other
companies offering serverspace (running some OSS packages) for
whatever purpose will likely make money. Why is that? It brings back
the need for capital investment. Amazingly this market isn’t dilute,
and features over the competition (like the ability to install
software on a virtualized system) will give you a leg up. Now, this
doesn’t prevent a company from never releasing something back (but as
mentioned in the response to the darkhorse guy) there is benefits of
not having to maintain software once it’s released (assumption being
it’s popular).
Gee, just what the world needs – another acronym. “CRM”? Start speaking comprehensible English and then we can debate the validity of your ideas.