Developer

License questions

1) Can I include and distribute Report Manager in my commercial product?
This is not a problem, the MPL allow linking/using with comercial products.

2) Where do you draw the line about what enhacements of the engine must be MPL and what are not required to be MPL?

The line is drawn by the license, you will see the concept "larger work", I think it's impossible to define this line exactly, this are things where a judge is needed, by examinig the license and the use of it, if a conflict appear.
Usually a conflict appear because the main autor gets angry because someone have used the engine in ways not permitted by the license. For example if you get the engine as it's now and sell it with a license fee model, omiting the license and the autor of the software.

Next question will explain a few cases so you can understand the concept better.

3) Some of the changes that I need to make involves 3rd party libraries

Report Manager allow the use of third party commercial librarys, no problem, consider three cases:
1- A commercial DBExpress database driver.
Obviously it's linked with Report Manager, but there are a lot of reasons that probes it's not a Report Manager enhacement:
a) It also works with other software
b) It's not designed exclusively to work with Report Manager
c) Does not enhace the report engine itself but just a capability of handling another database technology.

2- A export filter to csv output (no need because already done inside the engine)
a) It's designed to work only with Report Manager.
b) It enhaces the engine capabilities.
c) It's not a program that works without Report Manager.

3- Another export filter to pdf (not the one already implemented) using a super pdf component with lot of features available for Delphi X and installable on the Delphi component palete.
a) It's designed to work with any software written in Delphi
b) It enhaces the engine capabilities
c) It's a component that works with Report Manager

Case 1:
- You don't need to provide the dbexpress driver as MPL.
Case 2:
- You should provide the output filter within the MPL license.
Case 3:
- You do not need to provide the PDF export component as MPL, but may be good and reasonable you provide the interface from Report Manager to the PDF component. So anyone that purchased that component can use it in Report Manager, that is because you enhaced the engine a bit by allowing the use of that component, but I think it's not clearly mandatory.


4) I need scripting capabilities (I will use XXXXScript)

Scripting is limited in Report Manager, but the best way is to program an enhacement or interface to allow Report Manager work with any scripting engine (Ruby,Python,Passcript). The interface should be MPL, while scripting libraries can have other license.

5) I need to save report templates in XML or other format.

The export to XML should be MPL but it's not required because can be programmed as an idependent program called as reptoxml for example, so it's considered a external tool, but will benefit you to be inside Report Manager (new properties etc).


6) Do I need to make these enhancements available? Who decides?

You decide about this, but you must consider the MPL license, a small enhacement very dependent on Report Manager is clearly candidate as MPL license, larger works is a case by case.
Anyway because you benefit from enhacements provided by MPL license by other developers you should provide enhacements in MPL unless:
- The release of the feature will low your sales, or will produce you any loss. Usually the contrary because the feature is included in the engine forever and you don't worry about adding it in each update. Usually you will not loss sales unless you are selling an addon to the Reporting engine, so in this cases you should respect the MPL license and honestly decide.


7) Do I need to make all changes using {$IFDEF} ?

When you use products that other people not use, and you share same code base, the answer is yes, to not become a nightmare the IFDEFS are minimized, for example:

uses
{$IFDEF USEMYOWNCOMPONENT}
mycomponentunit,
{$ENDIF}

{$IFDEF USEMYOWNCOMPONENT}
CreateMyComponent;
UseMyComponent;
{$ENDIF}

This allows you a single codebase for the shared code, note that you will benefit about this model also used by other developers adding his own features.

Of course, if the feature is completely MPL and included in codebase no IFDEFS are needed.

8) I don't want to make it public that I am using MPL Source when I distribute my application in binary format. Some customers may get the impression that I am selling them something which should be free.

The license don't force you to place any message about the author in your software. You can remove any about box annonying you, there is already an option to do it.

I think it's ok to place at your license a message like:

- The reporting engine is based on Report Manager (http://reportman.sourceforge.net)

Don't know if omiting any reference violates de license but anyway is not very ethic, you have benefits using the software.
Let's explain to your customers that a product containing a free product can be a non-free product. This is specially true when your product is a large work, or simply with a diferent purpose. For example a product working on top of Linux can be priced, but you should say if asked that Linux is free software and have no redistribution limitations.

9) Can I download the code and maintain my own Report Manager version?

You can get all the code and begin your own branch of the engine, but this will cause you a lot of work when you want to add features on your branch that are on mine and viceversa. In opensource world, the branches are created when there is no other way to go, beacuse they consume resources (time).