Open Source Vs Commercial Applications
-
Hi to all. I will start an "open" question: I'm developing several projects based on QT environment (not for the same platform) and actually I'm moving several other projects under this platform.
I ask if you think that is possible that every development project, paid and for some specific customer or company or ... can also be used to give some part of this or some developed elements to the community as an open source component.
In terms of development approach, this means that in every project - this is my though - it is possible to focus elements that can be opened to the community without interferences to the commercial aspects of the global project. -
Not sure if i understood completely but i think it is possible to have custom licencing terms for the released source.
However do u mean u want to release some portion of code as open source and some portion as closed source from a released project ?
-
Hi,
I mean that the problem should be that the commercial product should not be released with an O.S. license because the code should be protected. In the meanwhile, for example the interface, vs the developed algorithms, can be a new solution useful for the community. Creating a new kind of interface for an application does not impact on the "protected" elements of the program and in the meanwhile the community users can take advantage from the work (and cooperate to the development).
Finally this means to create different sub-projects, some of them open and other licensing protected.Someone already experienced cases of this type?
Another possible approach is to deliver an open source application that can also be sold in a more complete version of the product. The idea is to take always a collaborative part in every project.
-
Well, it all depends on your licencing of the open source components. You need to choose a licence type that will allow use of those components in a closed source application, or you need to make sure that all the open source code is copyrighted by you. That is: have other contributors assign their rights over to you. That last thing is something that usually does not go down all that well, so if you want to attract other contributors, you probably do not want to do this.
There are many open source licences that allow use of the code in closed source products. LGPL is of course very well known as it is used by Qt itself. You simply need to make sure that the open code stays in a library of it's own, that you link against dynamically from your closed application. Other options include BSD and MIT licences, but there are more options I think.
For releasing two versions of your own code: that is perfectly possible. You can licence and re-licence your own code in any way you see fit. That includes releasing the same code under two or more different licences. As long as the code is copyrighted by you (either you wrote it, or some else signed over the copy rights), there is no problem using your own (open) code in another (closed) product.
You are going to get this comment a lot, and also from me: IANAL. If you want to get real answers, consult a lawyer specializing in licencing issues. It can get tricky, and there are probably corner cases or interactions with legislation in your own legal area none of us are familiar with.
-
I agree what Andre said, however from your post it seems you are looking for licence terms where open source and closed source both advantage you can take whichever is beneficial at times. is that the case ? then definatly lawyer can help you out with this. .
Have a look at this chart http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses
-
Alicemirror,
since you are the author you can release your software under as many licenses as you like. Multiple licenses are no legal conflict. The Trolls do exactly the same (GPL, LGPL, commercial license available).Just as you neeed to fullfill your obligations to Nokia depending on the Qt license you choose the receipients of your software will choose a license and need to comply to your respective terms.