Ion3 license violation

Philip Paeps philip at
Thu Dec 13 03:07:23 PST 2007

On 2007-12-13 10:54:47 (+0000), Tuomo Valkonen <tuomov at> wrote:
> On 2007-12-13, Philip Paeps <philip at> wrote:
> > I have not gone awol.  I replied to your email about the port being out of
> > date the day after you sent it.
> Closer to two days...


> > It is not particularly difficult to comply with the licence.  It just
> > takes a bit of time (which I'm happy to spend) to keep up with new
> > releases.  Of course, sometimes new releases will coincide with ports
> > freezes.  
> This time the thaw came quite in time (or did I cause it?-), and maybe the
> period could have been even a bit longer if people would communicate about
> such things.

I'm fairly sure you didn't cause the thaw. :-)

> However, there's still the problem of binary packages ending up in the
> release snapshots without prominent notices of obsoleteness.

The FreeBSD ports tree is not "pegged" to releases as in other systems.  So if
a -release user downloads a ports tree, he gets the same tree as someone who
is using -current.

You do have a point that "obsolete" versions will end up on the snapshots of
the ports tree on cds.  We have a perfectly good mechanism for dealing with
this, it's called NO_CDROM.  I would be happy to add this to the Makefile.

> I don't think RCs and development snapshots should end up there at all.

I don't share your opinion about RCs.  Regarding development snapshots,
however, the port was named 'ion3-devel' until the first RC - indicating quite
clearly that building it gave you software in development.  The only reason I
did the rename at RC-time was because I thought a release would happen 'real
soon' after.  It didn't.  Note that I'm not complaining about your release
schedule.  I should have waited with the repocopy until after the release.  My

> That's the problem with distros' megafreezes: you can't sync the development
> of thousands of packages. And as for stable releases, even they should get
> bugfixes promptly. Maybe the 28 day limit can be relaxed  in such cases a
> bit, but even half a year may be too long -- two years like with Debian is
> certainly too long.

I don't think there has ever been a FreeBSD ports freeze which lasted as long
as six months, let alone two years.  Generally a month or so is the order of

> It depends on the bug at hand: segfaults should be fixed very promptly,
> whereas minor glitches are not that big deal.

During ports freezes, approval from portmgr can be saught to fix things like

 - Philip

Philip Paeps                                    Please don't Cc me, I am
philip at                               subscribed to the list.

  BOFH Excuse #180:
    ether leak

More information about the freebsd-ports mailing list