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 been extracting 3rd-party library JARs into my open source Java library in order for the dependencies to work at runtime.
I remember when I tried doing this in Eclipse a while ago (different project) it produced a warning to check licensing before doing this.
What exactly are the general rules regarding when it's ok to repackage library contents into your JAR, how it should be done, and which widely used licenses forbid it?
Specifically, the libraries I'm repackaging use BSD and LGPL.
Thanks in advance for your help.
Edit
I actually ended up separating out the dependencies to prevent code conflicts as several commenters suggested. Thanks again for the suggestions and information provided.
What I personally do is make sure that none of the library I use explicitly forbid redistribution. If they do, you're out of luck. Neither BSD nor LGPL do though, so you should be ok. I can't think of a sane open source license that would.
Once you're satisfied you're not violating the terms of the license by repackaging and distributing them, you need to make sure you respect them in other aspects. I find that the following steps are sufficient for 99.99% of the open source licenses out there:
create a license.txt file at the root of your JAR file (some people put it in META-INF, but I know of no rule or convention on this and think it's just a matter of preference).
list all of the external libraries you import and the license under which they are distributed in license.txt.
write the complete text of all licenses that apply in license.txt.
ideally, link to each library's web site, download page and license page if available.
This should make sure you don't run afoul of any mainstream license, to the exception of the GPL. I'm not a lawyer, nor am I an expert in the GPL, and any advice I give you on how to respect it might end up entirely wrong, so I'd rather not lead you astray.
There are a few more things you can do, but those are more a matter of professional courtesy:
if you're writing a user facing application (webservice, UI application...), link to the libraries you're using in the About section.
let the maintainer of the library know that you're using and packaging it - some authors like to maintain a list of popular software using their tools.
While that might sound like a lot of work, it's far less work than writing and maintaining the actual library.
EDIT: I just realised that you were working on a library, as opposed to an application. My answer doesn't actually apply in that case: it's very poor form to package your dependencies in your library's JAR. If anything, it makes it rather harder for third-party developers to integrate your library with existing build tools and dependency management systems (maven, ant / ivy...).
If you want to keep things simple, just include the JAR of all your dependencies in the /lib folder of your distribution files.
To re-iterate my point: I believe you'll alienate the majority of developers by packaging your dependencies in your library's JAR file rather than with it. I certainly would file a bug report and look for alternatives if the issue wasn't addressed.
That's pretty ease to achieve with maven. Convert you project to a maven project which will make your life much easier and use the maven-assembly-plugin with descriptorRefs as jar-with-dependencies(a predefined assembly structure). You can create your own if you like so maven packages your code however you like.
Example of maven-assembly-plugin configuration:
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4</version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id> <!-- this is used for inheritance merges -->
<phase>package</phase> <!-- bind to the packaging phase -->
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
[...]
</project>
Related
I'm working on releasing a SDK package.
I don't want the developers who use my package to see any private elements when they add the jar to their eclipse projects.
I studied the android.jar. It just hides any private class/method/member.
How can I do like that?
thanks.
You might be looking for a way to obfuscate your code.
[...] Automated bytecode obfuscation makes reverse-engineering a program difficult and economically unfeasible. Other advantages could include helping to protect licensing mechanisms and unauthorized access, hiding vulnerabilities and shrinking the size of the executable.
Bytecode obfuscation - Owasp wiki
The wiki includes an example of using such a tool.
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'm developing an application with the Qt open source edition. As I don't want to deliver the Microsoft Visual Visual C(++) redistributables, I'd like to use a static-linked version of Qt.
The Qt licensing information says that I "should" develop with a commercial Qt license if I want to use static linking in my application, although when I use the configure -static command for building a static Qt library the command prompt asks me if I use the commercial or open source version of Qt.
So it is possible to build Qt with the open source version? Do I need the commercial edition to use static linking? I won't sell the application.
EDIT April 2016
Actually, I have recently been reading in depth about LGPL, and asking some experts on the subject. Turns out that the inability to use static linking for Qt in closed source applications is more of a cultivated legend and has nothing to do with reality.
What LGPL requires is the possibility for the end user to relink the application against a different version of the library. Using dynamic linking is one way to achieve that, but you can just as easily provide your object files, this way you don't have to open your source and the LGPL requirement is still satisfied.
On the Qt website there are 2 legal FAQs and in neither of them is it directly stated that you can't do it. Just as it is not stated that you can. However, there are at least several instances of implying a vague legal threat in case that you do. I think there is a good explanation for all of those - they can't say that you can't do it without publishing a practical lie which may as well have negative legal repercussions for them, and they are willing to discourage doing that rather than encourage it, as it has the potential to force more people into purchasing a commercial license.
So in short, yes you can, and you most definitely should as lately Qt has become a living deployment hell, plus as of Qt 5.7 in a static build, QML files are tucked neatly in the executable rather than being out on the file system, for anyone to tamper with. Just make sure that:
your Qt build only contains modules, licensed under LGPL, and nothing GPL
the about section of your app mentions that it is using Qt and contains a link to where you can download the application's object files
include all the respective license files with your application
Lastly, your application actually has to be "relinkable", that is, it must be able to work with a compatible library version that provides the necessary functionality. Which means that if you have made modifications to Qt before building it, you must provide those in the form of source code as well, but only the modifications to Qt, not your application's source code.
Update:
Here is an excerpt directly from the GNU FAQ:
For the purpose of complying with the LGPL (any extant version: v2,
v2.1 or v3):
(1) If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source)
format, so that a user has the opportunity to modify the library and
relink the application.
That states it pretty clear.
The old, original answer:
It is possible to build Qt statically as long as your application is open-source and you provide the source. If you want to keep your source closed, you either need an expensive commercial license, or you need to use dynamic linking.
BTW using a static build of Qt is pretty nice, for Qt5 I get about 7-8 MB executable with no external dependencies, which is much better than the 20+ MB of additional dll's you have to ship with a dynamically linked app.
For more information, you can take a look at this video: Making the correct license choice when developing with Qt
All in all, can it be done? 100% yes. Should it be done? It depends, for personal/testing/learning purposes it is 100% OK, however if you plan to distribute production grade software, be that commercially or not, open source or not, you'd better first consult with a lawyer. The whole subject is unnecessarily complicated, subject to interpretation, so that the consultation with a lawyer becomes more expensive than a pricey commercial license.
The answer is Yes, if you are willing to open source your application.
According to the Qt-Project's own interpretation of the licenses they use, if you dynamically link to the Qt libraries your application can be either closed source or open. If you statically link, however, your application is subject to the terms of the LGPL.
The exact language the Qt Project uses is this:
In case of dynamic linking, it is possible, but not mandatory, to keep
application source code proprietary as long as it is “work that uses
the library” - typically achieved via dynamic linking of the library.
In case of static linking of the library, the application itself may
no longer be “work that uses the library” and thus become subject to
LGPL. It is recommended to either link dynamically, or provide the
application source code to the user under LGPL.
(http://qt-project.org/legal.html)
The suggestion in some of the other answers that the situation is "not at all clear" is simply untrue - The Qt Project has tried to be abundantly clear about in what circumstances usage of the LGPL license is permissible, and static linking is one of those as long as the app is also LGPL.
Since the original question specifies non-commercial (not necessarily open source), the asker will need to decide whether they can allow distribution under the LGPL (or GPL by extension, as the above page also says "LGPL can be converted to GNU General Public License").
We've developed a commercial Qt application with Qt under LGPL. We link dynamically. We also made a few changes to a couple of files in Qt to better suit our needs. I realize that according to LGPL, I must make those changes publicly available.
My question is how is that done?
Do I set a webpage on my domain with the modified source codes available for download?
Do I distribute the modified source code in a folder on the client target machine after installation?
Another
way?
You simply have to make them available on request.
It can be a file on your web server, it could just be emailing them to anyone that asks, you can even supply them on floppy disk and make a charge for it.
Ideally you would also contribute the changes back to Qt if it's a bug fix or feature that could be useful to other people, then it may be incorporated in future editions and youcould then just use the standard build.
ps. The letter of the GPL says that you have to provide everything that is needed to create your modified build - so the full Qt sources and the build files. However for a large complex project like Qt, if you have only modified a couple of files it would be useful to offer a download of just these (or even a diff against the specific Qt version)
According to the licence you need to provide your changes back to the community, not just to your customer.
The easiest way is forking the main Qt repository on http://qt.gitorious.org/qt and commit your changes there.
I've been leading rather large project that strives to "Mavenize" various testing apps produced by the engineering tools group over past 5+ years to test and optimize our home-built database. So far our group managed to successfully retrofit (beside obvious Java) few Coldfusion-based apps, PHP app, large .NET app with about 30 modules and currently working on roughly 40 C/C++ apps. Actually, once you abstract yourself from Java-centric nature of Maven and throw in few useful plugins such as antrun, exec, assembler and resource you can pretty much figure out way of "Mavenizing" just about anything.
So my question is - are there people who had this sort of experience - using Maven to manage non-Java projects? What was it? What language/technology? What did you end up using? How? Were you successful? And if not - what did you end up using as alternative?
Conceptually, Maven is not Java centric but Java is monopolizing most efforts as written on Wikipedia:
Theoretically, [Maven's plugin-based architecture] would allow anyone to write plugins to interface with build tools (compilers, unit test tools, etc.) for any other language. In reality, support and use for languages other than Java has been minimal.
Having that said, I don't have any personal experience of maven with something else than Java. But I can suggest to check out Maven for other languages? :)
We're using Maven to build a Flex application, and it's working quite nicely :).
I have used maven for generating documentation based on LaTeX source files. Using exec and some wrapper scripts, I can create PDF files and handle SCM releases.
One of the PDF files generated is included in a web app by letting maven package it into a jar file, which is referenced from the web app as a regular dependency. The web app can then access the PDF file on the class path.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
A few years ago I looked into using some build system that isnt Make, and tools like CMake and SCons seemed pretty primitive. I'd like to find out if the situation has improved. So, under the following criteria, what is currently the best build tool:
platform agnostic: should work on windows, linux, mac
language agnostic: should have built-in support for common things like building C/C++ and other static langs. I guess it doesn't need to support the full autotools suite.
extensible: I need to be able to write rules to generate files, like from restructuredText, latex, custom formats, etc. I dont really care what language I have to write the rules in, but I would prefer a real language rather than a DSL.
I would prefer to avoid writing any XML by hand, which I think for example ant requires.
Freely available (preferably open source)
The term "best" is slightly subjective, but I think answers can be rated objectively by the criteria above.
I'd definitively put my vote up for premake. Although it is not as powerful as it's older brothers, it's main advantage is absurd simplicity and ease of use. Makes writing multi-compiler, multi-platform code a breeze, and natively generates Visual Studio solutions, XCode projects, Makefiles, and others, without any additional work needed.
So, judging purely by the criteria set forth in the question, the build system that seems like the best fit is probably waf - pure Python, provides support for C++ and other languages, general, powerful, not a DSL.
However, from my personal experience, I prefer CMake for C++ projects. (I tried CMake, SCons, and waf, and liked them in roughly that order). CMake is a general solution, but it has built-in support for C++ that makes it nicer than a more generic solution when you're actually doing C++.
CMake's build model for C++ is more declarative and less imperative, and thus, to me, easier to use. The CMake language syntax isn't great, but a declarative build with odd syntax beats an imperative build in Python. Of the three, CMake also seems to have the best support for "advanced" things like precompiled headers. Setting up precompiled headers reduced my rebuild time by about 70%.
Other pluses for CMake include decent documentation and a sizable community. Many open source libraries have CMake build files either in-tree or provided by the CMake community. There are major projects that already use CMake (OGRE comes to mind), and other major projects, like Boost and LLVM, are in the process of moving to CMake.
Part of the issue I found when experimenting with build systems is that I was trying to build a NPAPI plugin on OS X, and it turns out that very few build systems are set up to give XCode the exact combination of flags required to do so. CMake, recognizing that XCode is a complex and moving target, provides a hook for manually setting commands in generated XCode projects (and Visual Studio, I think). This is Very Smart as far as I'm concerned.
Whether you're building a library or an application may also determine which build system is best. Boost still uses a jam-based system, in part because it provides the most comprehensive support for managing build types that are more complex than "Debug" and "Release." Most boost libraries have five or six different versions, especially on Windows, anticipating people needing compatible libraries that link against different versions of the CRT.
I didn't have any problems with CMake on Windows, but of course your mileage may vary. There's a decent GUI for setting up build dependencies, though it's clunky to use for rebuilds. Luckily there's also a command-line client. What I've settled on so far is to have a thin wrapper Makefile that invokes CMake from an objdir; CMake then generates Makefiles in the objdir, and the original Makefile uses them to do the build. This ensures that people don't accidentally invoke CMake from the source directory and clutter up their repository. Combined with MinGW, this "CMake sandwich" provides a remarkably consistent cross-platform build experience!
Of course that depends on what your priorities are. If you are looking primarily for ease of use, there are at least two new build systems that hook into the filesystem to automatically track dependencies in a language agnostic fashion.
One is tup:
http://gittup.org/tup/
and the other is fabricate:
http://code.google.com/p/fabricate/
The one that seems to be the best performing, portable, and mature (and the one I have actually used) is tup. The guy who wrote it even maintains a toy linux distro where everything is a git submodule, and everything (including the kernel) is build with tup. From what I've read about the kernel's build system, this is quite an accomplishment.
Also, Tup cleans up old targets and other cruft, and can automatically maintain your .gitignore files. The result is that it becomes trivial to experiment with the layout and names of your targets, and you can confidently jump between git revisions without rebuilding everything. It's written in C.
If you know haskell and are looking for something for very advanced use cases, check out shake:
http://community.haskell.org/~ndm/shake/
Update: I haven't tried it, but this new "buildsome" tool also hooks into the filesystem, and was inspired by tup, so is relevant:
https://github.com/ElastiLotem/buildsome
CMake
CMake is an extensible, open-source
system that manages the build process
in an operating system and in a
compiler-independent manner.
Gradle seems to match all the criteria mentioned above.
It's a build system which took the best of Maven and Ant combined. To me, that's the best.
The Selenium project is moving over to Rake, not because its the best but because it handles multiple languages slightly better than all the other build tools and is cross platform (developed in Ruby).
All build tools have their issues and people learn to live with them. Something that runs on the JVM tends to be really good for building apps so Ant, Maven (i know its hideous), Ivy, Rake
Final Builder is well known in Windows world
smooth build matches most of your requirements.
platform agnostic: yes, it's written in java
language agnostic: it doesn't support c/c++t yet, only java but it is extensible via plugins written in java so adding more compilers support is not a problem
extensible: yes, you can implement smooth function via java plugin, you can also create smooth function via defining it as expression built of other smooth functions.
I would prefer to avoid writing any XML: you won't see a single line of it in smooth build
Freely available: yes, Apache 2 license
disclosure: I'm the author of smooth build.