[License-review] For Approval: Scripting Free Software License, Version 1.3.6 (S-FSL v1.3.6)

Engel Nyst engel.nyst at gmail.com
Sat Nov 9 00:46:09 UTC 2013


Hello Elmar,

I think you sometimes misunderstand copyright law, and misinterpret OSD. 
Let me point out a couple of core terms.

Disclaimer: I speak only for myself. I have no affiliation with OSI and 
I am not a lawyer; this has nothing to do with legal advice, nor any 
entity interests. Please note that I simplify the problems, in the 
interest of proper understanding on basics. I refer to OSD as well as 
make a couple of other considerations, in response to your statements in 
previous emails.


"Derived works".
The term in OSD refers roughly to derivative works under copyright law.
(cf. the Berne convention and US copyright law, at least; popular enough 
and public documents)

Your license tries to use the term "derived works" with a completely 
different meaning; it has no definition in the license, and an unclear 
"any diff that can be applied on the software".
Then you tried to argue that the terms are interchangeable and "fits OSD".

That's a logical fallacy. You can't use the term randomly then argue 
it's the same thing with the term in the OSD.

"Derived works" in copyright (and OSD) corresponds roughly to:
a) maybe certain "patches", but definitely NOT all;
b) "branches", the way your text uses the term, likely.

Example: I write code that calls a function in the program, in one line; 
and it has 3000 other lines of code, entirely written by me. The 3000 
lines are not a "derived work" of your program.
Only, perhaps the whole work (let us accept I add more lines that modify 
your program or the line was registering a hook), once distributed 
together, will be or will not become a derivative work under copyright 
law. The whole work is the "branch".

"License".
License means permission. Let us say, a copyright license is a text that 
grants certain copyright permissions under specified conditions. (give 
or take some amount of legalese)

conditions != restrictions [that prevent those permissions in the first 
place]

Now, let me read OSD #7.
"The rights attached to the program must apply to all to whom the 
program is redistributed without the need for execution of an additional 
license by those parties."
- the rights to distribute the software, to read it, to prepare 
derivative works and distribute them [OSD #1, #3], attached to the program
- must apply to all to whom the program is redistributed ([#5, #6] 
public or private, first downstream or the seventh)
- without the need for them to come back to you to ask for permission.

Formalized or not, badly written or nicely written, in a document or in 
a random email or on a page on the internet, a permission grant *is* a 
license.

If your text requires another set of permissions ("license") people have 
to ask from initial copyright holders, for the exercise of the very 
rights spelled out in other criteria, then it fails OSD #7. (and those 
criteria)

In my reading, OSD #7 is a good safety measure. It does not allow the 
text to try to bypass other criteria via sophistic requirements of some 
other "permission"/"consent"/"license" outside the text itself.

 > 6. You may choose to develop a different branch of this program any
 > time you want given that your new branch serves a new purpose or is
 > sufficiently different _so that the original authors do choose not to
 > re-integrate your branch_. [...] _Branched versions can not_
 > re-publish under a different license or _use patches_, patents or
 > other intellectual property _of the maintainers of the parent branch
 > in a new context unless explicit consent from the maintainers of the
 > parent branch is given_.

It's not clear to me what "a new context" means, what means "so that 
original authors do choose", nor what means they're forbidden to "use 
patches" without explicit consent. (if "patches" would be under S-FSL, 
it contradicts that branches are forbidden to "use" under S-FSL)

Do original authors have to "give explicit consent" for people to make a 
branch, integrate S-FSL code, or can they block/disprove the creation of 
a branch because they state it's not sufficiently different?
If yes, I think this new version still fails OSD #3 (and #7, likely #5), 
at least.

 >> If a new branch has to be "affiliated", in the sense that special
 >> permission has to be given for someone to fork the software, it's not
 >> open source.
 >>
 >> Please note, free as in free distribution or free software means
 >> free of the need to come back to someone and ask for more
 >> permissions. Free from the need to ask for (another) permission at
 >> all, in order to exercise a set of rights. The license should give
 >> those permissions already. Your goals and license seem to confuse it
 >> with an "I may allow you free of charge, but I keep control over
 >> whether I allow you to in the first place". That's not an open
 >> source license.
 >
 > No, to me it does not. It is not in the OSI criteria and I have
 > already explained on what I believe matters for open source. The
 > drop-to-the-community and forget it approach may be something to
 > dispose unused software; yet it just points to certain quality issues
 > and should not be considered a virtue.
 >

See above on OSD criteria. I just want to add a few comments on the rest 
of your statements. Please note that it is my opinion, and I speak only 
for myself.

I entirely disagree that an open source copyright license has anything 
to do with "forget it" and "quality issues". An open source license 
never forces your hand to "forget" anything, you never ever "lose" any 
ability to develop the software at any standards of quality you set for 
yourself and your work. It's meaningless to state otherwise.

What it does, however, has something in common with quality, but it's 
the other way around: when both the initial developers and anyone else 
in the community have the minimum rights (set in OSD) to develop the 
software at the standards they set for themselves and their work, then 
and only then there is potential for higher quality.

Because the initial developer may continue with others; or they may drop 
development; or they may lower their standards for some reason (not 
referring to you, but anyone); or their choices are debatable.
But if the community can take it and make it right, then and only then 
the *software* has the best chance to improve. It may or may not be the 
case of your software today as long as you're dedicated to it, but my 
personal belief is that it is the case of software when I look at years 
from today.

If you don't want to make a gift to the community, nobody can tell you to.
Please don't, however, confuse free and open source software with too 
much copyright control from one party to fit at least the minimum rights 
to *everyone* set by OSD.

In addition, my point here is: in the perspective of years from now, if 
the license for the software does not have the essential traits in OSD, 
then it keeps the software under copyright restrictions that, in my 
(strong) belief, will actually lead to lesser quality in time and, 
obviously, its eventual death.

There are not enough rights otherwise under current copyright law for 
the community to build it/on it safely under any circumstances, AFAIK, 
added to the confusion on what the text really means. Free/open licenses 
are usually no afterthought, they're proven to work.


That said. I'd make a couple more notes on the newer draft.

 > The maintainers of the original product or any of its branches may
 > any time transfer their rights to a new or extended group of people.
 > The new copyright holders can thereupon act as the original authors
 > or issuers of the branch called branch maintainers.

I think this is unenforceable and IMHO it doesn't really belong in a 
license; copyright holders "may" indeed transfer rights (as long as they 
haven't signed an exclusive contract on them), but this "may" is not a 
meaningful provision in a non-exclusive license. IMHO.

It doesn't fail OSD, it only brings some burden over the community to 
interpret another text.

 > share full intellectual property rights

This is, IMO, unenforceable in a simple license, and very likely to 
drive people away from your project(s). The term "full" and to one party 
is the problem here, not the rights or sharing. Any license exactly 
shares some rights (sub-rights of copyright), but this specific wording 
reads to me like you'd require shared copyright with you.
That doesn't work. You'd need a signed contract.

 > 6. The license should be compatible with the usage of patents and
 > trademarks without unloading that burden to the end user.

I don't think it is. "Branched versions can not [...] use patents [...] 
in a new context unless explicit consent from the maintainers of the 
parent branch is given."
Should I understand that consent has not been given for patents, thus 
the user cannot know if the maintainers have given it, or if the context 
is new enough for the maintainers' liking, or if they can branch on 
their own without being sued by the maintainers for patents?


I sympathize with your desire to draft a license for your needs, but I'd 
say license drafting is not easy, and has many traps. I strongly suggest 
to consider using a known license. Depending how I interpret your emails 
and license texts, it might come very close to GPL/AGPL, or a goal comes 
close to BSD/MIT (to relicense easily), or it might be very far from any 
open source license.




More information about the License-review mailing list