Bug#728716: [License-review] For Approval: Scripting Free Software License, Version 1.3.5 (S-FSL v1.3.5)
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.
Reply to: