Re: MIT licensed source code
On May 17, 2012, at 4:33 PM, Josh Thompson wrote: > Thanks for your thoughts and pointing out the code modification veto process > (I wasn't aware of that). I removed the offending files and emailed the > project maintainer regarding the discrepancy in licensing. Cool. Thanks Josh. In most projects, Veto's are pretty rare. However, they are an important part of the ASF process. --kevan
Re: MIT licensed source code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aaron,
Good thoughts, and thanks for "asking the obvious". I vaguely remember
considering using openssl instead of mcrypt when I initially wrote that code.
I think the only reason I decided to use mcrypt was that it was symmetric key
based, making it quite a bit faster. It probably doesn't introduce enough
delay to really matter, but just doing some tests now, I found using
openssl_public_encrypt/openssl_private_decrypt to be around 15 times slower
than the current code.
If it wasn't for what I see to be a useful exercise in dealing with possibly
incompatible code from another project, I'd go ahead and switch to openssl,
using the symmetric functions if available and the asymmetric ones if not.
For now, I think I'll go ahead and finish working through the issue with
phpseclib.
Josh
On Thursday, May 17, 2012 2:26:55 PM Aaron Coburn wrote:
> Just to ask the obvious Why not just use the openssl library for this?
> Especially since the public and private keys are already being loaded in
> the initGlobals() function. I know that it's interface is not nearly so
> nice, and it doesn't support symmetric encryption for PHP <= 5.3, but
> here's some code that could be dropped in place in utils.php:
>
> function encryptData($data){
> global $keys;
> if(! $data)
> return false;
> openssl_public_encrypt(
> $data,
> $encrypted,
> $keys['public']);
> return trim(base64_encode($encrypted));
> }
>
> function decryptData($data){
> global $keys;
> if(! $data)
> return false;
> openssl_private_decrypt(
> base64_decode($data),
> $decrypted,
> $keys['private']);
> return trim($decrypted);
> }
>
> The other change would require modifying the initGlobals() function so that
> the public/private keys were read earlier in the execution of the function,
> i.e. before trying to decrypt a continuation value.
>
> Aaron
>
>
>
> --
> Aaron Coburn
> Systems Administrator and Programmer
> Academic Technology Services, Amherst College
> acob...@amherst.edu
>
>
>
>
>
>
> On May 17, 2012, at 8:34 AM, Josh Thompson wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wednesday, May 16, 2012 10:37:02 AM Kevan Miller wrote:
> On May 11, 2012, at 3:17 PM, Josh Thompson wrote:
>
> Kevan,
>
> Ugh. Thanks for looking at this. I guess it goes to show you can't just
> trust that another project that says it is MIT licensed is *completely*
> MIT
> licensed. :( I'll figure out a way to deal with it. If it works out
> that
> bcpowmod.php and str_split.php are not actually needed, can I just remove
> them? If so, do I need to document that modification somewhere?
>
> BTW, vcl/trunk/web/.ht-inc/phpseclib/index.html refers to PHP Secure
> Communications Library as LGPL-licensed. Which is contradicted by
> http://phpseclib.sourceforge.net/
>
> It looks like our documentation comes from
> http://phpseclib.sourceforge.net/documentation/ -- I'd check with the
> phpseclib project. Seems to be their reference to LGPL is unintended or
> inconsistent. bcpowmod.php's LGPL license would seem to be a problem with
> this, however…
>
> --kevan
>
> After looking further, there are only two files (AES.php and Rijndael.php)
> needed from the phpseclib project, and both of them appear as though they
> were written to be able to be included by themselves (i.e. each one
> contains information about the author, the project, and the license). Both
> files state that they are MIT licensed and contain that license in them.
> Is it normal to just pull in specific files from another project, or is it
> better to include the whole project?
>
> My only other experience in including another open source project in one I
> work on is from including the Dojo Toolkit with VCL. In that case, it
> seemed to make the most sense to include the whole thing.
>
> License wise, it seems simplest to just include the two files in the
> release, but I just want to make sure we do the right thing in respecting
> other open source projects.
>
> Thanks,
> Josh
> - --
> - ---
> Josh Thompson
> VCL Developer
> North Carolina State University
>
> my GPG/PGP key can be found at pgp.mit.edu
>
> All electronic mail messages in connection with State business which
> are sent to or received by this account are subject to the NC Public
> Records Law and may be disclosed to third parties.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (GNU/Linux)
>
> iEYEARECAAYFAk+08HIACgkQV/LQcNdtPQN8dgCdF/RaBttxHHuRMjuw73G9Kv34
> RjYAnimOHe1R50N532Bgxi+uOjVnkgjv
> =PjK8
> -END PGP SIGNATURE-
- --
- ---
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
All electronic mail messages in connection with State business which
are sent to or received by this account
Re: MIT licensed source code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, May 17, 2012 11:45:00 AM Kevan Miller wrote: > On May 17, 2012, at 8:34 AM, Josh Thompson wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Wednesday, May 16, 2012 10:37:02 AM Kevan Miller wrote: > >> On May 11, 2012, at 3:17 PM, Josh Thompson wrote: > >>> Kevan, > >>> > >>> Ugh. Thanks for looking at this. I guess it goes to show you can't > >>> just > >>> trust that another project that says it is MIT licensed is *completely* > >>> MIT > >>> licensed. :( I'll figure out a way to deal with it. If it works out > >>> that > >>> bcpowmod.php and str_split.php are not actually needed, can I just > >>> remove > >>> them? If so, do I need to document that modification somewhere? > >> > >> BTW, vcl/trunk/web/.ht-inc/phpseclib/index.html refers to PHP Secure > >> Communications Library as LGPL-licensed. Which is contradicted by > >> http://phpseclib.sourceforge.net/ > >> > >> It looks like our documentation comes from > >> http://phpseclib.sourceforge.net/documentation/ -- I'd check with the > >> phpseclib project. Seems to be their reference to LGPL is unintended or > >> inconsistent. bcpowmod.php's LGPL license would seem to be a problem with > >> this, however… > >> > >> --kevan > > > > After looking further, there are only two files (AES.php and Rijndael.php) > > needed from the phpseclib project, and both of them appear as though they > > were written to be able to be included by themselves (i.e. each one > > contains information about the author, the project, and the license). > > Both files state that they are MIT licensed and contain that license in > > them. Is it normal to just pull in specific files from another project, > > or is it better to include the whole project? > > First, I should say that all my comments are from a purely procedural > nature… I'm not making any comments on the function. > > It's more "normall" to pull in whole projects. Certainly true when you're > pull in as dependencies. Advantage is that as fixes are made to original > library, you pull in as a dependency (and don't have to migrate any source > fixes). More later... > > That doesn't mean that whole projects is "better". Both can be equally > correct. In this case, only pulling in the two files would seem perfectly > fine to me. > > Can I please ask that the LGPL files be removed from SVN immediately? Please > treat this as a -1 on the original svn commit as the commit contains LGPL > licensed code. Removing the offending files from svn will address my veto. > > As a (final?) piece of mentor education, see: > > http://www.apache.org/foundation/voting.html#votes-on-code-modification > http://www.apache.org/foundation/voting.html#Veto > > > My only other experience in including another open source project in one I > > work on is from including the Dojo Toolkit with VCL. In that case, it > > seemed to make the most sense to include the whole thing. > > Right. So, both techniques are used. Which is most appropriate, depends on > the situation. > > License wise, it seems simplest to just include the two files in the > > release, but I just want to make sure we do the right thing in respecting > > other open source projects. > > In general copying code is less desirable than including released software > from another project. A description of this practice (with negative > connotations) would be "forking" (though forking usually refers to an > entire project). In general, we'd prefer to collaborate with other > projects, rather than copy their code. > > However, open source gives us the flexibility to choose. And we should feel > free to choose what best fits the needs of the project -- taking all > factors into account... > > In this case, we should definitely raise the licensing questions that have > been raised with the phpseclib project (no matter how we resolve the > issue). And, by the way, perhaps there was a mistake made and those files > aren't LGPL -- we may learn something... > > --kevan Kevan, Thanks for your thoughts and pointing out the code modification veto process (I wasn't aware of that). I removed the offending files and emailed the project maintainer regarding the discrepancy in licensing. Josh - -- - --- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk+1YJEACgkQV/LQcNdtPQMdqwCfVL0kJ7yWds73jEi+Xe4Uo7iu m/0AnjSIpFn1UjAbDNCIMMsIO0Ew1MVd =SR3z -END PGP SIGNATURE-
Re: MIT licensed source code
On May 17, 2012, at 8:34 AM, Josh Thompson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wednesday, May 16, 2012 10:37:02 AM Kevan Miller wrote: >> On May 11, 2012, at 3:17 PM, Josh Thompson wrote: >>> >>> Kevan, >>> >>> Ugh. Thanks for looking at this. I guess it goes to show you can't just >>> trust that another project that says it is MIT licensed is *completely* >>> MIT >>> licensed. :( I'll figure out a way to deal with it. If it works out >>> that >>> bcpowmod.php and str_split.php are not actually needed, can I just remove >>> them? If so, do I need to document that modification somewhere? >> >> BTW, vcl/trunk/web/.ht-inc/phpseclib/index.html refers to PHP Secure >> Communications Library as LGPL-licensed. Which is contradicted by >> http://phpseclib.sourceforge.net/ >> >> It looks like our documentation comes from >> http://phpseclib.sourceforge.net/documentation/ -- I'd check with the >> phpseclib project. Seems to be their reference to LGPL is unintended or >> inconsistent. bcpowmod.php's LGPL license would seem to be a problem with >> this, however… >> >> --kevan > > After looking further, there are only two files (AES.php and Rijndael.php) > needed from the phpseclib project, and both of them appear as though they were > written to be able to be included by themselves (i.e. each one contains > information about the author, the project, and the license). Both files state > that they are MIT licensed and contain that license in them. Is it normal to > just pull in specific files from another project, or is it better to include > the whole project? First, I should say that all my comments are from a purely procedural nature… I'm not making any comments on the function. It's more "normall" to pull in whole projects. Certainly true when you're pull in as dependencies. Advantage is that as fixes are made to original library, you pull in as a dependency (and don't have to migrate any source fixes). More later... That doesn't mean that whole projects is "better". Both can be equally correct. In this case, only pulling in the two files would seem perfectly fine to me. Can I please ask that the LGPL files be removed from SVN immediately? Please treat this as a -1 on the original svn commit as the commit contains LGPL licensed code. Removing the offending files from svn will address my veto. As a (final?) piece of mentor education, see: http://www.apache.org/foundation/voting.html#votes-on-code-modification http://www.apache.org/foundation/voting.html#Veto > > My only other experience in including another open source project in one I > work on is from including the Dojo Toolkit with VCL. In that case, it seemed > to make the most sense to include the whole thing. Right. So, both techniques are used. Which is most appropriate, depends on the situation. > > License wise, it seems simplest to just include the two files in the release, > but I just want to make sure we do the right thing in respecting other open > source projects. In general copying code is less desirable than including released software from another project. A description of this practice (with negative connotations) would be "forking" (though forking usually refers to an entire project). In general, we'd prefer to collaborate with other projects, rather than copy their code. However, open source gives us the flexibility to choose. And we should feel free to choose what best fits the needs of the project -- taking all factors into account... In this case, we should definitely raise the licensing questions that have been raised with the phpseclib project (no matter how we resolve the issue). And, by the way, perhaps there was a mistake made and those files aren't LGPL -- we may learn something... --kevan
Re: MIT licensed source code
Just to ask the obvious Why not just use the openssl library for this?
Especially since the public and private keys are already being loaded in the
initGlobals() function. I know that it's interface is not nearly so nice, and
it doesn't support symmetric encryption for PHP <= 5.3, but here's some code
that could be dropped in place in utils.php:
function encryptData($data){
global $keys;
if(! $data)
return false;
openssl_public_encrypt(
$data,
$encrypted,
$keys['public']);
return trim(base64_encode($encrypted));
}
function decryptData($data){
global $keys;
if(! $data)
return false;
openssl_private_decrypt(
base64_decode($data),
$decrypted,
$keys['private']);
return trim($decrypted);
}
The other change would require modifying the initGlobals() function so that the
public/private keys were read earlier in the execution of the function, i.e.
before trying to decrypt a continuation value.
Aaron
--
Aaron Coburn
Systems Administrator and Programmer
Academic Technology Services, Amherst College
acob...@amherst.edu
On May 17, 2012, at 8:34 AM, Josh Thompson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday, May 16, 2012 10:37:02 AM Kevan Miller wrote:
On May 11, 2012, at 3:17 PM, Josh Thompson wrote:
Kevan,
Ugh. Thanks for looking at this. I guess it goes to show you can't just
trust that another project that says it is MIT licensed is *completely*
MIT
licensed. :( I'll figure out a way to deal with it. If it works out
that
bcpowmod.php and str_split.php are not actually needed, can I just remove
them? If so, do I need to document that modification somewhere?
BTW, vcl/trunk/web/.ht-inc/phpseclib/index.html refers to PHP Secure
Communications Library as LGPL-licensed. Which is contradicted by
http://phpseclib.sourceforge.net/
It looks like our documentation comes from
http://phpseclib.sourceforge.net/documentation/ -- I'd check with the
phpseclib project. Seems to be their reference to LGPL is unintended or
inconsistent. bcpowmod.php's LGPL license would seem to be a problem with
this, however…
--kevan
After looking further, there are only two files (AES.php and Rijndael.php)
needed from the phpseclib project, and both of them appear as though they were
written to be able to be included by themselves (i.e. each one contains
information about the author, the project, and the license). Both files state
that they are MIT licensed and contain that license in them. Is it normal to
just pull in specific files from another project, or is it better to include
the whole project?
My only other experience in including another open source project in one I
work on is from including the Dojo Toolkit with VCL. In that case, it seemed
to make the most sense to include the whole thing.
License wise, it seems simplest to just include the two files in the release,
but I just want to make sure we do the right thing in respecting other open
source projects.
Thanks,
Josh
- --
- ---
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
iEYEARECAAYFAk+08HIACgkQV/LQcNdtPQN8dgCdF/RaBttxHHuRMjuw73G9Kv34
RjYAnimOHe1R50N532Bgxi+uOjVnkgjv
=PjK8
-END PGP SIGNATURE-
Re: MIT licensed source code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, May 16, 2012 10:37:02 AM Kevan Miller wrote: > On May 11, 2012, at 3:17 PM, Josh Thompson wrote: > > > > Kevan, > > > > Ugh. Thanks for looking at this. I guess it goes to show you can't just > > trust that another project that says it is MIT licensed is *completely* > > MIT > > licensed. :( I'll figure out a way to deal with it. If it works out > > that > > bcpowmod.php and str_split.php are not actually needed, can I just remove > > them? If so, do I need to document that modification somewhere? > > BTW, vcl/trunk/web/.ht-inc/phpseclib/index.html refers to PHP Secure > Communications Library as LGPL-licensed. Which is contradicted by > http://phpseclib.sourceforge.net/ > > It looks like our documentation comes from > http://phpseclib.sourceforge.net/documentation/ -- I'd check with the > phpseclib project. Seems to be their reference to LGPL is unintended or > inconsistent. bcpowmod.php's LGPL license would seem to be a problem with > this, however… > > --kevan After looking further, there are only two files (AES.php and Rijndael.php) needed from the phpseclib project, and both of them appear as though they were written to be able to be included by themselves (i.e. each one contains information about the author, the project, and the license). Both files state that they are MIT licensed and contain that license in them. Is it normal to just pull in specific files from another project, or is it better to include the whole project? My only other experience in including another open source project in one I work on is from including the Dojo Toolkit with VCL. In that case, it seemed to make the most sense to include the whole thing. License wise, it seems simplest to just include the two files in the release, but I just want to make sure we do the right thing in respecting other open source projects. Thanks, Josh - -- - --- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk+08HIACgkQV/LQcNdtPQN8dgCdF/RaBttxHHuRMjuw73G9Kv34 RjYAnimOHe1R50N532Bgxi+uOjVnkgjv =PjK8 -END PGP SIGNATURE-
Re: MIT licensed source code
On May 11, 2012, at 3:17 PM, Josh Thompson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Kevan, > > Ugh. Thanks for looking at this. I guess it goes to show you can't just > trust that another project that says it is MIT licensed is *completely* MIT > licensed. :( I'll figure out a way to deal with it. If it works out that > bcpowmod.php and str_split.php are not actually needed, can I just remove > them? If so, do I need to document that modification somewhere? BTW, vcl/trunk/web/.ht-inc/phpseclib/index.html refers to PHP Secure Communications Library as LGPL-licensed. Which is contradicted by http://phpseclib.sourceforge.net/ It looks like our documentation comes from http://phpseclib.sourceforge.net/documentation/ -- I'd check with the phpseclib project. Seems to be their reference to LGPL is unintended or inconsistent. bcpowmod.php's LGPL license would seem to be a problem with this, however… --kevan
Re: MIT licensed source code
On Fri, May 11, 2012 at 3:22 PM, Kevan Miller wrote: > > On May 11, 2012, at 3:17 PM, Josh Thompson wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Kevan, >> >> Ugh. Thanks for looking at this. I guess it goes to show you can't just >> trust that another project that says it is MIT licensed is *completely* MIT >> licensed. :( I'll figure out a way to deal with it. If it works out that >> bcpowmod.php and str_split.php are not actually needed, can I just remove >> them? If so, do I need to document that modification somewhere? I took a look at the documentation for bcpowmod.php and it looks as if it is a straightforward fixed point arithmetic for doing a power and then a modulus. It shouldn't be hard to redo it *if* one isn't very concerned about execution time. (An example of doing this is in the last comment at http://php.net/manual/en/function.bcpowmod.php ) So the question is whether or not it is needed. --henry schaffer > > Removal would seem to be a great way to fix. I can't see any problems with > that. > > I don't see a need for any documentation (beyond an svn commit message), > unless it affects the behavior of VCL (something users need to understand) or > has potential ramifications for future development work… > > --kevan
Re: MIT licensed source code
On May 11, 2012, at 3:17 PM, Josh Thompson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Kevan, > > Ugh. Thanks for looking at this. I guess it goes to show you can't just > trust that another project that says it is MIT licensed is *completely* MIT > licensed. :( I'll figure out a way to deal with it. If it works out that > bcpowmod.php and str_split.php are not actually needed, can I just remove > them? If so, do I need to document that modification somewhere? Removal would seem to be a great way to fix. I can't see any problems with that. I don't see a need for any documentation (beyond an svn commit message), unless it affects the behavior of VCL (something users need to understand) or has potential ramifications for future development work… --kevan
Re: MIT licensed source code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevan, Ugh. Thanks for looking at this. I guess it goes to show you can't just trust that another project that says it is MIT licensed is *completely* MIT licensed. :( I'll figure out a way to deal with it. If it works out that bcpowmod.php and str_split.php are not actually needed, can I just remove them? If so, do I need to document that modification somewhere? Thanks, Josh On Friday, May 11, 2012 2:13:10 PM Kevan Miller wrote: > On May 11, 2012, at 12:36 PM, Josh Thompson wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > That's my fault. I'll take care of it. I knew I checked that the > > license allowed it to be included in a release, but I forgot about > > having to include it in the LICENSE file. Dojo Toolkit (Academic Free > > License and in LICENSE file), phpseclib (MIT licensed), and some of the > > Droid font (Apache licensed) are the only external code bundled with > > the web part of VCL. So, there won't be any other problems in there. > > Thanks. > > A more severe problem is > vcl/trunk/web/.ht-inc/phpseclib/PHP/Compat/Function/bcpowmod.php > > That needs to be addressed immediately... > > --kevan - -- - --- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk+tZbwACgkQV/LQcNdtPQOHFwCeNf2to2kR5eszZSULHRIkppyx /90AniWN5mAdlhPZGd1qKrWVpHx5STYi =3JGS -END PGP SIGNATURE-
Re: MIT licensed source code
On May 11, 2012, at 12:36 PM, Josh Thompson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > That's my fault. I'll take care of it. I knew I checked that the license > allowed it to be included in a release, but I forgot about having to include > it in the LICENSE file. Dojo Toolkit (Academic Free License and in LICENSE > file), phpseclib (MIT licensed), and some of the Droid font (Apache licensed) > are the only external code bundled with the web part of VCL. So, there won't > be any other problems in there. Thanks. A more severe problem is vcl/trunk/web/.ht-inc/phpseclib/PHP/Compat/Function/bcpowmod.php That needs to be addressed immediately... --kevan
Re: MIT licensed source code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 That's my fault. I'll take care of it. I knew I checked that the license allowed it to be included in a release, but I forgot about having to include it in the LICENSE file. Dojo Toolkit (Academic Free License and in LICENSE file), phpseclib (MIT licensed), and some of the Droid font (Apache licensed) are the only external code bundled with the web part of VCL. So, there won't be any other problems in there. Josh On Friday, May 11, 2012 11:55:13 AM Kevan Miller wrote: > Looks like there's some MIT licensed source code, but the LICENSE file does > not include the MIT license. For example: > > vcl/trunk/web/.ht-inc/phpseclib/PHP/Compat/Function/array_fill.php > > Any other examples of non AL v2 licensed code? Volunteers to fix? > > --kevan - -- - --- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk+tQBkACgkQV/LQcNdtPQNHkgCfT6fhfMLkqd7ihgfA7cMlBGgO LCAAnj3nj+7frG2rYOQGT0Kv1C2p/mYD =hxp0 -END PGP SIGNATURE-
