Without a meeting today, it's probably best to bring this up on the list.
I know that we've been reaching out to upstream to get licensing problems fixed. The responses on the couple of threads I've seen seem generally positive about us providing the licensing audits, and have usually provided some idea of what's needed to fix the problem (at least in terms of scoping out the required changes). But they don't seem to always provide firm commitments to fixing the problems, as all the normal IRL rules apply. In other words, the upstream maintainer may simply be too busy to work on the solution.
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.
In other words, what I'm trying to avoid is blocking on upstream if this team has the capacity to fix these problems and send them patches.
Paul
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.
~spot
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.
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.
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.
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.
-Toshio
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.
On Wed, Jul 29, 2009 at 02:38:26PM -0400, Paul W. Frields wrote:
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.
I sent out a call for some PHP/JS help here:
http://marilyn.frields.org:8080/~paul/wordpress/?p=2651
I think that Simon from Zikula is on this list, but as Toshio said, we should reach out to the developers of each of the problem module to let them know what we're proposing to do, which is to take on the action item of ripping out license encumbered bits and replace them with functional equivalents that are GPL licensed. We'd love to have help from the upstream maintainers within the next several days, but failing that we need to commit to the work ourselves if we want to move it forward.
I think that Simon from Zikula is on this list, but as Toshio said, we should reach out to the developers of each of the problem module to let them know what we're proposing to do, which is to take on the action item of ripping out license encumbered bits and replace them with functional equivalents that are GPL licensed. We'd love to have help from the upstream maintainers within the next several days, but failing that we need to commit to the work ourselves if we want to move it forward.
I am on this list, and reading when I can. Apologies for my absence - as I suspected I am working long hours while away from home with limited access to my email. If you have any specific questions directed at me I'd ask that you email me directly, and I'll prioritise anything I receive in my inbox ahead of the mailing lists.
Simon
On Fri, Jul 31, 2009 at 09:35:05PM +0100, Simon Birtwistle wrote:
I think that Simon from Zikula is on this list, but as Toshio said, we should reach out to the developers of each of the problem module to let them know what we're proposing to do, which is to take on the action item of ripping out license encumbered bits and replace them with functional equivalents that are GPL licensed. We'd love to have help from the upstream maintainers within the next several days, but failing that we need to commit to the work ourselves if we want to move it forward.
I am on this list, and reading when I can. Apologies for my absence - as I suspected I am working long hours while away from home with limited access to my email. If you have any specific questions directed at me I'd ask that you email me directly, and I'll prioritise anything I receive in my inbox ahead of the mailing lists.
Simon, thanks very much for being around here. I think *our* next action is described above -- commit to fixing these problems ourselves. But if there's a general module maintainers list other than zikula-discussions to notify, maybe you could help us there.
Generally I think people on zikula-discussions agree that fixing licensing problems is good (albeit a royal pain). However, I don't know that any of the maintainers themselves have agreed to work on these problems in a way that will accommodate our schedule -- which is perfectly understandable. However, I'd like to at least pave the way for them to receive patches that will fix these problems upstream, since we try not to carry patches in Fedora for any longer than necessary.
Would we benefit from a blanket call for *anyone* in the Zikula community with PHP/JavaScript experience to help? I'm not sure anyone's made that request yet, but if you put your weight behind it, we might have a bit more luck!
Simon, thanks very much for being around here. I think *our* next action is described above -- commit to fixing these problems ourselves. But if there's a general module maintainers list other than zikula-discussions to notify, maybe you could help us there.
Most module developers are on the zikula-discussions list already, those that aren't are contactable through their project webpages. These are mostly hosted on code.zikula.org - generally, check out the wiki homepage for each project.
Generally I think people on zikula-discussions agree that fixing licensing problems is good (albeit a royal pain). However, I don't know that any of the maintainers themselves have agreed to work on these problems in a way that will accommodate our schedule -- which is perfectly understandable. However, I'd like to at least pave the way for them to receive patches that will fix these problems upstream, since we try not to carry patches in Fedora for any longer than necessary.
Summer is usually a bad time to catch Zikula developers. Normally we're all out doing stuff in summer :) If you add patches to a tracker though (and especially with patches, rather than bugs) I would expect to see them merged into the project's source control. Alternatively, request access to the project's source control - a lot of developers will be only too happy to have a hand.
Would we benefit from a blanket call for *anyone* in the Zikula community with PHP/JavaScript experience to help? I'm not sure anyone's made that request yet, but if you put your weight behind it, we might have a bit more luck!
I can give it a go - I can't guarantee a good response rate at this time of year though. How much help do you think you'll need?
Simon
logistics@lists.fedoraproject.org
-
Paul W. Frields -
Simon Birtwistle -
Tom Callaway -
Toshio Kuratomi