10:13 a.m.
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
10:18 a.m.
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
11 a.m.
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-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.
-Toshio
1:38 p.m.
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
2:30 p.m.
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-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.
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
3:35 p.m.
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
6:36 p.m.
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!
--
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
10:51 p.m.
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
5377
days inactive
5382
days old
logistics@lists.fedoraproject.org
7 comments
4 participants
participants (4)
-
Paul W. Frields -
Simon Birtwistle -
Tom Callaway -
Toshio Kuratomi