Licensing problems, solution strategy

[Paul W. Frields]

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.

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