Re: Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
Elmar Stellnberger <estellnb@gmail.com> writes:
> S-FSL v1.3.3 uploaded at http://www.elstel.org/license/
>
> Having clearly considered your critics I have published a reworked
> edition
> of S-FSL which should more strictly adhere to the terms of OSS-software.
> As you can understand and as I have already partially described there are
> still issues to me which discourage me from using an existing license like
> f.i. GPL or BSD.
I wouldn't mind hearing the full explanation, because I honestly see far
more issues with a new license than with using any of the existing,
battle-tested ones.
I will review the current (1.3.3) license, but that's about as much time
as I'm willing to spend on it. I would recommend getting your license
OSI[1] approved, to make things much easier for distributors like
Debian.
[1]: http://opensource.org/approval
So, about that review:
This program may be used free of charge. It has been designed as
research work and comes without claim for fitness to any particular
usage purpose and completely without warranty or any kind of liability
such as lost revenues, profits, harm or damage of any kind.
So far, so good.
The program may be distributed by a third party given that the program
is distributed in its original state completely without any kind of
modifications or patches.
This fails DFSG#3 and DFSG#4, but...
If you need to re-distribute a patched version of this program you
need to distribute the patches separately from the original so that
the pristine version can be restored at any time. Any derived work
must carry the name of the distributor, vendor or the product in its
name (or a unique shothand for it) preceded by the original unchanged
name of the software and its version.
With this clarification, it passes DFSG#3 and DFSG4, but only barely.
Modifications applied to this program may not affect the name,
original version, copyright or any reference given to the authors such
as their email addresses or their web presence and/or page in any part
of the program or any files attached to the program.
What exactly does this mean? Does that mean that if someone makes a
modification in form of a patch, he can't add his copyright to the
modified files? Or does that mean that they can't modifiy the original
copyright & license notes?
Or, another question: what if a software under this license is included
in something like Debian, where after the freeze, you're not supposed to
upload new versions of the software, but the upstream webpage moves, or
e-mail address changes, and for some reason, the maintainer wants to
correct that in the package. She then has to modify the email addresses
and URLs in the package, which would - in my reading - go against the
license.
You may only extend or modify this program given that you do also
consent with the following terms. As far as you are not a public
distributor you are oblidged to send a copy of your patches to the
original authors referred to herein as the authors of the first
version of the program as being listed in the changelog or program
header whenever you publish or exchange your patches with other
people.
This is against DFSG6: no discrimination against fields of endeavor. It
discriminates non-public distributors (whatever they may be), which
makes the license non-free at best.
It also is unclear about what a public distributor is (ok, that's
explained a bit better later, see my comments there). Consider that
Debian is not a legal entity, either. Software within Debian are
distributed using a mirror network, some of which are operated by
commercial entities. There are also private mirrors of Debian (my
company has one too, for internal use), which would not be able to carry
software under this license, since they're not public distributors.
In this reading, it's not ok for non-free, either, as it cannot be
distributed by Debian at all.
Also, the wording is unclear: "whenever you publish or exchange your
patches with other people" is very vague. If someone downloads the
patches from a mirror, that can be considered exchange. Do I, as a
distributor, need to send the same patch every time someone downloads
it? Do I, as a developer, need to send the patch every time I send it in
for internal review? Do I need to send work in progress patches too?
(It's a patch, and I'm sharing it with collegues, after all!)
That is unreasonable and unenforcable, and clearly goes against the
spirit of free software. Furthermore, trying to force out such strict
control of the software is very discouraging for potential contributors.
By distributing patches you do consent apart from this that the
original authors may incorporate your patches into future versions of
this program. The patched parts of the program and the patches
themselves will also become subject to this licensing and may even be
used for free in other programs or in the same program under different
licensing as soon as you choose to publish any kind of patch; i.e. you
need to be ready to share your full intellectual property rights with
the original authors whenever you choose to exchange, distribute or
publish any kind of patch to this program.
So, basically, by patching the software, I surrender my rights? Nope.
Not going to happen. That is not how copyright works. I can *choose* to
give up my copyrights, but no license can force me, or anyone, to do
that by default.
You can have a contributor agreement (which is what most people do, who
want tight control over their creation), but you can't make that part of
your license.
You can make a license that prevents anyone from distributing patches
without approval, but you can't have one that forces them to assign
copyright to you. Copyright law does not work that way.
The original authors will have to resolve whether to incorporate your
patches or not into future versions. Any contributer has the right to
be listed with full name, patching date and email address in the
changelog of this program. If you want to develop a separate branch of
this program the original authors need to give you permission.
Developing a separate branch means not to use the naming convention
proposed in the preceding paragraph.
So, if I want to distribute the program under another name, I need to
get permission. That is okay-ish, I suppose, but it sounds a bit iffy to
me, still. Although, the naming convention is a bit unclear to me. Does
it refer to the name of the tarball, the package name, or something
else? Because Debian *does* rename the tarball to
$project_$version.orig.tar.gz (from the usual $project-$version), and we
also add a debian specific version, which in a sense, changes the
version of the software. (foo_1.0-2 may have bugfixes over -1, which
touch upstream parts, not just packaging things, and so on).
The term 'public distribution' will in the following refer to any
public distribution available free of charge including updates
available free of cost.
Debian isn't such a distribution, so we do not get the benefits proposed
for public distributions, which makes the software under this license
unfit for Debian, even for non-free. We are not a public distribution in
this sense, because people are allowed to sell Debian CDs, for money
(and that's okay). We also allow private mirrors, and we have no control
over those - they may even sell their services, and that's okay too.
There are also derivative distributions which may not comply with the
above definition, so the license is definitely unfit for main. And I
very strongly believe it is unfit for non-free aswell.
The term distribution describes shipping of a given set of software
and potentially also its documentation with adherent materials.
This is still a bit unclear to me.
Availablity free of charge or costs includes tools, software and
manuals needed by an averagely technically experienced user to
download or obtain the distribution in a finally usable state as well
as the possibility to verify the integrity of the download securely
but not general connectivity to the internet.
What's an "averagely technically experienced user"? I would consider a
skilled Windows developer averagely technically experienced, but she may
not be able to install GNU/Linux software without a paid-for manual. I
would also consider a rocket scientist above averagly technically
experienced, but she may have no clue about installing software, either.
The term is far too vague.
And as such, violates DFSG#5: No discrimination against Persons or
Groups, as it discriminates people you may consider less than averagely
technically experienced. Thus, the license is unfit for main, and due to
the vagueness, remains undistributable in non-free aswell.
Distribution of the program by third parties must be done free of
charge apart from fees for the physical reproduction of the data
medium.
This is against DFSG#6, thus non-free at best.
Exception is given for selling xchroot as part of a public
distribution. Such a public distribution may be sold with additional
services such as support or the provision of information materials as
long as the whole distribution including updates can also be obtained
for free without these additional services.
This goes against DFSG#6 too.
Additional services with costs may even include commercial,
proprietary or any other kind of software as long as there is no
direct interrelation between the proprietary or commercial software
and software licensed under S-FSL. Direct interrelation means that
software under S-FSL would either be used as or in a component,
plug-in or add-on of the proprietary software or that software under
S-FSL is required to run the proprietary software not being available
free of charge.
DFSG#6 again, and also DFSG#9, as the license here is placing
requirements on other software distributed together with it.
Such a direct interrelation would require that you will either have to
pay for shipping programs licensed under S-FSL or put the whole
product under an OSS-compliant license which will make your product
available free of charge.
FYI, OSS compliant does not necessarily mean you have to make it
available free of charge.
Note that the terms for additional services stated herein will no more
be required as soon as the program is accepted by a public
distribution.
Since the public distribution definition is not exactly clear, this part
of the license if pretty meaningless.
A regulatory framework for acceptance as OSS-compliant license may be
found at http://opensource.org/osd.html. A license may be deemed
OSS-compliant if it has at least been accepted in the OSS (i.e. Open
Source Software) section of any public distribution in addition to the
compliance with the terms stated by opensource.org.
If any of the terms stated in this license were not in accordance with
local law all other parts of this license should remain valid. If any
of the terms about sharing patches should be deemed invalid modifying
the software and sharing patches shall no more be granted from the
time of the realisation of the decision of the court on in the given
country or region; already shared and incorporated patches are still
subject to the given terms and conditions as far as deemed valid; the
license needs to be re-issued then in order to allow further
modifications and sharing of patches again.
This part is a bit over my head, but the above comments should be enough
to highlight to you how difficult it is to write a license. Do yourself
a favour: don't do it. I mean it. You'll save yourself a lot of headache
if you use an existing license that's close enough to what you want.
For distributors, it's easy: if the license is too much effort to
review, we'll just ignore anything released under it and not allow it
in, that costs us pretty much nothing.
--
|8]
Reply to: