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-alternativ...
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.
--
Paul W. Frields
http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - -
http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug