Elmar Stellnberger <estel...@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] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87li13rbje.fsf@algernon.balabit
