Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Jun 2000 01:25:10 -0600
From:      Warner Losh <imp@village.org>
To:        Doug Barton <DougB@gorean.org>
Cc:        papowell@astart.com, nik@FreeBSD.ORG, arch@FreeBSD.ORG
Subject:   Re: Bringing LPRng into FreeBSD? 
Message-ID:  <200006270725.BAA32822@harmony.village.org>
In-Reply-To: Your message of "Mon, 26 Jun 2000 23:56:45 PDT." <3958502D.DF9729BD@gorean.org> 
References:  <3958502D.DF9729BD@gorean.org>  <200006242153.OAA01110@h4.private> <200006270615.AAA31842@harmony.village.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <3958502D.DF9729BD@gorean.org> Doug Barton writes:
: 	I'm surprised to hear this coming from you, actually. I disagree
: strongly that discouraging commercial vendors from being able to
: integrate "stock" parts of freebsd into their product is "not our
: problem." One of the drawing cards for freebsd is that commercial
: vendors _can_ take our code and use it in any manner they see fit. The
: list of exceptions is long enough already, I haven't seen a compelling
: reason to make it longer. 

I'd like to point out that FreeBSD isn't all Free.  Significant
portions of the tree are covered by licenses that require changes be
disclosed.  The compilers, binary utilities, awk, perl, and others
have this restriction.  Likewise there are parts of the system that
don't even come as source (the fla driver is one example).  These are
restrictions that people must live with.

Second, the ARTISTIC license does not preclude FreeBSD from including
LPRng.  This statement is still true.  We can comply with all the
terms of the license.

Third, we have a crying need for a better print system.  lpr/lpd are
hard to maintain and difficult to audit.

So we have to weigh the needs of most of the FreeBSD users against the
theoretical needs of a potential company wanting to make print servers
on a stick that requires them to hack lprng.

We have to ask ourselves the following sorts of questions:
	1) Is there a need?
	2) Will this fit the need?
	3) Is it better enough than what we have to kill what we have?
	4) a) Will the licensing restrictions cause someone to not use
	   FreeBSD?  b) If so, do we care?

1) and 2) are well known.  The answer is clearly yes.  Question 3 is
what we need to focus on, since it hasn't been answered due to the
licensing squabble.

In answering question 4a, I ask myself what the alternatives are:
	1) Use NetBSD or OpenBSD and hack on lpr
	2) Use FreeBSD w/o lprng and hack on lpr from ports
	3) Use * and write your own printer queuing software

If they choose (3) it doesn't matter what we have in FreeBSD since
otherwise they would have used an old copy of lpr, so the answer is
no.  If they chose 2) then we answer 4a no again because they are
using FreeBSD.  If their choice is (1), then it is strong evidence
that the license did matter.  I would suspect that if they did do (1)
it would be for reasons other than the license on the default print
software in FreeBSD.  So we wouldn't have won there anyway.

So it looks like the answer to 4b is pretty close to "we don't care"
since none of the alternatives were impacted by the licensing of
FreeBSD default print queue software and that alone.

That's my reasoning for saying that we don't need to care about a
company that wants to create a print server based on FreeBSD.  They
will either use lpr/lpd from a previous release (hacked as they see
fit), or use the new standard print queue software unmodified.

Personally, I'd think it would be in their best interests to make sure 
that the changes to lprng got merged back into the baseline sources
since I'd expect them to compete based on form factor of their custom
hardware, ease of use, price, etc. rather than on pure functionality.

Warner





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006270725.BAA32822>