[Pykaraoke-discuss] Extended Debate

[John Schneiderman]

There's some debate here where I work about moving forward with the PyKaraoke
project. At this time nothing has been decided or set in stone. We want to
open up communications to see if our goals fit the community. We are looking
for a karaoke player that we can use in a professional capacity. To that end,
we have contributed several enhancements and bug fixes to this project. The
two major concerns we have are the usage of the LGPL for the GUI code, and
the lack of modularity in the overall architecture. The issue with the GUI
code being LGPL is the possibility of the company's work being used against
it to be built into a larger system. Though this was a concern even in the
beginning, it is increasingly becoming a sore spot as each new enhancement is
given. The other issue is the architecture of the system. It appears to be
more and more fragile with each new enhancement. The possible corrections for
this are to re-write/re-design the architecture itself. Once again, let me
say nothing has been decided. We actively wish to discuss these concerns and
see if any possible solutions can be made to address them.

Thanks,
John S.

[Tim]

Post by John Schneiderman
There's some debate here where I work about moving forward with the PyKaraoke
project. At this time nothing has been decided or set in stone. We want to
open up communications to see if our goals fit the community. We are looking
for a karaoke player that we can use in a professional capacity. To that end,
we have contributed several enhancements and bug fixes to this project. The
two major concerns we have are the usage of the LGPL for the GUI code, and
the lack of modularity in the overall architecture. The issue with the GUI
code being LGPL is the possibility of the company's work being used against
it to be built into a larger system. Though this was a concern even in the
beginning, it is increasingly becoming a sore spot as each new enhancement is
given. The other issue is the architecture of the system. It appears to be
more and more fragile with each new enhancement. The possible corrections for
this are to re-write/re-design the architecture itself. Once again, let me
say nothing has been decided. We actively wish to discuss these concerns and
see if any possible solutions can be made to address them.

I am not familiar with who all holds the copyrights to code in the
project, but if your worry is that someone will take this product and
compete with your company with the same code, then why don't you just
use a full GPL rather than the LGPL? It may seem counterintuitive at
first, but if a competitor did use it under the GPL, they're going to
have a harder time doing that and not releasing all of the rest of
their code along with it. There are plenty of companies out there
that make this model work.

As for the code's fragility, I can't really comment. A documented
modular design is always a good thing though.

tim

[John Schneiderman]

Post by Tim
I am not familiar with who all holds the copyrights to code in the
project, but if your worry is that someone will take this product and
compete with your company with the same code, then why don't you just
use a full GPL rather than the LGPL? It may seem counterintuitive at
first, but if a competitor did use it under the GPL, they're going to
have a harder time doing that and not releasing all of the rest of
their code along with it. There are plenty of companies out there
that make this model work.

That is the debate here actually. There is strong support for a full GPL, but
a lot of concern over the use of the LGPL for the GUI. Sorry, I should have
made that clear.

John S.

[Kelvin Lawson]

Hi John,

Post by John Schneiderman
There's some debate here where I work about moving forward with the PyKaraoke
project. At this time nothing has been decided or set in stone. We want to
open up communications to see if our goals fit the community. We are looking
for a karaoke player that we can use in a professional capacity. To that end,
we have contributed several enhancements and bug fixes to this project. The
two major concerns we have are the usage of the LGPL for the GUI code, and
the lack of modularity in the overall architecture. The issue with the GUI
code being LGPL is the possibility of the company's work being used against
it to be built into a larger system. Though this was a concern even in the
beginning, it is increasingly becoming a sore spot as each new enhancement is
given. The other issue is the architecture of the system. It appears to be
more and more fragile with each new enhancement. The possible corrections for
this are to re-write/re-design the architecture itself. Once again, let me
say nothing has been decided. We actively wish to discuss these concerns and
see if any possible solutions can be made to address them.

[John Schneiderman]

Interesting question.