Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Jun 2000 08:18:07 -0600 (MDT)
From:      Nate Williams <nate@yogotech.com>
To:        Warner Losh <imp@village.org>
Cc:        Doug Barton <DougB@gorean.org>, papowell@astart.com, nik@FreeBSD.ORG, arch@FreeBSD.ORG
Subject:   Re: Bringing LPRng into FreeBSD? 
Message-ID:  <200006271418.IAA04077@nomad.yogotech.com>
In-Reply-To: <200006270725.BAA32822@harmony.village.org>
References:  <3958502D.DF9729BD@gorean.org> <200006242153.OAA01110@h4.private> <200006270615.AAA31842@harmony.village.org> <200006270725.BAA32822@harmony.village.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> : 	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.

Ahh, but very few (if any) of them are needed in an embedded system.
How many people are going to run 'grep' on an embedded system, or
re-compile the source to the system?

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

Again, this isn't a problem in embedded systems, since you'd just go an
avoid the driver in question.

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

The ARTISTIC license isn't that much different from the GPL from a
commercial entities POV.  For FreeBSD it is no different at all, since
we ship with source.

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

This is the crux of the matter.

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

Not just print server, but many others kinds of 'embedded' systems, that
have use for the print server code.

I'll mention the philisophical point and ask, what's the point of using
a BSD copyright if we don't really care what happens with FreeBSD
outside of the 'user base' that uses it for WWW servers, shell servers,
and other non-embedded systems?  These folks don't care what license is
being used (for the most part), since they could just as easily use
Linux (as far as licensing goes).

The BSD license is 'commercial friendly', and those of us who chose to
use it are 'giving away' our intellectual property with very few strings
attached, and have very little agenda.

This is the 'BSD way' (in contrast with the GPL way), and the more we
get away from this, the more that FreeBSD will become yet another
Linux-clone.

FreeBSD (and the rest of the *BSDs) are more than just bits of software.
They are also giving people a choice, and at this point in time the
choice happens to be a much more robust piece of software.  But, I still
believe the choice of licensing is *AS* important as the functionality
in the system.  (And, they certainly aren't in conflict with each
other.)

That's one of the main reasons I did the BSD thing when Linux was at
0.11.



Nate


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?200006271418.IAA04077>