On Wed, Jul 29, 2009 at 09:00:08AM -0700, Toshio Kuratomi wrote:
On 07/29/2009 08:18 AM, Tom "spot" Callaway wrote:
On 07/29/2009 11:13 AM, Paul W. Frields wrote:
I propose that we simply make the rollout a first priority. If there are licensing concerns which must be fixed to install the application somewhere, then module owners must fix the licensing problems themselves (or find someone to commit to doing it within a specific time frame). If we're able to wait for packaging until some later time, then we install now, set a date where we will have all those problems solved, and start the process of fixing them.
Paul, in most cases, this simply isn't possible. We cannot relicense bits that we are not the copyright holder for, and it usually isn't trivial to simply remove bits under an unclear or bad license. When it is, we're already just removing those bits.
We can't carry bits under bad licenses while we wait for someone to resolve the issue. That's simply a showstopper, sorry.
Yes, keep in mind that I wasn't suggesting that we package anything without regard to licensing. Someone had suggested we might be able to have a temporarily installed instance for private testing, but that doesn't resolve the issues at all. One way or another we have to fix the licensing problems, so we can roll out a server. If we have to live with the test instance in a crippled form while we build it up to full capabilities, it's not a disaster. That might actually people to learn more about the innards in the meantime.
In a few cases, the incompatibly licensed bits may, in fact be optional. (scribite had several choices of editors of which some were compatibly licensed and some were incompatible). In those cases we cansimply remove the bits instead of waiting for upstream to do it for us.
I'm hoping that's the case more often than not, although I had a terrible time trying this with the Mediashare module. I suspect the majority of my problem is my own lack of clue.
In a few cases we may be able to replace the bits with bits that are licensed appropriately. That could be the case with the lightboxXL and jquery.popeye code... I haven't looked at the replacement or the original, though, so I don't know if they make any attempt at drop in compatibility.
I think "drop in" was an optimistic (and probably unrealistic) statement I made. I doubt it's drop in, although it might not be a huge amount of work to make the jquery.popeye code functional in this context.
In the remaining cases, we'll need to get commitment from some php or javascript programmers to do some work. A cattlecall might work (we have a lot of php and javascript developers using Fedora) but I've found that those are most effective when there's specific tasks that you can slot people into. This would be an example of a good request for help: "Fedora Docs needs a php-javascript programmer to port zikula-module-mediaattach from using lightboxXL to jquery.popeye: http://herr-schuessler.de/blog/jquerypopeye-an-inline-lightbox-alternative/"
In cases like this, it's also good to confirm with upstream that the work you are proposing is acceptable to them... it's just that they don't have the time to do it themselves.
Agreed.