Hi all, since i noticed that none of the original GEM C++ wrapper code is present in flext anymore, and there have already been requests concerning the license issue, i'll now look into it more deeply. Flext will soon fully support jMax, which means that the same source code can be used for development of externals under all three major modular real-time systems. It is now released under the GPL what might somehow hamper the development of packages depending on flext. I'm an ignorant concerning these license issues, so i'm asking you for some input on this case. The most obvious solution would be the LGPL license, but there may be others i don't know about. Any suggestions?
best greetings, Thomas
The alternative would be a BSD license, which is the most liberal license. Why not just use the license PD uses? I think it's similar to BSD (or is it BSD license)?
But also LGPL is much better than GPL... :-)
Thomas Grill wrote:
Hi all, since i noticed that none of the original GEM C++ wrapper code is present in flext anymore, and there have already been requests concerning the license issue, i'll now look into it more deeply. Flext will soon fully support jMax, which means that the same source code can be used for development of externals under all three major modular real-time systems. It is now released under the GPL what might somehow hamper the development of packages depending on flext. I'm an ignorant concerning these license issues, so i'm asking you for some input on this case. The most obvious solution would be the LGPL license, but there may be others i don't know about. Any suggestions?
Hi, smoerk schrieb:
The alternative would be a BSD license, which is the most liberal license. Why not just use the license PD uses? I think it's similar to BSD (or is it BSD license)?
But also LGPL is much better than GPL... :-)
Well, it's not better, but something different. Before I go on, I'd better say, that I prefer the GPL for my projects and in general. RMS himself has written long articles regarding the differece between the LGPL and the GPL, for example: http://www.fsf.org/licenses/why-not-lgpl.html
In a nutshell it boils down to this: Use the LGPL, if you want proprietary, non-free software written with your library, use the GPL, if you don't want this. Plus: If you have written a software/library, that has no commercial alternative, use the GPL to strengthen the Free software movement. Because then "we have something, they (the proprietarians) haven't".
Thomas Grill wrote:
It is now released under the GPL what might somehow hamper the development of packages depending on flext.
The GPL hampers the developement of closed source (flext-)externals. You have put a whole lot of work into flext and made it open source. I don't see any gain in releasing it to developers, that wouldn't want to release their source.
The most obvious solution would be the LGPL license, but there may be others i don't know about. Any suggestions?
Although written by the FSF, this document is a great overview of various open source licenses: http://www.fsf.org/licenses/license-list.html
Especially important are the comments on "GPL-Compatible or not" licenses, because there already are flext-externals written under GPL (mine and most others, because currently flext is GPL), so they should be able to retain the GPL in the future as well.
Actually, I wouldn't bother much reading all those licenses. I don't see real advantages to using something else than the (L)GPL - with copyleft enforcing - or the X11 - proprietary usage possible (aka BSD, MIT) - licenses for open source software. Most other licenses to me just seem like syntactical sugar. And the Pd license itself looks a little vague in my eyes.
ciao
Hi Frank, you have strong arguments to stick to the GPL and one point's for sure:
- GPL must be a possible license choice for all current and future externals basing on flext
However, flext is more general and in the Max/MSP world open-source is not as widespread as in the PD universe. As a musician i'm often depending on stable, feature-rich performance tools and if they do the job i'm willing to pay for them. It's easy to develop large, complex packages with flext (see vasp) and i want to encourage that, be open-source or not.
So the target license should strongly encourage the open-source idea (and be compatible with the GPL), but allow commercial applications as well. That should be fairly easy.
best greetings, Thomas
Hallo Thomas,
Thomas Grill schrieb:
However, flext is more general and in the Max/MSP world open-source is not as widespread as in the PD universe.
Maybe flext could (help to) change that?
As a musician i'm often depending on stable, feature-rich performance tools and if they do the job i'm willing to pay for them. It's easy to develop large, complex packages with flext (see vasp) and i want to encourage that, be open-source or not.
I see your point, I have another opinion, but I don't have a problem with that at all.
I'd just like to add one thought. A flext external for Max/MSP on Mac written by someone in the huge Max/MSP community could work on Pd-Linux, if the source was available. But if that someone in the Max/Mac world wouldn't want to supply or couldn't build a Pd/Linux binary, and wouldn't release the source, it would be impossible to run it on Pd/Linux.
This somehow, I think, would be against (one of) the whole point(s) of flext: cross-plattform source code portability.
ciao
Frank Barknecht schrieb:
Hi, smoerk schrieb:
The alternative would be a BSD license, which is the most liberal license. Why not just use the license PD uses? I think it's similar to BSD (or is it BSD license)?
But also LGPL is much better than GPL... :-)
Well, it's not better, but something different. Before I go on, I'd better say, that I prefer the GPL for my projects and in general. RMS himself has written long articles regarding the differece between the LGPL and the GPL, for example: http://www.fsf.org/licenses/why-not-lgpl.html
In a nutshell it boils down to this: Use the LGPL, if you want proprietary, non-free software written with your library, use the GPL, if you don't want this. Plus: If you have written a software/library, that has no commercial alternative, use the GPL to strengthen the Free software movement. Because then "we have something, they (the proprietarians) haven't".
The problem with the GPL for libraries is, that you don't have the freedom to use another license than GPL for your externals for example a BSD license. If I were a developer and wanted to write a external for pd, I would not use the GPL flext library, because it forces me to put my code under the GPL license. So I would write my external only for pd instead of using flext and make it portable.
Hi, smoerk schrieb:
The problem with the GPL for libraries is, that you don't have the freedom to use another license than GPL for your externals for example a BSD license.
This is simply not true. According to the GPL-FAQ at fsf.org, if you are using libraries licensed under the GPL, you must use a GPL-compatible license to use those libraries in your on software. The (modified) BSD license is compatible with the GPL.
Compatible here "means you can combine a module which was released under that license with a GPL-covered module to make one larger program."
ciao
On Wed, 22 Jan 2003, Frank Barknecht wrote:
Hi, smoerk schrieb:
The problem with the GPL for libraries is, that you don't have the freedom to use another license than GPL for your externals for example a BSD license.
This is simply not true. According to the GPL-FAQ at fsf.org, if you are using libraries licensed under the GPL, you must use a GPL-compatible license to use those libraries in your on software. The (modified) BSD license is compatible with the GPL.
Compatible here "means you can combine a module which was released under that license with a GPL-covered module to make one larger program."
That was my feeling too, but I did not have the time to look this up really. I think LPGL is not giving you more freedom, it takes away freedom. Be clever and protect yourself. If you write free software you want to make sure that there won't be someone coming along, wrapping some code around your library and making millions without giving you a cent.
Guenter
Hey, i'd like to thank you all for your contribution to the discussion. I've now got a lot more insight into the license thing than before.
Consequently, flext will remain under the GPL as ever, but it will be possible for commercial applications to get an individual paid license. The case of commercial source code distribution (like linux CDs) is well covered by the GPL.
cheers, Thomas
Hi, Thomas Grill schrieb:
i'd like to thank you all for your contribution to the discussion. I've now got a lot more insight into the license thing than before.
Consequently, flext will remain under the GPL as ever, but it will be possible for commercial applications to get an individual paid license. The case of commercial source code distribution (like linux CDs) is well covered by the GPL.
Thank you.
I think, this is a good decision. But from what I wrote, it must be obvious, that I think so... ;)
ciao
guenter geiger wrote:
On Wed, 22 Jan 2003, Frank Barknecht wrote:
Hi, smoerk schrieb:
The problem with the GPL for libraries is, that you don't have the freedom to use another license than GPL for your externals for example a BSD license.
This is simply not true. According to the GPL-FAQ at fsf.org, if you are using libraries licensed under the GPL, you must use a GPL-compatible license to use those libraries in your on software. The (modified) BSD license is compatible with the GPL.
Compatible here "means you can combine a module which was released under that license with a GPL-covered module to make one larger program."
That was my feeling too, but I did not have the time to look this up really. I think LPGL is not giving you more freedom, it takes away freedom. Be clever and protect yourself. If you write free software you want to make sure that there won't be someone coming along, wrapping some code around your library and making millions without giving you a cent.
the bad bad comercial guys ;-). do you really think you can make money with a comercial license? in the case of flext i doubt it. let them pay for your support and your knowledge and don't ignore the advantages of the LGPL in some cases: Apple was able to use the KHTML library (HTML rendering) for there closed source Safari browser, because it's licensed under the LGPL. They made a lot of improvements to KHTML, which means a better open source HTML browser for Linux. Win-win situation...
quite off-topic, but nice: this mail from smoerk was the #10000 in my pd-mailbox... keep on rockin' d13b
guenter geiger wrote:
On Wed, 22 Jan 2003, Frank Barknecht wrote:
Hi, smoerk schrieb:
The problem with the GPL for libraries is, that you don't have the freedom to use another license than GPL for your externals for example a BSD license.
This is simply not true. According to the GPL-FAQ at fsf.org, if you are using libraries licensed under the GPL, you must use a GPL-compatible license to use those libraries in your on software. The (modified) BSD license is compatible with the GPL.
Compatible here "means you can combine a module which was released under that license with a GPL-covered module to make one larger program."
That was my feeling too, but I did not have the time to look this up really. I think LPGL is not giving you more freedom, it takes away freedom. Be clever and protect yourself. If you write free software you want to make sure that there won't be someone coming along, wrapping some code around your library and making millions without giving you a cent.
the bad bad comercial guys ;-). do you really think you can make money with a comercial license? in the case of flext i doubt it. let them pay for your support and your knowledge and don't ignore the advantages of the LGPL in some cases: Apple was able to use the KHTML library (HTML rendering) for there closed source Safari browser, because it's licensed under the LGPL. They made a lot of improvements to KHTML, which means a better open source HTML browser for Linux. Win-win situation...
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
the bad bad comercial guys ;-). do you really think you can make money with a comercial license? in the case of flext i doubt it. let them pay for your support and your knowledge and don't ignore the advantages of the LGPL in some cases: Apple was able to use the KHTML library (HTML rendering) for there closed source Safari browser, because it's licensed under the LGPL. They made a lot of improvements to KHTML, which means a better open source HTML browser for Linux. Win-win situation...
Of course, nobody would expect to earn (a lot of) money selling flext licenses. But it's a matter of principle. There are Max/MSP packages which are commercial (tap.tools, litter power etc.) and there will be more, possibly even for pd. I developed flext for my own (musical) projects in the first case and it has become larger and more time-consuming than i intended. I'm extremely happy that other people use flext but i'm not in the position to finance some else's commercial developments.
so, summing up, open-source rules! best greetings, Thomas
On Mon, 20 Jan 2003, Thomas Grill wrote:
Flext will soon fully support jMax, which means that the same source code can be used for development of externals under all three major modular real-time systems.
Which API will you be supporting? jMax-2.5, or jMax-4.0 ? I've heard the two are quite different, but I haven't looked into jMax-4.0 yet (it's still experimental)
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
Flext will soon fully support jMax, which means that the same source
code
can be used for development of externals under all three major modular real-time systems.
Which API will you be supporting? jMax-2.5, or jMax-4.0 ? I've heard the two are quite different, but I haven't looked into jMax-4.0 yet (it's still experimental)
It's true, they are different and currently, i'm supporting the jMax 4.0 API only. I'm somehow new to jMax and didn't know about the differences before i started porting. Anyway, if there is some need both version could be supported without much effort.
greetings, Thomas
hi pd-devs,
guenter geiger wrote:
On Thu, 12 Dec 2002 bbogart@ryerson.ca wrote:
I'm trying to find the cylone library and can't recall where it is, not in CVS? not in the pure database...
(any plans on putting it in cvs? or did I simply miss it?)
No, Krzysztof said he doesn't like the idea of putting cyclone under GPL. Generally, I think that we can change the license for the externals, if that is wanted, and put them under the same license as pd. What do you think ?
Thomas Grill wrote: ...
It is now released under the GPL what might somehow hamper the development of packages depending on flext. I'm an ignorant concerning these license issues, so i'm asking you for some input on this case. The most obvious solution would be the LGPL license, but there may be others i don't know about. Any suggestions?
?
Krzysztof
No, Krzysztof said he doesn't like the idea of putting cyclone under GPL. Generally, I think that we can change the license for the
externals,
if that is wanted, and put them under the same license as pd. What do you think ?
Hmmm, i'm not sure. - I would like to emphasize the non-commercial aspect, so maybe charge a fee for the unlikely case of a commercial applications. - If someone makes changes/improvements to the code this should have to be a contribution to the public code base, so that others can profit from it.
greetings, Thomas
On Tue, 21 Jan 2003, Thomas Grill wrote:
No, Krzysztof said he doesn't like the idea of putting cyclone under GPL. Generally, I think that we can change the license for the
externals,
if that is wanted, and put them under the same license as pd. What do you think ?
Hmmm, i'm not sure.
- I would like to emphasize the non-commercial aspect, so maybe charge a fee
for the unlikely case of a commercial applications.
This outrules LGPL, because commercial applications are explicitely allowed to link against the library, without fee.
- If someone makes changes/improvements to the code this should have to be a
contribution to the public code base, so that others can profit from it.
Use the GPL then. You can still charge a fee by double licensing.
GPL might not be sufficient though for forcing people to contribute to the code base.
Greetings,
Guenter
Hi, Thomas Grill schrieb:
- I would like to emphasize the non-commercial aspect, so maybe charge a fee
for the unlikely case of a commercial applications.
It is not as unlikely as it seems. Distribution of Linux CDs for example is often done commercially. This is why the open source guidelines forbid restrictions regarding commercial use.
ciao
-
d -
david casal -
Frank Barknecht -
guenter geiger -
Krzysztof Czaja -
Mathieu Bouchard -
smoerk -
Thomas Grill