I’ve been thinking about the feasibility of leveraging Pd as a development platform for commercial patches. Sort of like some (e.g. Twisted Tools) are using Reaktor for developing commercial-grade plug-ins. But instead of Reaktor I could rather use Pd, because it’s a more open platform.
But if the development is for commercial purposes, there would need to be some sort of mechanism for closing the source. Is this possible or something worth looking at?
-Matti
Hi Matti,Pd Vanilla has a 3-clause BSD license. This license allows you to use the code in proprietary software and distribute binaries without also distributing the corresponding source code. It also allows you to make changes/improvements to the code without sharing them back with the community. As for external libraries-- it depends on how they are licensed. Some are licensed GPL, which doesn't allow you to do what you're asking. -Jonathan
On Saturday, May 7, 2016 11:48 AM, Matti Viljamaa <mviljamaa@kapsi.fi> wrote:
I’ve been thinking about the feasibility of leveraging Pd as a development platform for commercial patches. Sort of like some (e.g. Twisted Tools) are using Reaktor for developing commercial-grade plug-ins. But instead of Reaktor I could rather use Pd, because it’s a more open platform.
But if the development is for commercial purposes, there would need to be some sort of mechanism for closing the source. Is this possible or something worth looking at?
-Matti _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Sat, 2016-05-07 at 16:13 +0000, Jonathan Wilkes via Pd-list wrote:
Hi Matti, Pd Vanilla has a 3-clause BSD license. This license allows you to use the code in proprietary software and distribute binaries without also distributing the corresponding source code.
It also allows you to make changes/improvements to the code without sharing them back with the community.
As for external libraries-- it depends on how they are licensed. Some are licensed GPL, which doesn't allow you to do what you're asking.
I'm just curious: If I implemented a way to close-source Pure Data patches, would I violate the GPL if I ship:
- Pd as a binary
- the GPL'd externals as binary with their source code and License
- my closed-source patch
Roman
On 05/10/2016 04:38 PM, Roman Haefeli wrote:
As for external libraries-- it depends on how they are licensed. Some are licensed GPL, which doesn't allow you to do what you're asking.
I'm just curious: If I implemented a way to close-source Pure Data patches, would I violate the GPL if I ship:
- Pd as a binary
no, because Pd is not distributed under the GPL.
- the GPL'd externals as binary with their source code and License
- my closed-source patch
inal, but i sincerely hope that this is a violation of the GPL. (though i'm afraid that this is a bit fuzzy, and there might be some loopholes or even larger holes to allow this).
gfmsard IOhannes
I'm just curious: If I implemented a way to close-source Pure Data
patches, would I violate the GPL if I ship:
- Pd as a binary
- the GPL'd externals as binary with their source code and License
- my closed-source patch
That has to be a GPL violation. On the other hand:* proprietary Pd binary* place for user to enter url of remote repository of packages* Deken exists This can't possibly be a GPL violation. I'm not advocating for building proprietary binaries, but this is such a trivial workaround it'd be silly not to mention it. -Jonathan
On 2016-05-10 17:19, IOhannes m zmölnig wrote:
On 05/10/2016 04:38 PM, Roman Haefeli wrote:
- the GPL'd externals as binary with their source code and License
- my closed-source patch
inal, but i sincerely hope that this is a violation of the GPL. (though i'm afraid that this is a bit fuzzy, and there might be some loopholes or even larger holes to allow this).
ah, here is a reference: http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
which states very clearly, that the license of the interpreter (in our case: Pd's BSD license) has no effect on the license of the programs (your patch). however, if your interpreted program (patch) uses bindings to other facilities (an external) covered by the GPL, then your program must be released in a GPL-compatible way.
fgmasdr IOhannes
On May 10, 2016 9:39 AM, "Roman Haefeli" <reduzent reduzent@gmail.com@ reduzent@gmail.comgmail.com reduzent@gmail.com> wrote:
On Sat, 2016-05-07 at 16:13 +0000, Jonathan Wilkes via Pd-list wrote:
Hi Matti, Pd Vanilla has a 3-clause BSD license. This license allows you to use the code in proprietary software and distribute binaries without also distributing the corresponding source code.
It also allows you to make changes/improvements to the code without sharing them back with the community.
As for external libraries-- it depends on how they are licensed. Some are licensed GPL, which doesn't allow you to do what you're asking.
I'm just curious: If I implemented a way to close-source Pure Data patches, would I violate the GPL if I ship:
- Pd as a binary
- the GPL'd externals as binary with their source code and License
- my closed-source patch
No--INAL, either, but program inputs are not subject to GPL. Distributing software that links with GPL licensed libraries requires that the free/open software requirements of GPL are met for each program or library linked with. So, all that's additionally required is to distribute Pd's source code or provide a link to the code.
If you had to modify Pd in the process so it reads encrypted patches, you'd give away the method of encryption in the code and make the keys easier to find.
So then, one also has to find a decent method of obfuscating the inputs without linking with or modifying Pd. An additional binary that reads an encrypted patch translates it into a readable format but doesn't link with Pd. It can also be distributed without source code. But, then there's an intermediate form of the patch when it's run that can be read and so it is not a foolproof method of hiding anything.
Modified versions of Pd without the GPL can be distributed without providing source code. So one could add a method of reading an encrypted patch.
No--INAL, either, but program inputs are not subject to GPL.
Is there an example of proprietary software that ships with a GPL'd plug-in? You may be technically right. But in the context of a question about whether some person or business can come along and "hijack our stuff", the practical answer is very likely to be "no". And as someone who's spent too much time reading the code for some of that stuff, I'd also add, "Good luck". -Jonathan
On Wednesday, May 11, 2016 12:33 AM, Charles Z Henry <czhenry@gmail.com> wrote:
On May 10, 2016 9:39 AM, "Roman Haefeli" reduzent@gmail.com wrote:
On Sat, 2016-05-07 at 16:13 +0000, Jonathan Wilkes via Pd-list wrote:
Hi Matti, Pd Vanilla has a 3-clause BSD license. This license allows you to use the code in proprietary software and distribute binaries without also distributing the corresponding source code.
It also allows you to make changes/improvements to the code without sharing them back with the community.
As for external libraries-- it depends on how they are licensed. Some are licensed GPL, which doesn't allow you to do what you're asking.
I'm just curious: If I implemented a way to close-source Pure Data patches, would I violate the GPL if I ship:
* Pd as a binary * the GPL'd externals as binary with their source code and License * my closed-source patch No--INAL, either, but program inputs are not subject to GPL. Distributing software that links with GPL licensed libraries requires that the free/open software requirements of GPL are met for each program or library linked with. So, all that's additionally required is to distribute Pd's source code or provide a link to the code.If you had to modify Pd in the process so it reads encrypted patches, you'd give away the method of encryption in the code and make the keys easier to find.So then, one also has to find a decent method of obfuscating the inputs without linking with or modifying Pd. An additional binary that reads an encrypted patch translates it into a readable format but doesn't link with Pd. It can also be distributed without source code. But, then there's an intermediate form of the patch when it's run that can be read and so it is not a foolproof method of hiding anything.Modified versions of Pd without the GPL can be distributed without providing source code. So one could add a method of reading an encrypted patch.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
But we'll be missing out on awesome front ends we can pay for N stuff!
Patrick Pagano B.S, M.F.A Interactive Media & Education +1352.226.2016 https://patrickrpagano.wordpress.com/
On May 11, 2016, at 1:09 AM, Jonathan Wilkes via Pd-list <pd-list@mail.iem.atmailto:pd-list@mail.iem.at> wrote:
No--INAL, either, but program inputs are not subject to GPL.
Is there an example of proprietary software that ships with a GPL'd plug-in?
You may be technically right. But in the context of a question about whether some person or business can come along and "hijack our stuff", the practical answer is very likely to be "no". And as someone who's spent too much time reading the code for some of that stuff, I'd also add, "Good luck".
-Jonathan
On Wednesday, May 11, 2016 12:33 AM, Charles Z Henry <czhenry@gmail.commailto:czhenry@gmail.com> wrote:
On May 10, 2016 9:39 AM, "Roman Haefeli" <reduzentmailto:reduzent@gmail.com@mailto:reduzent@gmail.comgmail.commailto:reduzent@gmail.com> wrote:
On Sat, 2016-05-07 at 16:13 +0000, Jonathan Wilkes via Pd-list wrote:
Hi Matti, Pd Vanilla has a 3-clause BSD license. This license allows you to use the code in proprietary software and distribute binaries without also distributing the corresponding source code.
It also allows you to make changes/improvements to the code without sharing them back with the community.
As for external libraries-- it depends on how they are licensed. Some are licensed GPL, which doesn't allow you to do what you're asking.
I'm just curious: If I implemented a way to close-source Pure Data patches, would I violate the GPL if I ship:
- Pd as a binary
- the GPL'd externals as binary with their source code and License
- my closed-source patch
No--INAL, either, but program inputs are not subject to GPL. Distributing software that links with GPL licensed libraries requires that the free/open software requirements of GPL are met for each program or library linked with. So, all that's additionally required is to distribute Pd's source code or provide a link to the code. If you had to modify Pd in the process so it reads encrypted patches, you'd give away the method of encryption in the code and make the keys easier to find. So then, one also has to find a decent method of obfuscating the inputs without linking with or modifying Pd. An additional binary that reads an encrypted patch translates it into a readable format but doesn't link with Pd. It can also be distributed without source code. But, then there's an intermediate form of the patch when it's run that can be read and so it is not a foolproof method of hiding anything. Modified versions of Pd without the GPL can be distributed without providing source code. So one could add a method of reading an encrypted patch.
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Charles Z Henry -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Matti Viljamaa -
Pagano, Patrick -
Roman Haefeli