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

[Elmar Stellnberger]

Am 07.11.2013 20:21, schrieb Thorsten Glaser:
>
>> 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.
That is right. I wanna have a license that should suffice the need of all
parties or at least will be acceptable to them.

>
> (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.
That should be resolved in the new upcoming S-FSL version 1.3.6.

>
>> "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).
Well we could crop out this special facilitation but that would make
the license less fit for practical purposes. I do not want to sacrifice
practical fitness towards perfectly strict OSI compliance.

>
>> 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.)
No back-stabbing changes on copyright notices should be required.
If a certain level of tradeoff in this area can not be achieved then
you will have to package as non-oss.

>
>> 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.
should be improved in the upcoming 1.3.6 revision.

>
>> 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.
Well it does. By changing any part of the program you will specify
implicit consent with the terms stated in the license. It has been
proven to work for the DEC SRC M3 license and it will work on
S-FSL too.

>
>> 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…
I hope it will not be necessary to define what a patch is.
Well and I do not want to talk about compilers because
that is in some of a way too specific for my needs. It
was one of the design goals of that license to protect
software which is not compiled in the same way as
other.

>> Contracts with the authors of the patches?
That is not viable in practice. I will simply dump any patch like this
or disallow your contribution! The license is here to assert that
this is not necessary.

>
>>> But in Open Source, the right of the user to fork the code (e.g. if
>>> they disagree with upstream) is basic.
>>
improved in the upcoming revision v1.3.6.