DXL Standard Library - License

Mathias Mamsch - Tue May 25 05:26:42 EDT 2010
Hey Steve,

after contacting the FSF (Free Software Foundation), I can say that at least it seems no problem to them to release the library under the GPL. That far that good.

The fact that inspired me to create this library was, that to whatever client I get to in my DOORS consultancy job, they all face the same problems with DXL and they all spend a lot of money to solve them. Companies like Telelogic were deliberately NOT giving the users the possibility to get their work done, so they could sell their products. Taking the XML library as an example, this means that there should be a lot of different XML libraries out there and you would expect that people would share, but this does not happen. In this forum you read posts like "I have the code you are looking for, but sorry it is to valuable to share". I am convinced that once this library reaches its critical mass that it can break this pattern.

Creating an XML module exporter would be a great contribution for the whole DXL community - and someone will do this sooner or later and add it to the standard library. The opportunity I see here, Steve, is that we can define a standard XML export format for DOORS modules and create an exporter for this format under the GPL. The community can help you with implementing, testing, maintaining and improving this XML exporter. You can create a non-free software that uses the XML files and invokes the DXL exporter to transform them into PDF or whatever is on your mind and sell licenses for it, as long as you keep the applications clearly separated. It is a give and take.

I offer you the following: I will add a tools directory to the library (was planned for later). I will adapt the environment so that any tool in the library can be invoked seamlessly from a third party application. You convice your project leader that outsourcing the XML module export part to the community will save money in development, maintenance and improvement (e.g. export speed!). Or you can choose to implement your own version of an XML export - keep in mind though that a free XML export will come anyways - so your product will be measured by that standard.

After thinking thoroughly about the licensing I think releasing the DXL standard library under the LGPL or some less restrictive license will not accomplish the initial goal, since other companies will use it without giving back to the community.

I hope we can make "a deal" here and you guys think about outsourcing the XML export part.

Regards, Mathias

SteveCooper - Tue May 25 08:19:30 EDT 2010

Hi, Mathias.

I think your goal is excellent; if there were a standard XML import / export format available for DOORS, I'd definitely want to use it, and would be happy to contribute changes if I had any to make. Much of the work I have to do now would already be done. Also, I have to say that this is your code and your project, and you have the right to license it how you wish. It looks to me like really well engineered, well-documented code, and I'm grateful you are releasing it to the public.

GPL causes problems when charging customers. Neither you nor I can use DXLSTDLIB without giving away our rights. If you have done some work in your DOORS consultancy business, and sold a script that #includes a DXLSTDLIB file, then your customer can distribute that script around their organization for free, post it on the Internet, and charge other people for copies. The same thing for me; I can't use your strings::trimWhitespace() function in my project, because that stops me selling software licenses. This approach might be fine for your projects, but I can't use it for mine.

I imagine it is too limiting for lots of other folks. Let's say a developer out there has their own library; CUSTLIB.DXL. If they write this script;
 

#INCLUDE <CUSTLIB.DXL>
#INCLUDE <XMLDOCUMENT.INC>
 
// some code using both

Then they are obliged to release CUSTLIB.DXL as GPLv3. I think that is going to make a lot of people avoid using DXLSTDLIB at all.

I think, actually, that it may be useful to talk about two different projects;

• DXLSTDLIB, analogous to C's STDLIB, describes low-level library functions which are useful for almost all programs.
• XML Import/Export, an application which links to DXLSTDLIB and which is focused on importing and exporting a specific DOORS XML dialect.

It would be possible to license these separately. For instance, you could put DXLSTDLIB under a multi-license of Modified BSD license and GPLv3, and put the XML Import/Export under full GPLv3. This page lists the licenses compatible with GPLv3. It is worth noting that this is how GNU do things; the GNU version of STLIB is LGPL, not GPL. That means people can write C programs which

#include <stdlib.h>

without making all their C programs open-source.

This approach would support your goal of creating a GPL XML importer and exporter, and it encourages the widespread use of the DXLSTDLIB library, which may help improve code quality and contributions. Certainly, if I were using the DXLSTDLIB library and found a bug that I could fix, I'd post the patch back to you.

Anyway, again, this is your work and you can license it how you want. Thanks for releasing your hard work.

Steve.

Mathias Mamsch - Tue May 25 10:38:34 EDT 2010

Hey Steve,

with most of the things you said you are right. The idea of free software conflicts with selling licenses for software. I need to think about the idea of allowing the DXL Standard Library to be bundled with non-free software for the sake of developers who do not want to give away their rights for their own code.

You did not comment on the possibility of two separate applications for your exporter project:
One XML exporter which will put DOORS Modules (or whatever to DXL) which is released under the GPL and will be created by the community and you. The second application is your own non-free, binary only, XML transformation engine, for which you will sell software licenses to your customers. The XML transformation engine calls the GPL XML exporter over a DXL interface, which is not a violation of the GPL, since these are two separate applications.

So the XML Exporter could provide an API like this:
 

// ModuleExportAPI.inc
#include <lib/dxlstdlib.inc>
// this is the good stuff: 
#include <lib/ModuleExport.inc> // includes XMLDocument.inc
 
exportModuleToXML (modToBeExported, strFilename)

Your own application could then do something like this:

Module modToBeExported = read ("/Project/Folder/ExportModule", false) 
     string strFilename     = "C:\\myfile.xml"
     #include <tools/ModuleExportAPI.inc>

which is nothing else than a batch call from DXL (in fact you could also make a DOS batch call). There is a clear separation between the two standalone applications. You would be able to sell licenses for your application and not put it under GPL, you could benefit a lot from the knowledge of the community in the development of the module export (I am sure there are quite some people who would like to help), we could maintain, test and improve the XML Exporter application together with you and we could define an XML export standard for DOORS modules.

Please comment on this solution. See, what I don't want it that one company uses the XML library, create an exporter from it, sells it to some customers, then another company takes it, creates a little different exporter from it, sells it to some more customers and in the end there are 1000 customers who each paid someone to develop an XML export, where a comparable small shared effort of some of the customers would have been enough.

Note, this does not mean that the license question is answered for me. I will think about the fact, that I might not be able to convice enough people of the "free software" idea, which forces them to give up the rights to their code. For the normal consultancy business (that I do) that is usually fine, since you only charge your customer once - whatever he wants to do with the code is up to him.

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

SystemAdmin - Wed May 26 03:08:08 EDT 2010
The idea of free software conflicts with selling licenses for software.

Not at all, at least not from the copyright holders' perspective. Google a bit on "Dual licensing". This is the licensing model MySQL used to go from a 2-person startup to a $1B sell-off in less than 15 years.

Mathias Mamsch - Wed May 26 05:56:38 EDT 2010
Hmmm ... never thought about that one ... thats a nice idea. Thanks for the hint! Regards, Mathias

GerhardS - Mon Nov 22 10:07:25 EST 2010
Mathias,

first of all: thanks for the great code. However, while following this discussion, it's not completely clear to me, what I can do with it, and what I can't.

I'm currently imagining two situations:

(1) Developing a product, which might be sold to any customer who is interested in. I understood, that I cannot use your library for this purpose, except physically separating the relevant program parts.

(2) Developing a customer-specific solution, which might use the library as a small part of a big picture, while leaving it unmodified, including the file headers. According to company-specific conventions, the file name and the formatting may change, and there may be additions to the file header. The complete solution would be property of the customer, who would use it internally, and who would not sell it to others.

I'm now wondering, if (2) is possible with your license. And if not, which constraints must be fulfilled to make it possible.

Regards,
Gerhard