Licensing problems, solution strategy

[Paul W. Frields]

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.

-- 
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