Re: [Pmw-general] Pmw status

[Friedrich R. <fri...@gm...>]

Hello Reinis,

2010/6/13 My Th <re...@gm...>:
> I actually saw the GitHub repo just after I wrote the post. It looks
> like there are some good changes in it. But what I would like to see is
> the official git source repo at SF and some releases, so that the
> changes get into distros.

I agree fully with you ...

> The program I'm working with bundles older version of Pmw and I would
> like to split it out and use system's version, but I see no point in
> doing so if distributions ship old/broken versions. Py3k thing is
> something for further consideration after existing bugs are fixed, but
> at some point I would like to switch to that (besides, there is already
> an open issue about this in Pmw tracker).

Ok, I think I can try to work on this.

>> > It is still in CVS repository. Have you considered moving it to
>> > something more usable like git?
>>
>> The thing is not decided yet.  In fact, pmw2 is already hosted on
>> Github, and I think, because the flow in open source is that someone
>> grabs the code, develops it, and posts it somewhere else, that at
>> least from my side future versions are likely to be put on github.
>> Now the others will chime in and tell that svn is fine and works well.
>>  And I have no problem with hosting the releases on Sourceforge.
>> Actually we want to avoid too much splitting since we do have not the
>> man power to efford that.  And documentation is still available only
>> via Sourceforge.
>
> I would like to see a repo at SF, because that would make releasing
> easier and Git, because it is way more convenient for me to work with
> (that would also allow to use Pmw as git submodule in external
> projects).

I also agree to that - what's the opinion of the others?  Btw, the
"git submodule" thing I don't know yet - how does it work?

> Another thing - I would really like that the existing project reaches
> version 2 (pmw-2.0) without changing name to Pmw2 unless there is very
> good reasons for doing so.

Hmm, as you can see from the git repo there has been done a major
restructuring of the file hierarchy.  From user feeling, nothing
changes at all, but since the file structure isn't compatible, I
called it pmw2.  But anyway, I think each user installs it only once,
so we can maybe stick to the Pmw name (although pmw2 was /the/ chance
to get PEP compliant in naming conventions ...).

> I actually have a question - what about that GPL to MIT transition I'm
> seeing at GitHub? Is it going to be official? How does it play with GPL
> projects?

Hmmm, afaik Pmw never was GPL at all, the license it's shipped with
should be http://pmw.sourceforge.net/doc/copyright.html .  We
abandoned that license since according to the former maintainer of the
project, this is permissible.  For me it was natural to choose not a
GPL license, since ... well, you can read
http://matplotlib.sourceforge.net/devel/coding_guide.html#why-bsd-compatible
.

For your application, which is assumed under GPL, a MIT project is not
a problem, as Python itself and also e.g. matplotlib are BSD-style.
Problems only arise if you want to incorporate a GPL project in a
not-GPL project, since this violates the GPL.  BSD-style licenses
allow sublicensing.

I understand the sentence:
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
in that way, that it deals with The SOFTWARE, which is in our case
Pmw, i.e., when one distributes Pmw with one's project, one has to
make sure that The Software is still under BSD-style, irrespective of
what the license of the full program is.  But I'm not a lawyer ...

Well I see there is some (nice) work coming ... :-)

Friedrich