2

I like the GPL. I like that it keeps FOSS free and open. I like that if my software is re-distributed, users know where to file bug reports, buy feature requests, and know where it came from.

Corporations who develop proprietary software often loathe the GPL because of its "contaminating" nature. They may have legitimate and necessary reasons to keep their software proprietary (export control, data license agreements).

I'm developing a simulation engine and development framework. I anticipate corporations to use my software and architecture to develop and run dynamically loaded proprietary models. I need a license which:

  1. Preserves the FOSS nature of my application
  2. Explicitly allows development using my application framework (static, or dynamic linking against my -dev libraries) in proprietary models.

Could I release the development libraries under MIT and the application under GPL? Any incompatibilities?

It's easy to argue that extensions are "covered works", or "works based on the program", so if any ambiguities exist, my application will be less attractive. Is it reasonable to release my own version of the GPL with an alternative definition of "covered works"?

  • 3
    Would the LGPL license perhaps be appropriate? GPL-style copyleft for the core itself, but no substantial restrictions for software that links with the core, such as plugins. – amon May 25 at 21:00
  • 2
    Would your framework be used to create software that the corporations want to sell/distribute or would it be software for internal use within the corporation? – Bart van Ingen Schenau May 26 at 14:34
  • I know from my experience that the LGPL is still pretty restrictive. I've often been told by lawyers to avoid it when selecting libraries. There's the general understanding that static-linking is a no-no for LGPL in propietary software, so I think staying away from this one is smart. The framework would be used to create proprietary dynamic libraries as "plugins" or "extensions" that would be sold/distributed. – Stewart May 26 at 17:49
  • 1
    @Stewart this is why you need lawyers who are trained in this field: all lawyers are no more equal than doctors, and we don't (generally) let proctologists do open-heart surgery. LGPLv3 s4d0 makes clear reference to your obligations in the case that you distribute a binary with an LGPL library statically linked into it, so there cannot be any kind of "no-no" with respect to LGPL in this regard. – MadHatter May 27 at 7:02
3

It's easy to argue that extensions are "covered works", or "works based on the program", so if any ambiguities exist, my application will be less attractive. Is it reasonable to release my own version of the GPL with an alternative definition of "covered works"?

No, do not do that. There are already too many open-source license as we speak and adding another one that is deceptively similar but different from a widely used license will only make it worse. Moreover, I expect that the legal departments of those corporations you want as your users will block the usage of your software until they have studied the license text for a few years to be sure there are no hidden surprises in there.

Could I release the development libraries under MIT and the application under GPL? Any incompatibilities?

That is not going to help you. From the GPL FAQ:

If I write a plug-in to use with a GPL-covered program, what requirements does that impose on the licenses I can use for distributing my plug-in? (#GPLAndPlugins)

Please see this question for determining when plug-ins and a main program are considered a single combined program and when they are considered separate work..

If the main program and the plugins are a single combined program then this means you must license the plug-in under the GPL or a GPL-compatible free software license and distribute it with source code in a GPL-compliant way. A main program that is separate from its plug-ins makes no requirements for the plug-ins.

When is a program and its plug-ins considered a single combined program? (#GPLPlugins)

It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.

If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.

If your application does not have any dependencies that are under the GPL license, then you do have the option of using the GPL license with an additional permission. For example, you could give a permission like this

"As an additional permission, plugins for <application> may be distributed under the terms of their author's choice without being bound by the requirements of the license of <application>. This permission does not extend to changes made to <application> itself or its development libraries."

| improve this answer | |
  • For me, this is the right way forward for the OP: stock GPL on the core, with an additional permission to distribute with closed-source plugins. – MadHatter May 29 at 10:36
1

I'm developing a simulation engine and development framework.

Most operating systems (e.g. Linux, Windows, ...) and language implementations provide a way to accept plugins. On Linux with C code that means using dlopen(3).

A good example is the recent GCC compiler, or the Firefox browser.

You could implement a plugin mechanism in your simulation engine.

The license of your simulation engine might not be related to the one of proprietary plugins loaded by it.

Alternatively, you could embed some interpreter in your application.

E.g. Lua, or Guile, or Python, or your own interpreter (perhaps using just-in-time compilation techniques). Read the Dragon book then Programming language pragmatics and SICP before designing then implementing your own interpreted language. Read also the Garbage Collection Handbook.

but I am not a lawyer, and you probably need one

Is it reasonable to release my own version of the GPL

Certainly not: in most large corporations, developers are allowed to use open source components only with a specific set of licenses (defined by in-house lawyers). And writing a software license requires legal expertise. Choose (with your client) some existing open source licenses.

I anticipate corporations to use my software and architecture to develop and run dynamically loaded proprietary models.

This could be an optimistic view. Lots of open source software have almost no users. You might want to read the simple economics of open source paper. You should at least put a lot of efforts on proper documentation.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.