Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I would like to know if it's allowed to distribuite a binary-only/non-LGPL'ed application together with a shared library (used by the application itself) in a single archive, where the original source code of that library is covered by the LGPL and has not been modified for the application use.
The reason is that the application can be compiled so that it searches for the library in the current directory ./ first, for example. This would make the binary-only application depending on a particular version of the lib almost identical to the same application with that library statically linked, although in the latter case you must license the resulting application under the terms of the LGPL.
Myapp/ -- the archive
myapp -- the binary-only application
otherlib.so -- the LGPL'ed library
$ cd Myapp
$ ./myapp
I think your proposed distribution is fine.
To comply with LGPL it must be possible for users of your application to drop their own version of otherlib.so and have your app run using this. Assuming this requirement only covers binary compatible changes, it sounds like the requirement is met in your case by a distribution containing only a binary version of your app.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have built a small program for plotting data from serial port using Qt and QCustomPlot. I am an engineering student, and I had a project that required me to manipulate data from the ADC of an mbed, so I built this app for my convenience and for experience. I would like to share it with other people who need such a tool (will put it on the mbed website).
I am not a programmer and I do not know a thing about licenses. The QCustomPlot is under GPL. I read that I cannot use static linkage with the GPL licence for QT; I do not intend to, (I will post the source too), but would like to include a statically built version of the program for people who would rather just use the program.
So without going in too much detail, what can I do? Also, do I need to include any disclaimers in my source?
First of all: choose a license for your software. The website http://choosealicense.com can help you in doing that.
Usually a license requires to add a text header to your source code files. This is just a fragment of text which shows the terms of the license right within the source code.
Also, a license.txt file is often required in which the full license has to be pasted. Anyway choosealicense.com clearly explains what to do.
Notice that some licenses (e.g. the GPL) need that a list of changes is added to your source code. This list has to be mantained through the entire life of your software distribution and updated when you provide new releases.
When you are ready with your package use a website like GitHub to distribute it as a source code.
Do not include binaries. Just add the source code and a README file in which you explain how to compile them.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I've written a Ruby gem that I've licensed under the MIT license, but I think I could greatly improve the test coverage by using an AGPL library in my specs. The actual library code I've written (that would be executed by people using the gem) would never use this AGPL library, it would just be for running the tests in a development environment when running the gem specs.
Is it legal for me to then license my spec code under AGPL while still licensing my library/application code under MIT? Is there anything special I would have to do with regard to my GitHub repository (e.g. a separate repo for the specs) or my .gemspec file (e.g. not bundling the specs and AGPL library with the gem)?
First of all, I am not a lawyer.
Let's assume that the library you're going to use is named L.
Since your application code is not a derivative work of L it is not affected by AGPL's licensing. Therefore you're free to choose rules under which it is distributed.
Your test code is a derivative work of L in the sense of AGPL and as a result if you publish it you have to use terms of AGPL.
Storing files with different licenses in a single repository is not an issue. What is important is to clearly and unambigously state what is the license of each file. The best idea is to put relevant notes both in files' headers and a README or LICENSE file. What I mean is something like
All files in the test directory are published under terms of (...). All remaining files are published under terms of (...) unless otherwise stated.
Remember to add this information in each form of distribution of your project, i.e. a gem file, a tarball and so on. If you have to specify terms under which your whole gem is published you have to provide both licenses. In the terms of a gemspec it would mean
spec.licenses = ['MIT', 'AGPL']
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I am looking at different types of linux to run a small web server on, however I have a question as I am a bit confused about how the GPL works. If I have PHP scripts that I created myself, etc...running on the linux server, do those automatically become part of the GPL, or are those still mine to do with as I please? How about if I need to make a copy of the system, as is, by making a disk image, to install it on another computer of mine? Does that mean that all my work would become part of the GPL?
First of all it is very likely that your Linux system will run Apache, which is not licensed under terms of GPL, but Apache license. Apache itself does not run PHP scripts. In fact lots of functionality is provided by third-party modules and this applies to PHP too, which is handled by mod_php. Those modules are allowed to be distributed under their own licenses. And PHP utilizes this being distributed under terms of PHP license. PHP license is not permissive (or not copyleft), which means that you may distribute your scripts under any license you wish, with very little restrictions like including in your product a statement:
This product includes PHP software, freely available from <http://www.php.net/software/>
So basically no, your software will not become a part of GPL in any way.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I have found a bug in an LGPL Lib that I currently link against dynamically.
The application is closed source
I link dynamically to the LGPL Lib
The application will be available to the public
If I modify the lib my understanding is that I will have to make the changed source files availible with the application, is this correct?
You are redistributing the modified code of the LGPL library, so you need to release the source for that library (your bug fix). That does not mean you need to release the source code for your entire application, just the library that's LGPL'ed.
Also note that the GPL/LGPL only requires you to give the source code to someone that you give the binary to. It does not require you to e.g. put the source on the web for anyone in the world to download. A sure way to comply is to pack the source inside your distribution so people get it together with the binaries, then nobody can ever complain that the source wasn't available.
Another solution (although it may not always be possible) is to derive your own subclasses from the LGPL'ed library and make the necessary fixes there. Of course a better approach is to submit the fix to the maintainers of the library, but if you need to ship your code soon, this may be something to consider. By deriving stuff, you're not violating the LGPL.
From the License:
An “Application” is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I have a commercial Java application which I will be distributing.
I want to use an LGPL'd java library.
I wont be modifying the library.
Does the LGPL license of that library have any impact on my application's license?
Yes, it does to a certain degree. You are e.g required to allow people to upgrade the LGPL'd library without your help. I suggest reading through the whole license yourself, as you're legally obligated to adhere to it's clauses. Know what you oblige yourself to, don't just take other people's words for it :)
As far as I understand the LGPL, no, you can distribute it however you like. You will only be linking to the library, not creating a derivative work, and the LGPL doesn't restrict linking.
There is no impact on your application. LGPL license allows inclusion in commercial application as long as the terms of the license are fulfilled (LGPL license text in the distribution, indication of the use of the library, etc).
My guess is that as long as your linking is dynamic (i.e. dynamic loading of the .dll/.so/.a/.class/whatever file at runtime), you're OK. If you statically compile your code to include the library, you're at risk of violating the license, depending on how your code is structured.
If it's Java, however, you can not link statically - it's an impossibility of the platform.