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

[Thorsten Glaser]

Elmar Stellnberger dixit:

> Yes, they are and the license does currently not give any restriction about
> them

Except for forbidding them all, because patches must be distributed
separately, and distributing patched versions is forbidden.

> However it is not an OSD criterium

Independent on whether it is or not (it’s not explicitly listed, as are
other things people have commented on, but some of these things can be
inferred from the OSD), I said in my first eMail that I’d do a general
comment on the S-FSL, no (pure) OSI review.

(For that matter, I’m also lead developer of both a BSD and a GNU/Linux
distribution, *and* a Debian Developer, too, that’s why I have feet in
multiple camps.)

> However if there is some
> broader effort to establish new features I would simply consider it good style
> to notify the upstream maintainers. The software below could change.

I agree, but it’s much better to just _request_ it. Sensitive people
will upstream their patches anyway (if upstream is reachable), since
not doing so massively increases maintenance burden, especially when
keeping up with active upstream development.

> "specific to someone": Well this is an unavoidable necessity in order to

Maybe, but specific clauses like this clearly violate OSD #3 and #5
(#3: if your downstream “A” is a “public distribution” and A’s
downstream “B” isn’t, B cannot distribute them under the same terms
as it got them from A under).

> Someone who obfuscates his modifications can hardly claim possession
> on my work.

Of course not, only on their changes, but that is generic.

> move it to another place; i.e. from the help->about menu to some obfuscated
> place which should not happen either

That will make it a forbidden invariant section. You cannot, in OSS,
prevent people from doing so, period. (In this case you’d probably
be better off with the GNU AGPL, because it does what-you-really-want
in a more OSS way than what you’re trying to do.)

> development. Top down in its primary sense simply requires some sort of
> privileges and control.

But too much of it and you can’t call it OSS any more.

> That is where I argue with homomorphism. You can strip a full context diff into
> a no context diff. Consequently the no context diff is a derived work of the
> full context diff.

Oh, but copyright law does not work this way. For example, I own all
of my (copyrightable) sentences in this eMail that I wrote, but none
that you wrote. You own all those you wrote, but none that I wrote.
If someone cites a sentence I wrote in this eMail, it doesn’t mean
you’ve got any rights in the thing that other person writes citing
my sentences.

>> in question permits bsee the homomorphism and transitivity issue: A derived

I seem to be unable to read your eMail, can you please configure your
MUA to send as quoted-printable or base64 instead of 8bit because at
least on of the mail servers between your MUA and my inbound MTA is
violating the SMTP standard?

(And while at it, *please* wrap your lines at, at most, 72 columns.)

> If it is independent work I believe it should be distributed as such.
> i.e. as standalone file rather than as a patch.

In your scenarios, patches are standalone files.

> To me a patch is something that refers to the part which is to be patched.

Ah. That’s a rather narrow definition. I have a combination of a
Debian source package (with all red tape this requires) whose
debian/rules unpacks a *.deb then runs forward ed(1) diffs on
the contents and regenerates some things like md5sums then
repacks it. The debian/rules script is a patch, as are those
forward ed diffs. Yet, they are not derived works of the .deb
that’s binpatched, only the result is.

Hm. Actually, maybe the better term for these is “compiler”,
as this sounds awfully like what gcj does when compiling
*.jar files into *.so DLLs. But it’s still oftentimes referred
as patch…

> Can you explain it any further why it won`t work in practice?

There are packages whose distributors carry patches rejected
by upstream, over a disagreement.

> Contracts with the authors of the patches?

Yes.

> I think S-FSL as well as the DEC SRC
> M3 license make sure this is not required because it may not be possible to ask
> any contributor with hindsight. They need to agree in advance or work on their
> own branch possibly with other license.

That makes these things non-free, too.

>> But in Open Source, the right of the user to fork the code (e.g. if
>> they disagree with upstream) is basic.
> I doubt whether this is enforced by the OSD criteria #1-#10. You could deem it

“The license shall not restrict any party from selling or giving away
the software” plus “The program must include source code, and must
allow distribution in source code” plus “The license must allow
modifications and derived works, and must allow them to be distributed”
and OSD#4 doesn’t permit the author to restrict downstreams from
distributing patches *and* patched versions.

In this case, yes, the right to fork is written in the OSD, and this
part is an explicit OSD analysis ☺

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜<thkoehler:#grml> also warum machen die xorg Jungs eigentlich alles
kaputt? :)    15:49⎜<novoid:#grml> thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?	-- ~/.Xmodmap wonders…