10

I'd like some help/advice regarding a problem I'm facing with licensing options.

I'm currently writing software for an open hardware project that uses cameras from various brands. I'd like (very much) that my program be released under a GPLv3 license but this is likely incompatible with most camera SDK licenses.

I'm not asking if I can embed those private libraries into my GPL program because I know I can't (even that thing under Section 7 is not really applicable because that would prevent me from using any third-party GPL lib after). What I'm asking is:

  1. If my GPL program accepts a feed from a named pipe (or networking or whatever) and I create another program, with a more permissive license compatible with the camera SDK licenses, that uses the SDK and feed the named pipe with the data; is this ok under the terms of the GPL?

  2. Assuming 1 holds, can I distribute both programs together (I feel like it's going to be a big no) or should I distribute them separately?

I know trying to find loopholes is bad but I'd really love to have the SW be under GPL as the hardware is already under OHL v2 (which has very similar philosophy). One option would be to use OHL-W version for the software but that closes a lot of doors after and I'm not sure the OHL thing was even done thinking about computer SW...

Big thanks in advance for your insights. I'd also be interested for other solutions if anybody can think of one (like generic camera driver under GPL -- but I don't think it exists).

Improve this question
3
  • Where would your GPLv3 program run? On a PC?
    – ruben2020
    Mar 10 at 6:40
  • 2
    Generally, it's perfectly fine to distribute GPL and non-GPL software. What's not allowed is preventing your users from getting access to the source code of the GPL software. For example, Apple bundles GPL software with OSX (eg. bash). In such cases they are required to allow you to access the source code of the GPL software. However they are free to restrict access to the source of proprietary parts of their OS (surprisingly a lot of OSX is actually not proprietary, the kernel for example is open source)
    – slebetman
    Mar 10 at 7:12
  • 1
    Does your program totally need the GPL thing to work? Is it broken without the GPL part? If it is, then your scenario is not acceptable. If you had an abstraction layer, where you could use the GPL software, and at least one other input implementation, a strong argument could be made that you are simply compatible with the GPL thing.
    – doug65536
    Mar 11 at 2:22

3 Answers 3

Reset to default
13

The communication method you use is irrelevant; the question is whether your work forms a derivative work of the libraries. Quoting from the GPL FAQ: What is the difference between an “aggregate” and other kinds of “modified versions”?

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

There is no "bright line" here which absolutely determines if something is a derivative work or not - and this could be something courts in different jurisdictions rule differently on.

Improve this answer
3
  • 13
    If the GPL application accepts the video feeds in a format that is publicly documented and not invented specifically for this application, then I find it very unlikely that this communication would be regarded as intimate and a basis for considering it as a single work under copyright law.
    – Bart van Ingen Schenau
    Mar 10 at 8:04
  • Right, the law does not work like a computer program, saying "if (X) then {derivative_work = true;}` - your program is a derivative work if it's a derivative work.
    – user253751
    Mar 10 at 18:31
  • Just as an example, US courts have used the rather unwieldy abstraction-filtration-comparison test to determine whether program X is a derivative work of program Y. It is a decidedly complicated inquiry. Frankly, it's really not compatible with the commonly-held belief that "if X and Y share an address space, then one must be a derivative work of the other."
    – Kevin
    Apr 7 at 2:40
5

The spirit of GPL is not to prevent you from writing open-source software which relies on someone else's closed-source software to perform its function. What GPL is trying to prevent is that you take someone else's GPL-licensed software, adapt it to work with your closed-source part, and get away with distributing the combined work without publishing your part of the source code.

Your GPL-licensed part can absolutely rely on existing closed-source code, pretty much like Cygwin relies on Win32 API. This doesn't give Cygwin users a claim to receive the Windows source code, nor does GPL forbid the distribution of Cygwin itself.

What GPL forbids is that someone designs a closed-source camera software that is only usable with a certain frontend that contains GPL-licensed code. This becomes especially important if the GPL-licensed code is not written by the same person as the closed-source part, so that the problem cannot be fixed by relicensing the GPL code under a different license, and the closed-source part must be released under GPL instead.

Of course, this answer is not actual legal advice.

Improve this answer
2
  • BTW: if you want to make GPL software that relies on non-GPL software it's best to write a license exception that says you don't have to distribute the non-GPL software as GPL - there are many templates you can use for this
    – user253751
    Mar 10 at 18:32
  • 1
    However, the OP has explicitly ruled out including a license exception because they want to use other GPL code.
    – Philip Kendall
    Mar 10 at 19:22
4

It would be great if there exists at least one camera SDK that is compatible with GPL. Then you could make available a fully free distribution of the software, which is able to work with that specific camera. It would contain the GPL main program and a reference implementation of camera component, including a documented method of how they communicate.

Then you can provide alternative implementations for the camera interface component, based on proprietary SDKs.

The main advantages:

  • It is possible to use and develop the project without dependence on any proprietary SDK. It also works as a reference implementation, to which the other components can be compared when debugging.
  • The free distribution being able to operate by itself is a very strong argument in favor of it not being a derivative work of any proprietary library.

It may make sense to publish the camera communication reference implementation under a GPL-compatible non-copyleft license, such as MIT or BSD. This makes it usable as the base for proprietary implementations

Improve this answer
2
  • 1
    This is an interresting proposal. Do you think the following would work ? Create a short communication SDK under MPL license with a generic DLL driver that import files from bitmap; then implement this as the base solution in the GPL software and then provide extra DLLs under the license of both MPL and camera SDK ?
    – Luc
    Mar 12 at 13:40
  • 1
    @Luc DLLs are often considered a more "intimate" link between the programs, than e.g. network connections. But this is a very fuzzy line. The GPL FAQ entry on gnu.org/licenses/gpl-faq.html#GPLPlugins plugins may help some, but in the end it is pretty unclear.
    – jpa
    Mar 12 at 14:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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