- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
systemd row ends with Debian getting forked
|
|
|
Comments (41)
A non-programmer's hypothesis "confirmed"
19 earlier comments in the full thread.
@linux4567:
No. It does matter who the copyright owner is... and this is one reason Debian did not choose Upstart -- the copyright assignment required by Canonical.
The copyright owner may change the license of the software, and many do... especially the smaller startup ISVs who release code as FOSS to get started. Copyright ownership matters. And if Red Hat actually wanted to 'control everything via systemd' they would require copyright assignment.
EDIT:
See here: https://wiki.debian.org/Debate/initsystem/upstart
No. It does matter who the copyright owner is... and this is one reason Debian did not choose Upstart -- the copyright assignment required by Canonical.
The copyright owner may change the license of the software, and many do... especially the smaller startup ISVs who release code as FOSS to get started. Copyright ownership matters. And if Red Hat actually wanted to 'control everything via systemd' they would require copyright assignment.
EDIT:
See here: https://wiki.debian.org/Debate/initsystem/upstart
Okay.....we now get to the point where we know that systemd is issued under the GPL. Poettering wrote the software and holds the copyright, but that copyright is subject to the prescriptions of the GPL and therefore the source code of systemd is open to anybody to modify without Poettering's approval, provided that they then release the modified systemd under the GPL. Fine. But we had to fight to get to this point and it's both distracting and time wasting in that it was suggested that Poettering "owned" the code without stating the rest of the facts as they applied to the GPL.
@me1010.......I disagree with you completely over the forcing of systemd onto the Linux community by Red Hat. The proof is in what you see happening - Red Hat is implicitly forcing the code by its community leverage and by the fact that it is now being added and abetted by its major DM, Gnome. Of course there is no statement out of Red Hat (or Poettering) saying "Linux community, you WILL use systemd, or we have ways of making it so darn hot for you with broken routines, that you will be very sorry you ever tried to stop us.".....but the practical effect of what they are doing is just the same. systemd is steadily encroaching on other initialising routines (and that is well documented by others) and if you don't use systemd, you can be in big trouble and be forced to rewrite considerable software. The biggest mistake was for Debian to move and I understand there were successive challenges to that decision and eventually culminated in the fork.
Thanks linux4567.......I sometimes wonder if I am barking up the wrong tree, but it's very nice to know others think the same way too.
@me1010.......I disagree with you completely over the forcing of systemd onto the Linux community by Red Hat. The proof is in what you see happening - Red Hat is implicitly forcing the code by its community leverage and by the fact that it is now being added and abetted by its major DM, Gnome. Of course there is no statement out of Red Hat (or Poettering) saying "Linux community, you WILL use systemd, or we have ways of making it so darn hot for you with broken routines, that you will be very sorry you ever tried to stop us.".....but the practical effect of what they are doing is just the same. systemd is steadily encroaching on other initialising routines (and that is well documented by others) and if you don't use systemd, you can be in big trouble and be forced to rewrite considerable software. The biggest mistake was for Debian to move and I understand there were successive challenges to that decision and eventually culminated in the fork.
Thanks linux4567.......I sometimes wonder if I am barking up the wrong tree, but it's very nice to know others think the same way too.
@Ridcully:
Correlation does equal causation. Simply because non-RH distros are adopting systemd does not prove that RH is controlling the choice of init via systemd. You've placed intention where there is none.
The 'time wasted' on GPL, copyright, and licensing is not wasted at all. It should be very clear to those who may be following the argument that copyright implies control -- and thus the copyright owner is the controller -- and in systemd's case that controller is not Red Hat.
Forked GPL code still requires copyright statements. You don't need a separate permission, as permission is granted in the GPL. However, the copyright owner may still decide to change licenses for all future releases. So, in a very real way, if you use FOSS you are always at the mercy of the copyright owner whomever that may be -- unless you are very good programmer and keep your own software stack.
EDIT:
Actually I was wrong about Poettering being the copyright owner. He is the owner of a significant portion of the code, however -- Intel does in fact have its stamp on several header files. And there are other authors too... However, there are very few Red Hat copyright notices within the source tree. So, actually the statement: Intel is pushing systemd. is more correct than: RH is pushing systemd. However, neither is truly accurate.
Correlation does equal causation. Simply because non-RH distros are adopting systemd does not prove that RH is controlling the choice of init via systemd. You've placed intention where there is none.
The 'time wasted' on GPL, copyright, and licensing is not wasted at all. It should be very clear to those who may be following the argument that copyright implies control -- and thus the copyright owner is the controller -- and in systemd's case that controller is not Red Hat.
Forked GPL code still requires copyright statements. You don't need a separate permission, as permission is granted in the GPL. However, the copyright owner may still decide to change licenses for all future releases. So, in a very real way, if you use FOSS you are always at the mercy of the copyright owner whomever that may be -- unless you are very good programmer and keep your own software stack.
EDIT:
Actually I was wrong about Poettering being the copyright owner. He is the owner of a significant portion of the code, however -- Intel does in fact have its stamp on several header files. And there are other authors too... However, there are very few Red Hat copyright notices within the source tree. So, actually the statement: Intel is pushing systemd. is more correct than: RH is pushing systemd. However, neither is truly accurate.
> Linux is open source.. So fork it and do what you want. Or use the fork these guys create. Then we can see who wins in the end.
Oh, I will. The one thing that these discussions have convinced me of is that I want nothing to do with systemd. If necessary I'll be looking at the BSD's. Systemd is far too reminiscent of early KDE4 for my taste.
Oh, I will. The one thing that these discussions have convinced me of is that I want nothing to do with systemd. If necessary I'll be looking at the BSD's. Systemd is far too reminiscent of early KDE4 for my taste.
@me1010........The distros are adopting systemd because they have to......are compelled to......I cannot make it clearer. We are wasting time here. You are playing semantics. By employing Poettering, encouraging him in his work, by seeing Gnome fall into line given that Gnome is Red Hat/Fedora's default DM, Red Hat is implicitly cooperating in seeing that systemd is adopted as widely as possible. I direct you once again my to my statement above in inverted commas which says:
Of course there is no statement out of Red Hat (or Poettering) saying "Linux community, you WILL use systemd, or we have ways of making it so darn hot for you with broken routines, that you will be very sorry you ever tried to stop us."
Also as my final comment, no users or systems administrators have ever been this upset before in my experience and their concerns are already widely documented. I don't have to repeat them. The mercy of the copyright owner under the GPL is a theoretical one only; it has no practical value provided the programmer obeys the strictures of the GPL, and if you as a programmer, pick up GPL'd code to modify, you automatically know you must obey the GPL rules - or pay the penalty....again, your writing is a red herring.
I don't think I need to continue this debate. I have said all I need to say except that systemd is now an unhappy blot on the overall structures of Linux - but Red Hat is happy, and is in control, and that's really what this is all about.
Of course there is no statement out of Red Hat (or Poettering) saying "Linux community, you WILL use systemd, or we have ways of making it so darn hot for you with broken routines, that you will be very sorry you ever tried to stop us."
Also as my final comment, no users or systems administrators have ever been this upset before in my experience and their concerns are already widely documented. I don't have to repeat them. The mercy of the copyright owner under the GPL is a theoretical one only; it has no practical value provided the programmer obeys the strictures of the GPL, and if you as a programmer, pick up GPL'd code to modify, you automatically know you must obey the GPL rules - or pay the penalty....again, your writing is a red herring.
I don't think I need to continue this debate. I have said all I need to say except that systemd is now an unhappy blot on the overall structures of Linux - but Red Hat is happy, and is in control, and that's really what this is all about.
@Ridcully:
OK... you have your opinion on systemd, real or imagined, and there is no way to convince you otherwise.
However, you've missed the mark on the GPL. The power of the GPL is the ability to give source code without giving up authorship. It is not a theoretical point. The following example happens all the time... A given program is released as GPL... it builds a market share... the copyright owner switches from the GPL to a commercial license. The more common method -- because end-users may not like the bait and switch -- of extracting cash from GPL or other FOSS-ware is through proprietary add-ons. Similar to RibbonSoft's QCAD's DWG add-on [damn them to hell for that!] ...
OK... you have your opinion on systemd, real or imagined, and there is no way to convince you otherwise.
However, you've missed the mark on the GPL. The power of the GPL is the ability to give source code without giving up authorship. It is not a theoretical point. The following example happens all the time... A given program is released as GPL... it builds a market share... the copyright owner switches from the GPL to a commercial license. The more common method -- because end-users may not like the bait and switch -- of extracting cash from GPL or other FOSS-ware is through proprietary add-ons. Similar to RibbonSoft's QCAD's DWG add-on [damn them to hell for that!] ...
Whoa back, me1010........if something is released under the GPL, it is irrevocable as far as I am aware. It is possible to have add-ons which are personal property and not part of the original GPL'd release, but my understanding of the GPL is that once software is released under that licence, that is where it stays........it cannot be taken back. Here's the reference:
http://www.rosenlaw.com/pdf-files/Rosen_Ch06.pdf
http://www.rosenlaw.com/pdf-files/Rosen_Ch06.pdf
@Ridcully:
You are thinking of the end-user... or the licensee. My statements refer to the author/s. And the authors listed in the copyright statement of GPL code are free to choose any new license he/she/they wish for any future code based on the GPL code he/she/they released.
It is true that in many cases there are many authors, and permission must be given by all authors in order to change the license. This is why Canonical contributors complain about the requirement for copyright assignment. If you contribute GPL code to a Canonical copyrighted project, you are required to forfeit your say [yea or nay] in changing the license from GPL to commercial. This is one reason I do not use Ubuntu.
Ref: I'm sure there's a better reference... but I'm too lazy at the moment:
http://stackoverflow.com/questions/9116172/gpl-and-lgpl-to-commercial
maybe wikipedia too...
https://en.wikipedia.org/wiki/Business_models_for_open-source_software#Re-licensing_under_a_proprietary_license
Meaning: Your own software can be re-licensed proprietary and also then combined with other people's FOSS if that other FOSS uses a 'permissive' open source license.
You are thinking of the end-user... or the licensee. My statements refer to the author/s. And the authors listed in the copyright statement of GPL code are free to choose any new license he/she/they wish for any future code based on the GPL code he/she/they released.
It is true that in many cases there are many authors, and permission must be given by all authors in order to change the license. This is why Canonical contributors complain about the requirement for copyright assignment. If you contribute GPL code to a Canonical copyrighted project, you are required to forfeit your say [yea or nay] in changing the license from GPL to commercial. This is one reason I do not use Ubuntu.
Ref: I'm sure there's a better reference... but I'm too lazy at the moment:
http://stackoverflow.com/questions/9116172/gpl-and-lgpl-to-commercial
maybe wikipedia too...
https://en.wikipedia.org/wiki/Business_models_for_open-source_software#Re-licensing_under_a_proprietary_license
Meaning: Your own software can be re-licensed proprietary and also then combined with other people's FOSS if that other FOSS uses a 'permissive' open source license.
A person that holds a copyright can revoke or change the license at any time. That includes GPL. The trick is that the copyright holder cannot retroactively revoke the license on the code already released. That means that if the users of the software do not agree with the change in license, they can always fork the code at that point and continue onward with the code as it was at the last GPL release.
A perfect case in point is MySQL versus MariaDB. Now that Oracle owns the copyright on MySQL, they can license it however they wish. But, MariaDB is free to continue onward with the code as it stood just before Oracle bought the copyright. However, MariaDB cannot change the license because they do not own the copyright. They can however dual license their own code - I have no idea if they do that.
A perfect case in point is MySQL versus MariaDB. Now that Oracle owns the copyright on MySQL, they can license it however they wish. But, MariaDB is free to continue onward with the code as it stood just before Oracle bought the copyright. However, MariaDB cannot change the license because they do not own the copyright. They can however dual license their own code - I have no idea if they do that.
THANKYOU mrider......what you have written is what I intended to convey in my post above, but apparently didn't explain it properly. Your word "retroactively" fully deals with what I meant by saying that once code is released under the GPL, that code cannot be changed from the GPL.....Your example is perfect.
me1010 is saying the same thing when he said future code meaning release
Quoting:And the authors listed in the copyright statement of GPL code are free to choose any new license he/she/they wish for any future code based on the GPL code he/she/they released.
Yes, he is Fettoosh, but that occurred in a posting after his original post to which I offered an objection. Ultimately, all three of us have the same concept I think......well, I am sure mrider and myself agree.
Yes... it would appear that we all understand the GPL after all...
However, it is important to note that it may be successfully argued that:
1
2
:may constitute enough of a change that code 2 is a "new" release and can be re-licensed as proprietary.
What I'm trying to show is that the end-user of GPL-ed code is certainly free to use the original version of the code in a 'free' way. However, any and all future releases and updates - including security updates - [made by the copyright holders] are not required to be released under this same license. And so, as I indicated before:
The fact that RH does not control the systemd copyrights makes the entire argument that:
However there remains the following:
1. systemd code quality is poor.
1a. Measurable, but no one here has provided a yard stick.
2. systemd is philosophically flawed.
2a. OK.. can't really argue that one -- but it is a personal opinion and not a factual statement.
3. systemd is prone to scope creep.
3a. The main inclusion of code has been udev... which has already been forked.
3b. The libc choosen may be a problem for some use cases, but there are solutions 'out there' to build anyway.
4. systemd's maintainers are sometimes rude or otherwise unpalatable.
4a. OK... again, this is a personal opinion and is at least partially driven by the non-systemd party... as my parents are fond of saying: It takes two to tango.
So... the entire argument over systemd hinges on very few factually based decision points. And hopefully, the RH conspiracy theorists are beginning to rethink the soundness of that wild accusation.
However, it is important to note that it may be successfully argued that:
1
int main
{
int x=0;
x++;
return 0;
}2
int main
{
int x=0;
x++;
__asm__ ( "nop;");
return 0;
}:may constitute enough of a change that code 2 is a "new" release and can be re-licensed as proprietary.
What I'm trying to show is that the end-user of GPL-ed code is certainly free to use the original version of the code in a 'free' way. However, any and all future releases and updates - including security updates - [made by the copyright holders] are not required to be released under this same license. And so, as I indicated before:
Quoting:in a very real way, if you use FOSS you are always at the mercy of the copyright owner whomever that may be -- unless you are very good programmer and keep your own software stack.
The fact that RH does not control the systemd copyrights makes the entire argument that:
Quoting:RH is controlling everything by pushing systemdentirely specious and/or universally applied to all FOSS.
However there remains the following:
1. systemd code quality is poor.
1a. Measurable, but no one here has provided a yard stick.
2. systemd is philosophically flawed.
2a. OK.. can't really argue that one -- but it is a personal opinion and not a factual statement.
3. systemd is prone to scope creep.
3a. The main inclusion of code has been udev... which has already been forked.
3b. The libc choosen may be a problem for some use cases, but there are solutions 'out there' to build anyway.
4. systemd's maintainers are sometimes rude or otherwise unpalatable.
4a. OK... again, this is a personal opinion and is at least partially driven by the non-systemd party... as my parents are fond of saying: It takes two to tango.
So... the entire argument over systemd hinges on very few factually based decision points. And hopefully, the RH conspiracy theorists are beginning to rethink the soundness of that wild accusation.
OK, so far, according to few posts here, two main programs, udev & D-bus, were included in systemd that consequently made many applications that use or depend on these two programs also dependent on systemd.
Now udev, according to Wikipedia, was developed by Greg Kroah-Hartman and Kay Sievers.
& D-Bus, again according to Wikipedia, was developed by Red Hat and the community developed as part of the freedesktop.org project.
The questions I have, and I appreciate some answers are:
- Were these two programs forked/hijacked or were they voluntarily include into systemd by all their developers?
- was it really technically necessary to do the inclusion? what are the reasons? Did RH address or justified these concerns?
- how big of an effort is it to maintain a fork to keep them separate by others than their original developers?
- Has any one objectively addressed such concerns?
- Has RMS, or any one of the main FOSS advocates made his/her opinion about this issue public?
- ...
Now udev, according to Wikipedia, was developed by Greg Kroah-Hartman and Kay Sievers.
& D-Bus, again according to Wikipedia, was developed by Red Hat and the community developed as part of the freedesktop.org project.
Quoting:Heavily influenced by the DCOP system used by versions 2 and 3 of KDE, D-Bus has replaced DCOP in the KDE 4 release. An implementation of D-Bus supports most POSIX operating systems, and a port for Windows exists. It is used by Qt 4 and GNOME. In GNOME it has gradually replaced most parts of the earlier Bonobo mechanism. It is also used by Xfce.
The questions I have, and I appreciate some answers are:
- Were these two programs forked/hijacked or were they voluntarily include into systemd by all their developers?
- was it really technically necessary to do the inclusion? what are the reasons? Did RH address or justified these concerns?
- how big of an effort is it to maintain a fork to keep them separate by others than their original developers?
- Has any one objectively addressed such concerns?
- Has RMS, or any one of the main FOSS advocates made his/her opinion about this issue public?
- ...
@Fettoosh:
eudev is the fork of udev:
http://www.gentoo.org/proj/en/eudev/
I don't believe D-Bus code is included in the source tree of systemd. My understanding is that systemd uses D-Bus as its messaging transport. So systemd depends on D-Bus, rather than D-Bus depends on systemd... please correct me, if I am wrong... but please do not post third party hearsay as proof.
If you want to know the answers to the rest of the 'why' questions, check out Poettering's blog -- whether anyone likes him or not, you will find the 'why' questions mostly answered there...
http://0pointer.net/blog/
eudev is the fork of udev:
http://www.gentoo.org/proj/en/eudev/
I don't believe D-Bus code is included in the source tree of systemd. My understanding is that systemd uses D-Bus as its messaging transport. So systemd depends on D-Bus, rather than D-Bus depends on systemd... please correct me, if I am wrong... but please do not post third party hearsay as proof.
If you want to know the answers to the rest of the 'why' questions, check out Poettering's blog -- whether anyone likes him or not, you will find the 'why' questions mostly answered there...
http://0pointer.net/blog/
Quoting:but please do not post third party hearsay as proof.
That wasn't my intention. I was merely assuming the worst as portrayed by some posts .
In my opinion, if Poettering is heavily involved in this project, his blog might not be a reliable source for facts concerning this subject. If you have one, I would rather read an independent unbiased source instead.
If you notice, my questions are aimed at the claims in the various threads hoping someone does real evaluation and state the facts instead of interpretations & assumptions.
An example of confirmation bias:
A psychic tells you, "You will converse with a drop-dead gorgeous blonde today..." And then it happens. Wow, the psychic was right? Only because you hoped so.
And a counter-example, same psychic:
"...right before you get hit by a truck." And then it happens. Ummmm...
A psychic tells you, "You will converse with a drop-dead gorgeous blonde today..." And then it happens. Wow, the psychic was right? Only because you hoped so.
And a counter-example, same psychic:
"...right before you get hit by a truck." And then it happens. Ummmm...
@Fettoosh:
I don't have a blog, I'm a terrible blogger. I don't considered myself unbiased, because we are all biased - although I do try to remain unbiased.
Arch has really good documentation.
https://www.archlinux.org/packages/core/x86_64/systemd/
I have referred to Arch's documentation in other threads. I really should start using the distro, but I sort of 'grew up' with Debian. Here's the build dependecies they list as well as which programs currently employ systemd hooks. I'm sure many of the anti-systemd people will say:
However, this is not true, most of those 133 programs include an 'if it's there' optional behavior -- sort of like [or maybe is] make's ifdef.
For examples CUPS:
I separated out the important point.
As far as code complexity is concerned, it's not an easy topic of research, especially considering systemd. In general there are many measures of code maintainability, cost, and quality. However, SLOC [source lines of code] is a key value in the calculations of code cost and maintainability. Based on SLOC alone, systemd could probably be calculated to be cheaper to maintain than a a full laden general purpose desktop deployment of sysvinit and associated smaller programs --- although I haven't done the actual calculation.
Here's a wiki link to source code quality measurement -- much of it will seem esoteric:
https://en.wikipedia.org/wiki/Software_quality
At one point in my meandering career, I took a few nearly forgotten courses on CMMI:
http://whatis.cmmiinstitute.com/grow-your-career
But I found it very boring, I much prefer to put things together with my hands than do esoteric calculations in risk management. I suppose that's why risk management pays lots.
@gus3:
No harm will come to me as the bearer of the holy hand grenade of Antioch.
EDIT: corrected 144 to 133.
I don't have a blog, I'm a terrible blogger. I don't considered myself unbiased, because we are all biased - although I do try to remain unbiased.
Arch has really good documentation.
https://www.archlinux.org/packages/core/x86_64/systemd/
I have referred to Arch's documentation in other threads. I really should start using the distro, but I sort of 'grew up' with Debian. Here's the build dependecies they list as well as which programs currently employ systemd hooks. I'm sure many of the anti-systemd people will say:
Quoting:Hey! See! That's 133 programs that require systemd.
However, this is not true, most of those 133 programs include an 'if it's there' optional behavior -- sort of like [or maybe is] make's ifdef.
For examples CUPS:
grep -r systemd *
config.h.in: * Do we have systemd support? config-scripts/cups-systemd.m4:dnl systemd stuff for CUPS. config-scripts/cups-systemd.m4:dnl Find whether systemd is available config-scripts/cups-systemd.m4:AC_ARG_WITH([systemdsystemunitdir], config-scripts/cups-systemd.m4: AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files]), config-scripts/cups-systemd.m4: [], [with_systemdsystemunitdir=$($PKGCONFIG --variable=systemdsystemunitdir systemd)]) config-scripts/cups-systemd.m4:if test "x$with_systemdsystemunitdir" != xno; then config-scripts/cups-systemd.m4: AC_MSG_CHECKING(for libsystemd-daemon) config-scripts/cups-systemd.m4: AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir]) config-scripts/cups-systemd.m4: if $PKGCONFIG --exists libsystemd-daemon; then config-scripts/cups-systemd.m4: SDCFLAGS=`$PKGCONFIG --cflags libsystemd-daemon` config-scripts/cups-systemd.m4: SDLIBS=`$PKGCONFIG --libs libsystemd-daemon` config-scripts/cups-systemd.m4:if test -n "$with_systemdsystemunitdir" -a "x$with_systemdsystemunitdir" != xno ; then configure.in:sinclude(config-scripts/cups-systemd.m4) debian/cups-daemon.install:lib/systemd/system/cups.socket debian/cups-daemon.install:lib/systemd/system/cups.path debian/cups-daemon.install:lib/systemd/system/cups.service debian/libcups2.README.Debian:Socket-activation under systemd
debian/libcups2.README.Debian:Since 1.7.1-7, when systemd is the active init system, CUPS can be
debian/libcups2.README.Debian:its sockets. The socket definition in /lib/systemd/system/cups.socket gets debian/libcups2.README.Debian:configured through files in /etc/systemd/system/cups.socket.d/; see debian/libcups2.README.Debian:systemd.unit(5) and the examples files in /usr/share/doc/cups-daemon/examples . debian/libcups2.README.Debian:/etc/cups/cupsd.conf. For systemd's socket activation to working, cups.socket debian/libcups2.README.Debian:configuration files in the /etc/systemd/system/cups.socket.d/ directory.
I separated out the important point.
As far as code complexity is concerned, it's not an easy topic of research, especially considering systemd. In general there are many measures of code maintainability, cost, and quality. However, SLOC [source lines of code] is a key value in the calculations of code cost and maintainability. Based on SLOC alone, systemd could probably be calculated to be cheaper to maintain than a a full laden general purpose desktop deployment of sysvinit and associated smaller programs --- although I haven't done the actual calculation.
Here's a wiki link to source code quality measurement -- much of it will seem esoteric:
https://en.wikipedia.org/wiki/Software_quality
At one point in my meandering career, I took a few nearly forgotten courses on CMMI:
http://whatis.cmmiinstitute.com/grow-your-career
But I found it very boring, I much prefer to put things together with my hands than do esoteric calculations in risk management. I suppose that's why risk management pays lots.
@gus3:
No harm will come to me as the bearer of the holy hand grenade of Antioch.
EDIT: corrected 144 to 133.
@me1010, look here: mockus.us/papers/decay.pdf
There's nothing esoteric here. It's a statistical analysis which code goes bad. There is a significant overlap with systemd.
"systemd, a similar but less-Linux-specific set of tools"
Isn't that backwards? SystemD uses MORE linux-specific system calls.
I saw that, too. After such poor fact-checking, I didn't bother reading the remainder of the article.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
@me1010: your distraction tactic is a waste of time, nobody will fall for your hair-splitting with regards to the GPL and it's very transparent that this is simply an attempt by you to derail the thread by focusing on non-issues of no relevance to the subject of the thread.