Re: Licenses in a commercial application
Gabor Szabo wrote: On 3/18/07, David Golden [EMAIL PROTECTED] wrote: You might find this open book helpful: http://www.oreilly.com/catalog/osfreesoft/book/ thanks 8. Aggregation of this Package with a commercial distribution is always permitted provided that the use of this Package is embedded; that is, when no overt attempt is made to make this Package's interfaces visible to the end user of the commercial distribution. Such use shall not be construed as a distribution of this Package. What does that mean that no overt attempt is made to make this Package's interfaces visible ? How can I make sure we are fulfilling this requirement? Quoting from that book: This Section 8 accordingly limits the generally free distribution of the source and executable codes under Section 1 and 4 respectively when that distribution is part of a commercial aggregate with the Package. In those situations, the Package may be utilized as part of the commercial program, but its interfaces (and, correspondingly, the ability to write new scripts in Perl) must be blocked from the end user. This section is presumably included to prevent commercial distributions of programs written in Perl from competing with the parallel open source distributions of Perl that are intended to encourage innovation and contributions to Perl itself. That would mean ccperl and all the other vendor supplied perls were actually violating with this section. If package a script with PAR including everything even perl itself then after it is installed it allows writing scripts on this perl. If you create a compiled distribution based on perl and a bunch of CPAN packages and optionally some propriatery packages, is this then in violation of that section? I personally don't see what's the point behind hiding this version of perl. I believe that's where the overtly bit might come into it. If the ordinary users of YOUR program won't be writing Perl applications using what you install, but will just be using the normal user interfaces, it's fine. If you install your program, but say And since it installs Perl, you can also use it to write your own Perl programs! that would be overtly making the interfaces visible. If all the user ever see's is buttons and widgets, it's just fine. IANAL however. Adam K
Re: Licenses in a commercial application
On 3/20/07, Adam Kennedy [EMAIL PROTECTED] wrote: Gabor Szabo wrote: On 3/18/07, David Golden [EMAIL PROTECTED] wrote: If you install your program, but say And since it installs Perl, you can also use it to write your own Perl programs! that would be overtly making the interfaces visible. If all the user ever see's is buttons and widgets, it's just fine. IANAL however. Adam K I am not a lawyer either, but I used to think I would become one -- and I think that you could even provide a script operations in this system using an application-specific dialect of the Perl language facility without violating anything. This section is presumably included to prevent commercial distributions of programs written in Perl from competing with the parallel open source distributions of Perl that are intended to encourage innovation and contributions to Perl itself. I think the Artistic License explicitly allows forking Perl. The fact that nobody has successfully pulled this off has to do with the reward to effort ratio and the bad effects of no longer being compatible with man release perl, not a legal motivation. Given the choice of installed perl to run a perl script with, I would much rather have the command line switches and so on than have to sneak an eval statement into a regular expression in an e-mail filtering system. Unless I wanted to work around access control permissions or something. Which is another reason not to allow evaluation of user-provided code, the insecurity implications. -- When the day comes that anyone can bend our country's laws and lawmakers to serve selfish, competitive ends, that day democratic government dies. And we're just optimistic enough to believe that once the facts are on the table, American public opinion will walk in with a big stick. -- Preston Tucker, June 15, 1948
Re: Licenses in a commercial application
specifically, paragraph 4.c: [you may distribnuted modifed Perl provided you] give non-standard executables non-standard names, and clearly document the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version. So, something like Whizzomatic can be automated by writing whizz-scripts, using Perl! (To obtain Perl, see http://perl.org) would allow commercial distribution under 4.c. Para 8 allows Perl to fit into the bigger picture much like a compiler -- compile an executable and distribute the executable, that's not a distribution of the compiler. Compose an aggregation of perl and a perl script and distribute the aggregation, that's not a distributioon of Perl.
Re: Licenses in a commercial application
On 3/18/07, Gabor Szabo [EMAIL PROTECTED] wrote: We are planning to distribute our application under some restrictive, proprietary license. Technically we are distributing a zipped version of the compiled Perl and the CPAN modules and then we install (using Perl Makefile.PL;make;make install) our code but at some point we might distribute the whole thing in an installable exe file. I need your help to deal with the legal aspect of this. You might find this open book helpful: http://www.oreilly.com/catalog/osfreesoft/book/ 8. Aggregation of this Package with a commercial distribution is always permitted provided that the use of this Package is embedded; that is, when no overt attempt is made to make this Package's interfaces visible to the end user of the commercial distribution. Such use shall not be construed as a distribution of this Package. What does that mean that no overt attempt is made to make this Package's interfaces visible ? How can I make sure we are fulfilling this requirement? Quoting from that book: This Section 8 accordingly limits the generally free distribution of the source and executable codes under Section 1 and 4 respectively when that distribution is part of a commercial aggregate with the Package. In those situations, the Package may be utilized as part of the commercial program, but its interfaces (and, correspondingly, the ability to write new scripts in Perl) must be blocked from the end user. This section is presumably included to prevent commercial distributions of programs written in Perl from competing with the parallel open source distributions of Perl that are intended to encourage innovation and contributions to Perl itself. Regards, David
Re: Licenses in a commercial application
On 3/18/07, David Golden [EMAIL PROTECTED] wrote: You might find this open book helpful: http://www.oreilly.com/catalog/osfreesoft/book/ thanks 8. Aggregation of this Package with a commercial distribution is always permitted provided that the use of this Package is embedded; that is, when no overt attempt is made to make this Package's interfaces visible to the end user of the commercial distribution. Such use shall not be construed as a distribution of this Package. What does that mean that no overt attempt is made to make this Package's interfaces visible ? How can I make sure we are fulfilling this requirement? Quoting from that book: This Section 8 accordingly limits the generally free distribution of the source and executable codes under Section 1 and 4 respectively when that distribution is part of a commercial aggregate with the Package. In those situations, the Package may be utilized as part of the commercial program, but its interfaces (and, correspondingly, the ability to write new scripts in Perl) must be blocked from the end user. This section is presumably included to prevent commercial distributions of programs written in Perl from competing with the parallel open source distributions of Perl that are intended to encourage innovation and contributions to Perl itself. That would mean ccperl and all the other vendor supplied perls were actually violating with this section. If package a script with PAR including everything even perl itself then after it is installed it allows writing scripts on this perl. If you create a compiled distribution based on perl and a bunch of CPAN packages and optionally some propriatery packages, is this then in violation of that section? I personally don't see what's the point behind hiding this version of perl. Gabor
