sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- From: Remko van der Vossen <wich AT stack.nl>
- To: sm-discuss AT lists.ibiblio.org
- Subject: [SM-Discuss] ion spell license issue
- Date: Sun, 9 Sep 2007 12:43:09 +0200
Hi everyone,
Since a couple of releases, ion has a new license (attached below) which
basically says that if we are to name the program ion, then the version
in our grimoire should be updated to the newest release within a month
of availability. At the moment we still have a version of ion before
this LICENSE change in our grimoires, but the source tarball is not
available anymore, as the author only provides the tarball of the latest
release.
The reasoning, as I understand it, for this new license is that the
author wants to make sure that users always use the latest release and
do not report bugs or otherwise request support for older releases that
have already been fixed or changed by a newer release.
First question is; can we live up to this requirement? To answer this
question we first need to establish whether this requirement would
pertain to the stable grimoire, or test grimoire. As for actually
updating the spell, I think I can take care of this, I am on the ion
mailing list and thus get a notice whenever a new version is released,
though there might of course be some delay in updating the spell if I
were to be on vaction or some such.
The major problem with this in my view is that we would need to track
the responsibility. right now I use ion3 personally and am on the
mailing list, but what if I start using another window manager, or would
stop developing for SourceMage for whatever reason? The responsibility
would have to be taken over by someone else when appropriate, what if
there is noone willing to take it, what if noone thinks about it?
One other way to get around the whole thing is to fork each release
renaming the program and every occurance of it's name in it and it's
documentation (somewhat like SeaMonkey), but that would be quite an
effort for every update of the spell and not be in the spirit of
SourceMage in my view.
Any thoughts on how to approach this? The author does not keep old
releases available, so unless you have the tarball in spool the current
spell is useless.
Regards,
Remko van der Vossen.
----
Copyright (c) Tuomo Valkonen 1999-2007.
The code of this project is "essentially" licensed under the LGPL, version
2.1, unless otherwise indicated in components taken from elsewhere. It is
reproduced below. Additionally, the following terms apply to the use of
the name of the project, Ion(tm), names of particular "branches" such as
Ion3(tm), and other derived names:
If the name Ion(tm) or other names that can be associated with the Ion
project are used to distribute this software, then:
- A version that does not significantly differ from one of the
original author's versions must be provided by default.
- When there are no further prominent notices of possible out-datedness,
and no prominent original author's version qualifiers present (resp.
only branch qualifier is present), then the version distributed online
may not significantly differ from the original author's latest stable
release (resp. latest release on the branch) within a reasonable delay
(normally 28 days). The holders of physical distribution media must
be provided ways to upgrade to the latest release within this delay.
- Significantly altered versions may be provided only if the user
explicitly requests for those modifications to be applied, and
is prominently notified that the software is no longer considered
the standard version, and is not supported by the original author.
The version string displayed by the program must describe these
modifications and the "support void" status.
Derived works that do not satisfy the above terms must be renamed so
that they can not be associated with the Ion project, their executables
must be given names that do not conflict with the original author's
version, and this author may not be referred to for support.
Modules and other (standalone) extensions to Ion must also be named
so that they can not be confused to be supported by the original
author. If "Ion" occurs in the name, it must be in the form
"Foo for Ion" instead of "Ion Foo", etc.
This name policy notice may not be altered, and must be included in
any altered versions and binary redistributions. It may only be
removed when using small portions of the code in unrelated projects.
The original author and the Ion project retain the same rights to
your modifications that it would have under the LGPL or GPL without
these or similar additional terms.
If you fail to follow these terms, you lose the rights granted to
you by the LGPL.
Explanations:
Significant change: Bug fixes are a priori insignificant as additions.
Basic changes that are needed to install or run the software on a target
platform are a priori insignificant. Additionally, basic configuration
changes to better integrate the software with the target platform,
without obstructing the standard behaviour, are a priori insignificant.
Everything else is significant. The author reserves the right to refine
the definition of significant changes on a per-case basis. Please consult
when in doubt.
Distributions: For example, suppose an aggregate distribution of software
provides an `installpkg` command for installing packages. Then the action
`installpkg ion3` (resp. `installpkg ion`) should within a reasonable
delay install the latest release of Ion3 (resp. the latest stable release),
or prominently notify the user that the provided version is not or may not
be the latest. The action `installpkg ion-3ds-20070318` may at any date
install this particular mentioned release. Likewise, the action `installpkg
--support-void-featurex ion3` may apply additional patches to the latest
Ion3, within the further constraints set above.
The intent of these terms is to curb the power that "distributions", as
the primary sources of software for many users, have in defining what
is perceived as Ion. By providing significantly modified versions and
out-dated development snapshots without prominently mentioning this fact,
they do not present the work in a light that the author can agree with,
and create a burden of dealing with (new) users seeking for support for
such versions.
[SNIP]LGPL2.1 License[/SNIP]
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
-
[SM-Discuss] ion spell license issue,
Remko van der Vossen, 09/09/2007
- Re: [SM-Discuss] ion spell license issue, Andraž 'ruskie' Levstik, 09/09/2007
Archive powered by MHonArc 2.6.24.