On 2007-03-05 17:28 +0100, Bernhard R. Link wrote:
>  Having things not mega-freezed means
> either having to watch for important changes (like, say,
> no longer starting in default configuration) throughout
> the whole year, or just throwing unusual stuff out of the
> supported pre-installed pool of software.

Having things not mega-freezed, means that the upstream doesn't
have to listen to complaints of _old development snapshots_ that
the upstream is no longer supporting. Get it? Not every software
release is a "stable" release that the upstream is willing to 
support for very long. During the process of trying to eventually
provide a stable release, you make "development snapshot" releases
for the users who want to be on the bleeding edge, but not directly
build from the version control systems.

That is the state of Ion3: development/unstable. Only an idiot would
provide it in a "stable" distribution. Ion2, on the other hand, is
"stable", and will not go through major changes. However, even Ion2
should be upgraded in distributions, if there's a new release (very
unlikely), because due to its "stability", any upgrade will be a 
rather critical fix.

Distributions should be attention to the stable/unstable state
of the upstream packages. If the upstream package is "stable",
then it can be included in the distribution's "stable" collection,
and the few upstream upgrades should also be safe to include
in an upgraded collection. If, on the other hand, the upstream
package is in "unstable/development" state, the distribution should
also only include it in an "unstable" extras collection.

I have been considering adding something like the following to 
the Ion3 license. If it is against the DFSG, well, the effect 
still be the intended.

---

This work, "Ion3", is licensed under the GNU Lesser General Public
License (LGPL), reproduced below, extended with the following
"Distributor timely response clause" (D).

  D. Anyone distributing Ion3 in aggregate with other works, must
     within twenty-eight (28) days from the release of a new version
     of Ion3, either (A) upgrade the aggregate to include the new
     version, and cause the new version be installed when a user tries 
     to install an unspecified version of Ion3, or upgrade Ion3 (from the
     aggregate); or (B) remove Ion3 from the aggregate, and notify users 
     of the removal, when they try to upgrade the aggregate or Ion3 (from 
     the aggregate) and have installed an old version of Ion3. (It is, 
     however, not necessary to remove Ion3 from the user's computer; 
     merely notify of its out-datedness.)

     The requirements above on responses to user actions do not apply,  
     if the user is not network-connected, or chooses to not use network
     upgrades, and is using physical distribution media.

     This clause does not bind any rebranded derivative works, that can
     not be confused with Ion3: that is, any derivative work whose name
     can not be confused with "Ion3", and whose listed maintainer (in
     the README) is different from that of Ion3, may be distributed
     under the LGPL or GPL without this clause.

---

So, if you're willing to take all the blame for the outdated 
development snapshots that you want to provide, just rebrand 
and start maintaining it yourself..

-- 
Tuomo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to