Licensing Advice when wrapping GPL software

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Licensing Advice when wrapping GPL software

Nathan Smith
Hi Folks, 

I'd like some advice on my first package. I'm building a package to interact with Maxima (similar in spirit to RCall.jl etc..). Maxima is under the GPL license so my question is this: Does this mean my package must also be GPL licensed? Do I have to supply the Maxima source code to respect Maxima's license in my package?

Building Maxima.jl has been a great experience, I'd just like to cover my bases before I start sharing my package broadly. Any advice would be greatly appreciated!

The package is here if anyone is interested :)

Best, 
Nathan


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Licensing Advice when wrapping GPL software

Stefan Karpinski
In short, no. If your package merely interacts with Maxima and is not derived from Maxima, then it can have its own license, which is entirely independent of Maxima's license. So if you're not copying code from Maxima, then it can be MIT or whatever you like. The combined product of Julia + your package + Maxima is a little more complicated and it depends on whether the result constitutes a single "derived work" or not, but you would not be distributing that, so you're not bound to the terms of that combination. In order for the combination to be unambiguously usable and distributable, you'll want to pick a GPL-compatible license for Maxima.jl – e.g. MIT, BSD or GPL. If you start distributing the combination, then you're bound to the terms of the GPL for Maxima, but you would be anyway since you'd be distributing Maxima then.

Cool package :)

On Fri, Aug 19, 2016 at 9:51 AM, Nathan Smith <[hidden email]> wrote:
Hi Folks, 

I'd like some advice on my first package. I'm building a package to interact with Maxima (similar in spirit to RCall.jl etc..). Maxima is under the GPL license so my question is this: Does this mean my package must also be GPL licensed? Do I have to supply the Maxima source code to respect Maxima's license in my package?

Building Maxima.jl has been a great experience, I'd just like to cover my bases before I start sharing my package broadly. Any advice would be greatly appreciated!

The package is here if anyone is interested :)

Best, 
Nathan



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Licensing Advice when wrapping GPL software

Nathan Smith
Ok great, thanks for clarifying! So if I choose to add binary support through something like BinDeps I should be choosing something GPL-compatible right?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Licensing Advice when wrapping GPL software

Tony Kelman
Yes that would be the least risky. It would also be a useful courtesy to users to note clearly the fact that the package wraps and downloads GPL-licensed software upon installation.


On Friday, August 19, 2016 at 8:11:54 AM UTC-7, Nathan Smith wrote:
Ok great, thanks for clarifying! So if I choose to add binary support through something like BinDeps I should be choosing something GPL-compatible right?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Licensing Advice when wrapping GPL software

Steven G. Johnson
In reply to this post by Stefan Karpinski


On Friday, August 19, 2016 at 10:02:43 AM UTC-4, Stefan Karpinski wrote:
In short, no. If your package merely interacts with Maxima and is not derived from Maxima, then it can have its own license,

To clarify, according to the FSF's legal counsel, if you interact with a program that is forked into a separate address space, then its license can be chosen independently of yours.  However, if you link dynamically to a library and share data structures with it, then you are a derived work of that library and are constrained by its license.

(For example, PyCall invokes Python by linking dynamically to libpython and sharing data structures with it, so we are constrained by Python's license.  However, since the CPython license is a permissive BSD-like license, it's not really a constraint.)

Ultimately, these questions of when something counts legally as a "derived work" of something else (and hence is constrained by its license) cannot be resolved except by a court, because they are determined by copyright law and not by the license itself.  But the FSF's interpretation of the GPL seems to have held up over many years, and hence is a good standard to follow.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Licensing Advice when wrapping GPL software

Nathan Smith
Ok, for concreteness sake, the way Maxima.jl works is that it spawns maxima on a seperate process and communication happens over a TCP socket. So it seems from the FSF's interpretation I'm free to choose my license, though something GPL-compatible is probably the safest choice. 

Thanks for your help everyone! I'll be sure to report back when I finish a stable release :) 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Licensing Advice when wrapping GPL software

Jeffrey Sarnoff
For use with Julia, the MIT License is best when one has the choice.

On Friday, August 19, 2016 at 4:25:31 PM UTC-4, Nathan Smith wrote:
Ok, for concreteness sake, the way Maxima.jl works is that it spawns maxima on a seperate process and communication happens over a TCP socket. So it seems from the FSF's interpretation I'm free to choose my license, though something GPL-compatible is probably the safest choice. 

Thanks for your help everyone! I'll be sure to report back when I finish a stable release :) 

Loading...