Slashdot Mirror
Ask Slashdot: "Pseudo-Free" Software in Major Distributions?
PugMajere
submitted the following:
"I've been looking into using SSH and rdist to distribute
around 2 gig worth of data to about 1000 machines nightly.
Rdist (v6.1.5) would be perfect for this, as it automatically
forks to send data to multiple machines, but it isn't totally
free software. The problem is with SSH.
To use SSH with rdist you need the server side of SSH on
each of the machines that are running the rdist server.
The licensing fees for this are simply astronomical for
this kind of application. While researching all this I noticed
that Red Hat includes rdist (6.1.5) in its distribution.
I also now know the
rdist license
terms. Rdist isn't free to use in a commercial setting
if it involves another company. So, if you have two
companies running Linux, that are collaborating on some
project, and sharing some of the data using Linux and rdist,
they owe Magnicomp money. My real question here is: Does
anyone else realize this? How many other packages have
similar arrangements that are going to cause major
headaches in the future?"
While it is true that Debian distinguishes between free and non-free software according to the DFSG, this does not imply that Debian is only distributing free software. Far from it. Three weeks ago I counted 334 non-free packages in potato. If we add the contrib packages that depend on non-free software, say another 150 packages (don't know the exact number), it will be true to say this: Debian distributes about 484 non-free packages. This is contrary to Debian's 'social contract' which begins with the phrase "Debian Will Remain 100% Free Software" (then goes on to explain that 100% free software means free + non-free software! )
rsync is more like rcp than rdist. In particular, rsync does not support a configuration file, nor does it support copying files to multiple machines at the same time.
From the ssh COPYING file:
--------------------------------------------------
(b) You may use the program for non-commercial purposes only, meaning that the program must not be sold commercially as a separate product, as part of a bigger product or project, or otherwise used for financial gain without a separate license. Please see Section 2, Restrictions, for more details.
--------------------------------------------------
And...from the ssh FAQ:
--------------------------------------------------
3.2 May I legally run ssh?
The UNIX version of ssh 1.2.27 may be used freely for non-commercial purposes and may not be sold commercially as a separate product, as part of a bigger product or project, or otherwise used for financial gain without a separate license. The definition of "commercial use" is generally interpreted as using ssh for anything that would generate financial gain, such as logging into a customers system to do administration, or providing ssh as a secure login to your partners or vendors.
In email between Data Fellows and the maintainer, the following questions were asked and answered:
================================================== =============
= ===============
S: Steve Acheson, FAQ Maintainer
P: Petri Nyman, F-Secure SSH Product Manager for Data Fellows
S)Can a company use the 1.2.26 release of the SSH software freely for
S)internal support and administration without violating the license
S)agreement?
P)You can freely use it for internal support and administration of your own
P)equipment located in your premises.
S)Does connecting from one machine to another via SSH to
S)read email, do work, etc, violate this agreement?
P)No, unless you provide this ability to a third party or connect to a third
P)party's computer to provide a service.
S)Does connecting from a purchased PC client SSH software to a non-licensed
S)SSH server violate the agreement?
P)No.
S)Does connecting to a remote site, that is not company owned, but company
S)administered, via SSH to do administrative work violate the agreement?
P)Yes. You need a commercial license for that.
===============================================
--------------------------------------------------
So, I'd say that it's at least legally questionable if you use ssh to connect to client machines, or vice-versa.
--
However, a decent answer to this question would involve trying to look for a solution, maybe something like SSLrdist would be appropriate. It's based on SSLeay, USC rdist, and stuff from NetBSD. So it looks free to me, and that's a good place to start. Comments?
pb Reply or e-mail; don't vaguely moderate.
I am a bit perturbed that there was no mention of 6.1.5 or the license change on the rdist developers list. The first I heard of 6.1.5 was some note on the list asking for help with 6.1.5.
"even if the person behind MagniComp is the individual who did the work at USC (one Michael Cooper)" It is the same person. Michael Cooper left USC for Sun. MagniCorp is (I think) his own corporation for stuff he has done that is not concerned with Sun.
If someone wants a copy of rdist 6.1.4 I can send it.
Hi Bruce,
While you may have written the scripts that were used to build ``bo'' CDs, I think we should probably credit Andreas Jellinghaus, who did an almost total rewrite for ``hamm'' (a.k.a. Debian 2.0).
I then maintained that set of scripts, but there has since been another rewrite by Steve McIntyre (for ``slink'', a.k.a. Debian 2.1), with contributions from a whole bunch of people on debian-cd@lists.debian.org.
Apart from that, you are correct in saying that the Official Debian GNU/Linux CDs contain only software that meets the Debian Free Software Guidelines.
Cheers, Phil.
P.S. rsync ? I think you mean rdist. rsync is GPL. Debian's rdist is rdist-6.1.3 (usc.edu:/pub/rdist) which is BSD.
Debian: GNU/Linux done the Linux way
This would not have happened if you were using Debian, because Debian considers the license of each package for compliance with the The Debian Free Software Guidelines, the document that later became the Open Source Definition.
Thanks
Bruce
Bruce Perens.
Bruce
Bruce Perens.
Bruce
Bruce Perens.
Bruce
Bruce Perens.
Bruce
Bruce Perens.
Bruce
Bruce Perens.
Yeah rdist. It's getting late. Thanks for the verification.
Bruce Perens.
I got rsync and rdist confused in more than one posting. Sorry. Time to go to sleep.
Thanks
Bruce
Bruce Perens.
Nope, it's not that old.
Bruce Perens.
Bruce
Bruce Perens.
The Debian Social Contract was not written to eliminate non-free software from the face of the earth, but to keep it out of Debian's "main" directory. The contrib and non-free directories aren't an official part of Debian.
Bruce
Bruce Perens.
The Official CD ISO 9660 images do not contain non-free software. They do contain an old BSD version of rsync.
Bruce
Bruce Perens.
Bruce
Bruce Perens.
That, sir, is why we're so "fanatical" about licenses. To protect you from exactly what you described.
Thanks
Bruce
Bruce Perens.
I checked. There's really an addendum to the Red Hat version that makes it non-free. Extract the source package and look just before the usual BSD license text.
Bruce Perens.
Rsync is GPLed, and a lot more efficient than rdist for most purposes -- the debian ISO mirror process is one good example.
If you do go with rdist-style distribution, check into sdist, which might (I can't recall with any certainty) have a more liberal license than rdist, and uses SSH.
For the SSH portion, there are troubles. Free implementations of ssh are underway (the ssh1 license allows some levels of commercial use, ssh2's is too restrictive to be commercially useful), but taking their time.
It's nice to see so many folks chiming in with comments about ssh & rdist replacements; the competition to build a better mousetrap sometimes seems a bit ridiculous, but then you run into a situation like this and you're grateful.
Unfortunately, being able to name a replacement is not the point. The point is that someone out there is not going to know that there is a licensing distinction for some piece of software including on one of the distros and they're going to violate the terms of the license. And they're going to get caught. And they're going to raise a stink. Not that this is a real problem; I think all of the distributions should band together to develop some universal mechanism for informing users when they are installing a "pseudo-commercial" licensed product.
I think that rpm, yast, apt and whatever tools that are used to install packages should be modified to present the license to a user when it varies from the license used by a majority of the distribution. Or that a user should have to read/accept each license in kind.
The Norton Anthology of English Literature, 4th Ed., Vol 2
The plan is to remove the GCC requirement. The new exception will be
// As a special exception, you may use this file as part of a free software
// library without restriction. Specifically, if other files instantiate
// templates or use macros or inline functions from this file, or you compile
// this file and link it with other files to produce an executable, this
// file does not by itself cause the resulting executable to be covered by
// the GNU General Public License. This exception does not however
// invalidate any other reasons why the executable file might be covered by
// the GNU General Public License.
But the LGPL also have problems; it isn't suitable for embedded systems customers, who have, in effect, been paying most of the bills for gcc development (via Cygnus support contracts). Switching libio to the LGPL would not be acceptable to the people that are doing or paying for most of the work.
The current license (GPL with special exception) requires that at least one .o file be compiled with gcc. But the LGPL has many more requirements: the executable must be shipped in linkable form, and there are other requirements as well.
Switching libio to the LGPL will make matters worse for many. Some other solution is needed.
The license terms look similar to those for MySQL. That is, it's free of charge when a person, company or org puts it on its own machines, regardless of who uses the machines. Payment and/or negotiation are required for redistribution.
As with MySQL, you seem to be welcome to build resale solutions around it without anyone getting paid, so long as your app leaves it to the customer to obtain and install rdist themselves separately.
The terms are weird and tortuous, but they do not seem to require payment for commercial or business-to-business use per se.
Richard assured me in Paris that all the necessary permissions have been granted for the glibc maintainers to change the libio license to LGPL.
You should use rsync instead. It's faster, and support SSH.
cfengine is a GNU project which easily replaces rdist. It uses its own protocol rather than relying on a seperate program (ie: rsh or ssh) to transfer the data. Encrypted transfers are an option in the most recent (v1.5) version.
Check it out at the cfengine home page
I don't know who MagniComp is, but the version of rdist included with RedHat is 6.1.3 from University of Southern California and is distributed under the BSD license.
MagniComp appears to have forked their version off the USC source tree and "hijacked" the license. This is possible with the BSD license, which is why some of us feel that the GPL is better. The However, they definitely can't lay any claim on the version of rdist that comes with RedHat... even if the person behind MagniComp is the individual who did the work at USC (one Michael Cooper), that version had not yet been hijacked, so it's safe.
1: Ssh1 is not that expensive, just ssh2.
2: You don't need the server stuff on your 1000
hosts, just on the central one. Just have the
clients pull the files from the server (eg from
a cron job, like we do here).
3: Use rsync instead of rdist - it's much better.
Cameron Simpson, DoD#743 cs@cskk.id.au http://www.cskk.ezoshosting.com/cs/
Unfortunately, yes. The courts have traditionally held that licenses *are* enforceable.
The Berne convention, the basis for most international copyright laws, states that all original works are automatically copyrighted and that the author, unless she specifically waives certain rights by declaring otherwise, is entitled to every protection under the copyright law, including the right to redistribute the work.
Basically, without the license, you have NO right to copy the work or really even to use it, except under "fair use" exemptions. What entails "fair use" is somewhat vague...and depends greatly on the type of work in question.
If software licenses were held to be unenforceable, however, this would be GREATLY *hurt* the free software movement, which actually depends on these licenses. Remember that the GPL, and other similiar licenses are just that: they are software liceneses and they do place restrictions on how software can be copied, modified and distributed. The fact that these restrictions are designed to protect people's rights to redistribute and modify free software is completely irrelevant.
The real question is not whether software licenses are enforceable per se, but whether or not *certain provisions* of these licenses are enforceable, such as restrictions about who and who cannot use a program.
I would say that distribution and copying can be controlled under copyright, but personally I would argue that if someone has *paid* for a license to use a program then that person cannot be denied the right to use the program under fair use, but if someone was *given* a program, but the license does not allow distribution to that particular person (or company) then they *could* be denied the right to use the program.
For a complete discussion by an excellent copyright attorney, you should check out "The Software Developer's Complete Legal Companion" by Thorne D. Harris III (Prima Publishing).
DISCLAIMER: I am not a lawyer, so this represents only a laypersons opinion. You should consult a lawyer if you really need to.
My journal has hot
One of my favorite comics, an old Fifth Wave I think, has a person paying for software with a check that says that it is presented as is and that it's cashing functionality isn't guarenteed. :-)
Basically this means that you can't make commercial software on linux that uses libio unless you use a GNU compiler.
G NU_C++_Iostream_Library/libioIntroduction_ to_Iostreams.html
-----------------------
http://www.cygnus.com/pubs/gnupro/4_libs/c_The_
Licensing terms for libio
Since the iostream classes are so fundamental to standard C++, the Free Software Foundation has agreed to a special exception to its
standard license, when you link programs with libio.a.
As a special exception, if you link this library with files compiled with a GNU compiler to produce an executable, this does not cause the
resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why
the executable file might be covered by the GNU General Public License.
The code is under the GNU General Public License (version 2) for all purposes other than linking with this library which means that you can
modify and redistribute the code as usual; remember that, if you do, your modifications, and anything you link with the modified code, must
be available to others on the same terms.
The enforceability of shrink-wrap or non-wrap license agreements certainly remains, at least, an open question. While at least one Circuit Court (the Seventh) has found them to be enforceable, several others have not enforced shrink-wrap provisions for various reasons. Recent District Court cases in other Circuits have characterized the Seventh Circuit position as "the minority view."
In short, I respectfully dissent from the second sentence of the message to which I respond.
I note, with interest, that recent efforts to add a new article 2 to the UCC were directed to precisely this question, which would tend to support OSS non-wrap licenses. It is ironic that these proposals were largely rebuffed without much analysis by the open source community, precisely because the proposals were also supported by IP holders.
It is important to recall that, at least, the Stallman view --which eschews the notion of public domain free software in favor of GNU-like licenses-- depends upon the enforceability of Copyrights and related license agreements.
In my legal practice, I am more and more frequently asked by clients (one or more a month now) to review ALL licenses of incorporated or embedded open source code and to advise or opine as to the specific obligations arising from the mix of software and the manner in which it the software is mixed with putatively proprietary code.
Unsurprisingly, clients' first question is whether (and if so, how much and how) code must be distributed in open source or at least offered for distribution. They are often surprised that there may be serious questions whether the software can be distbuted at all!
As it turns out, these questions are rarely easy ones to answer, even after assuming that the agreements are all fully enforceable. On the other hand, the failure to perform such an analysis can lead to substantial downsides such as the suggested example.
With that being said...
Commercial use of SSH generally requires a license. But there are non-commercial allowances in both SSH1 and SSH2. The trouble is what the definition of "non-commercial" includes. SSH2 is very restrictive and pretty much discounts any use of the suite near anything "commercial" in any manner. SSH1 allows for greater leeway:
The file named COPYING that is included in the distribution reads:
The interpretation I get from this is that a Commercial enterprise may use SSH1 as long as it is not a part of a specific service. Administration of local servers is OK. Services that include "Remote secure backups of your systems for pennies a day!" or "Checking accounts now come with secure online banking!" that includes SSH1 as its method of secure communications do not fit in the "non-commercial" license.Once again, it would be wise to point out that it seems the folks selling SSH later decided against this kind of policy. SSH2's license is much more restrictive and reserves "non-commercial" licensing to personal use and educational use as part of academic research and/or teaching (note: educational institutions don't get to use it for administration).
But you're not out of the legal woods yet. SSH1 uses a whole slew of libraries and intellectual property that adds additional layers of license concerns. Thankfully, most of them are cleared by allowances for use of those properties in SSH1.
Two big concerns that aren't covered include IDEA and RSA. IDEA is easy to get around by not including it in your compile (opting for Blowfish instead). RSA is a tougher issue. You'll have to look at it yourself if you're still trying to figure it out (I luck out with a license granted to the US Government for RSA since a partial Gov't grant helped develop it at MIT).
This re-raises the issue:
Are software licenses legal or enforcable.
It's one thing when Microsoft has a license which states that by clicking on this button, you sign your soul over to bill, but I never clicked such a button when I installed my Redhat 5.2. Would this make Redhat responsible for license violations. Can you enforce a contract which one side has never even seen? I suspect the ideas of software licenses will have to be revisited by the legislature at some point (Scary thought).