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.
Related
I am a Premium WordPress Theme Developer. During the development process Multiple developer working on same theme simultaneously and it create conflict issue as to make changes one developer enter there codes and update files.Mostly same files are open on other developers pc and when later own they save files the changes of developer 1 become lost and create lots of problems. Is there a better solution to tackle this issue?
Thanks
Most web-developers have probably worked with some sort of revision control system, but designers may find it a foreign concept. The most obvious benefit of using revision control is the ability to have an unlimited number of people working on the same code base, without having to constantly send files back and forth.
Git is the new fast-rising star of version control systems.Git offers a much different type of version control in that it’s a distributed version control system.
Subversion is probably the version control system with the widest adoption. Most open-source projects use Subversion as a repository because other larger projects, such as SourceForge, Apache, Python, Ruby and many others, use it as well. Google Code uses Subversion exclusively to distribute code.
https://www.atlassian.com/git/tutorials/what-is-version-control/
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").
I want to make an app using Qt that communicates with serial port.
The problem is that I cant find a library that works and does this thing.
I need a non General Public License library I think.
Actually I am not sure cause I don't know if I can use a General Public License library for a closed source program.
I found qextserialport but I am unable to build it using Qt 4.7.3. I added all the needed headers but it fails on some functions.
Can anyone help me here?
If you want to go closed source and distribute your application, you can't use GPL. You can use LGPL when linking either dynamically or statically. For the latter, you need to provide object files for all of your code, so that they can be statically re-linked with Qt.
Conercerning your base issue, Qt 5 includes a serial port module. On Qt 4, you'll need a platform-specific solution. Reducing the scope might help to point you to something. I suggest that if you don't target portability, you should add relevant tags and comments. Otherwise, saying that you need a portable solution is a good thing too.
As far as I know, on most paltforms, accessing to serial port requires higher privileges, so be ready for that in your deployment.
Concerning qtextserialport, license is BSD so it would work for your clsoed source application. If you post a compilation issue on where it fails, maybe people will be able to help you
I tried to compile it using VC2010 and Qt 4.7.2 and head of project (I just cloned it) compiles flawlessly: I got a nice qextserialport1.dll (that I admit I didn't try using).
There is a QtSerialPort add-on nowadays that can be used for such tasks. I am one of the maintainers behind it. That is the "official" Qt add-on nowadays, so I would suggest switching to it. It will also support Qt 4.
It is properly useful for commercial code (closed source) as I have also been doing that. If we do not yet have an exception for static linking, I would even accept that if legally possible.
My opinion about licenses is somewhere in-between LGPLv2 and MIT, i.e. LGPLv2 + static linking.
Here you can find my blog post about it. It also works fine with Qt 4 as we have had put some effort into that support, too.
http://lpapp.blogspot.co.uk/2013/02/qtserialport-in-qt-51.html
I am going to develop my first application (4 members team).I am not aware of source control tool ( Visual
source safe,Tortoise SVN).
My .NET version is 3.5. What is the best source control tool ?
Is CruiseControl a source control tool ?
Definitely avoid Visual Source Safe.
Subversion is probably a safe choice, but you will have to elaborate about your situation (E.g. how big is your team?) to get more specific advice.
Another no vote for Visual Source Safe here.
Might be an idea to get familiar with subversion as - just as others mentioned - it's widely adopted, so might be useful in the future and simply works..oh and it's free too!
TortoiseSVN integrates into the windows explorer and is both easy to use and well documented so I would give it a try.
If it's a small project of yours and you don't want to worry about hosting, I would recommend signing up for a free account at something like beanstalk, to keep it safe, without any hassle.
But if it's your first ever project, it might just give you too many additional things to learn about, so you might want to put it aside for a while.
Try GIT, it's much lighter weight than svn
http://sourceforge.net/projects/gitextensions/
you can use a local repository for just checking in your own work (to keep a history, or to keep a working version before changing everything) Or you can connect to a central repository for enterprise source control.
The company where I work used to use the SVN, Tortoise, Ankh stack but we're using Git now. Plus I use it at home on my on play projects.
(quated part is no more important since you edited your post about team size)
If you are doing some small project on
your own, maybe you shouldn't use code
versioning at all because you probably
don't need it. Code versioning helps
you with central code storage,
multi-person development code merging
(several people working on the same
file and then commit changes) and code
branching to name the most important
ones.
If I were you, and I would be the only
person developing something simple, I
wouldn't use it, because it would also
be a bit of a time-overkill.
But otherwise source control doesn't address technology like .Net framework version. Code control only stores files (with history) and is able to merge text files. Written in whatever language possible.
If you are part of a team I'd suggest using Subversion + TortoiseSVN + AnkhSVN
And No, CruiseControl is not a code versioning system. It's a continuous integration system.
If you have a pure Windows environment then VisualSVN server is a Windows version of SVN server and installs easily and cleanly. You can setup security using Windows usernames and passwords, or SVN usernames and passwords.
You can then use Tortoise to provide integration in Explorer and VisualSVN to provide Visual Studio integration (there's a small cost for VisualSVN) or you could try AnkhSVN if all you want is VS integration and don't want to spend any money. Personally I prefer VisualSVN's integration.
Running a GIT server under Windows is, umm, frankly a pain in the ass, and not a route I'd recommend for beginners. VS integration is also fraught with pain.
As with everyone else I'd say avoid SourceSafe like the plague.
CruiseControl is not a source control system, it's an automated build server. It monitors source control servers looking for changes, then checks everything out, compiles it and runs it through your unit tests, so people know if they've broken the build. Once you have source control up and running it's the next big step towards a better build environment.
Before we start talking about source control, I would like you to consider your actual need for it, if this is to be your first .NET application. Is this your actual first attempt of writing some .NET 3.5 code? If so, I doubt that you need to worry about source control just yet. I would say it's not just a little bit overkill for the first learning projects.
On the other hand, if this is to be your first application that you'll actually sell to someone, it's a completely different matter.
I currently use VisualSVN, an add-in to Visual Studio that lets you do check-in, check-out etc from within the environment. Along with it, I use the free SVN repository service at XP-Dev. It works well for me =)
Your choice of a versioning system does not have to do anything with the .NET version you are using.
I'd vote for Subversion / Tortoise SVN. It's rock-solid, has lots of handy features, widely adopted and free.
One thing I've always wondered about is how software patches work. A lot of software seems to just release new versions on their binaries that need to be installed over older versions, but some software (operating systems like Windows in particular) seem to be able to release very small patches that correct bugs or add functionality to existing software.
Most of the time the patches I see can't possibly replace entire applications, or even small files that are used within applications. To me it seems like the actual binary is being modified.
How are these kinds of patches actually implemented? Could anyone point me to any resources that explain how this works, or is it just as simple as replacing small components such as linked libraries in an application?
I'll probably never need to do a deployment in this manner, but I am curious to find out how it works. If I'm correct in my understanding that patches can really modify only portions of binary files, is this possible to do in .NET? If it is I'd like to learn it since that's the framework I'm most familiar with and I'd like to understand how it works.
This is usually implemented using binary diff algorithms -- diff the most recently released version against the new code. If the user's running the most recent version, you only need to apply the diff. Works particularly well against software, because compiled code is usually pretty similar between versions. Of course, if the user's not running the most recent version you'll have to download the whole thing anyway.
There are a couple implementations of generic binary diff algorithms: bsdiff and xdelta are good open-source implementations. I can't find any implementations for .NET, but since the algorithms in question are pretty platform-agnostic it shouldn't be too difficult to port them if you feel like a project.
If you are talking about patching windows applications then what you want to look at are .MSP files. These are similar to an .MSI but just patch and application.
Take a look at Patching and Upgrading in the MSDN documents.
What an .MSP files does is load updated files to an application install. This typically is updated dll's and resource files, but could include any file.
In addition to patching the installed application, the repair files located in C:\WINDOWS\Installer are updated as well. Then if the user selects "Repair" from Add / Remove programs the updated patch files are used as well.
I'm thinking that the binary diff method discussed by John Millikin must be used in other operating systems. Although you could make it work in windows it would be somewhat alien.