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

Elmar Stellnberger estellnb at elstel.org
Tue Nov 12 13:10:38 UTC 2013


> >
> > 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.

   What I do see so much about open source software is that things were 
working right in the first place but then were broken by other 
developers. Some people come to fix it and a few weeks later the feature 
is broken again. I do see it every day as a tester. Believe me Linux and 
all of what is known as open source would be the best operating system 
ever invented featuring the best applications ever had if it did not 
have these quality issues. I personally can not recommend Linux or much 
of what is called open source to the casual user as they will not know 
what to do when their software fails. Furthermore it costs a lot of time 
if something does not work in practice. Believe me OSS software would 
play a predominant role also for end users, not just for companies who 
have experts to work with that software if it did not have these quality 
issues. These issues are not a problem for experts as said as they may 
be able to fix something on their own. However it is a no-goer for the 
average user or people who do currently develop in another area.
   People do not feel responsible and do not care to break things. That 
is the issue. Not the license. I do not claim that these things will be 
resolved by a new license. However I believe it could help in some sort 
of way as S-FSL explicitly mentions a group of people responsible for 
its reliability and quality. I don`t see much good in the 'do to it what 
you want' motto. Yes you can. However if you do then mark it as your own 
derivate and do not sync it into main without anyone else having an eye 
on it and even more important without any one else doing all the QA work 
for you: i.e. re-test all use cases that could be affected by your changes.
   Consider also that there may be a group A of developers and some 
contributors C. If there are f.i. some malicious contributors who add 
security relevant backdoors into the code they can re-add their 
backdoors modified whenever A has a fix for them. Note that the sets A 
and C may not be known and that some of these developers may also hide 
in A. The problem is that there is no responsibility for breaking code 
and that those who broke it will not be traced down with current OSS. 
You have even suggested me to drop the changelog which is a minor issue 
but points out clearly how you think about it.
   I do not claim that there were less security issues with proprietary 
software. It is usually closed source, no one can read it and people can 
be corrupted or blackmailed more easily. Why not have a software that is 
OSS (and yes I would claim S-FSL OSS) but allows clear responsibility 
issues about developers. You may not like it and even proprietary 
developers try to exclude from compensation but that is not the point. 
You need at least some place to define responsibility issues and why not 
give those who are responsible for their software some additional rights 
(and my license proposal does not do more than that).

>
> 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.

  If those who are/feel responsible for the software do not wish to keep 
their responsibility they can denominate another group of 'copyright 
holders' (though you may not like that term either) or you may 
re-license at any time to devolve all rights to what is called the 
community.


>
> 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.
   If you want more community contribution then update to v1.3.6 is 
recommended because it allows free branching under reasonable conditions 
without having to ask for permission. That way the software should still 
be maintainable without any restriction even if those who were 
responsible for it in the first place do neither delegate their 
responsibility to someone else nor do unleash their software to the 
community. Sometimes it will help just to ask the maintainers or to 
write them an email ;). I don`t like people doing something behind my 
back. It is not good style. You should try to talk with people in the 
first place rather than just starting your own things. That may help you 
for yourself as well, it may prevent incompatibilities, confusion or 
double-work that could be more fruitfully invested in another way.












More information about the License-review mailing list