FWIW, the GMane thread view for the Debian bug on this is:
http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/1099104
The bugreport is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728716
although I’d have put it into the ITP bug #721447 instead.
Elmar Stellnberger dixit:
>> What about binaries?
>
> such as python, bash or perl. As the license says nothing about binaries I
> would presume that it is not forbidden to derive such binaries as long as the
No, binaries are derived works.
> However at some point we do strongly recommend to get all changes incorporated
> into the main line. I believe it would really become a problem if the software
> is unmaintained or incompatible upstreams. However for this case we can either
This has led to catastrophes, but also to improvements (full forks).
I think you’re too restrictive here, especially for the all of the
OSS ecosystem.
> one; not which one. The way I conceive things it is a right of the user to
> know
> who has changed what. Everyone who does a change to the software will be
There’s CVS for it ;)
> and drop everything to the community we have a huge quality problem as no one
> feels responsible for the outcome.
I don’t think forcing people like this would help.
[ desert island ]
> As far as I have studied law if there is a force majeure that prevents you
> from
> notifying the original authors or if there is some unreasonable burden to do
> so
> then you do not need to do that. - and on a desert island force majeure is
Yes, but this is a metaphor for less “majeure” things. Please do not
assume special provisions for the “desert island”, otherwise the test’s
metaphor will obviously fail – it’s used to help comprehend the issue
*behind* the test, not for its own good.
> upstream party will thus be o.k.. Note also that public distributors do not
> need to notify at all; only 'closed' distributions which obfuscate their
> sources need to. Consequently I would regard this as minor infringement.
You don’t define “public distributors”, and this will make some parts
of the licence specific to certain people _and not their downstreams_
which is an issue.
[…]
> program and finally coded it in the first place. Invention includes primary
> requirements engineering. S-FSL assumes a proper software engineering and
[…]
I think your ideas are really right, but trying to put them into
this form will not work out.
People do get along with the already-approved licences plus *asking*
(but not legally requiring) to e.g. keep the “powered by FusionForge”
comment on the output HTML, plus *reminding* people that things used
in academic papers *must* be cited/acknowledged properly and that
this-and-that is the correct citation for this piece of OSS software.
For this, these things do not need to be in the licence.
And, I think removing copyright/authorship remarks is not legal either
so it doesn’t need to be explicitly required (maybe mentioned, sure).
> group denominated as new copyright holders. The bottom up development approach
> that is 'hack and drop to the community' is the way I believe rarely a good
Sure, the hack’n’drop is bad, but:
Please do not put all bottom-up development into that category though.
I find bottom-up SWE (after designing, of course) very nice for smaller
things, basically where you can have an idea in your head.
(But this is going off-topic.)
> starting point for high quality assurance.
IMHO this doesn’t belong into the licence. Maybe in an academic or
commercial environment, yes, but definitely not in OSS.
> Also the design of the initial
> inventors should be followed by later contributors.
This is a point I am prepared to vehemently disagree, by pointing
out that some peoples’ designs just suck. You may not fall under
it (I’ve looked at your website to see what the programs mentioned
are, but not at the code itself), but I know others who most certainly
do. (Incidentally, they seem to end up at RedHat.)
> My argument against this is that patches for my software can not be produced
> without my software
Forward ed(1) diffs with no context can. (Mostly §24 UrhG which is
especially interesting for Fanfiction, not so much for software.)
Parts of the new code may need to be written in order to fit with
the existing code, but that’s just interfacing.
> and are thus to be regarded as derived works.
And here we also disagree: if forward ed(1) diffs can be works
of their own, so can be unified/context diffs iff the country
in question permits “fair use” (Germany doesn’t but the USA do).
> It can never be seen independent from the program it was designed to
> patch because otherwise it would be meaningless.
Leaving mathematic terms aside (I tried hard to forget them and
am in no particular mood to figure out which ones to use), yes,
a “patch” can contain (and thus be) an independent work; for
example something written for another program and then just
fitted to match the interfaces of yours. (This is, incidentally,
the reason nobody can legally go after the multi-platform Nievida
graphics driver in Linux, no matter how much they want to.)
> ... 'ouch-y' but actually necessary to re-license at a given later point in
> time. It was the intention of the license designers to make this possible.
Indeed, but – as others also pointed out – you need a much stronger
contract for this, and you cannot simply require this of all patches,
only for those steered your way with intent to accept them upstream.
I know (from further above) that you always want that, but in practice
this doesn’t work out (the “desert island” thing, and because upstream
and downstream can and will disagree over whether to use a given patch
or not).
> Consider my previous argument that it should be possible to license as S-FSL
> in
> a first place when publishing the first time and re-license later on under any
> OSS license you want.
Sure, but you need actual contracts for this, properly. You’d just
only need to accept patches from people who signed them, or trivial
ones (over which nobody can prevent you from relicencing).
> You may need it as soon as you develop something that is sufficiently
> different
> from the main branch and want to give it its own name. The idea behind it is
> that the original authors will have to decide whether they want an own branch
> for it or include the given features into main.
But in Open Source, the right of the user to fork the code (e.g. if
they disagree with upstream) is basic.
bye,
//mirabilos
PS: My eMails to the OSI mailing list (which, incidentally, is the only
OSI list not also on GMane) also are delayed by a day or so, that’s
apparently normal.
--
21:26⎜<cnuke> cool cool, pitch ist zu hoch
21:26⎜<cnuke> eingebauter chipmunk modus in dragonfly bsd │ I luv it ^^
21:31⎜«yofuh» ich glaube ich wuerde den rechner aussm fenster werfen,
⎜ wenn er beim booten das chipmunks intro spielt
--
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/pine.bsm.4.64l.1311071730340.18...@herc.mirbsd.org
