>From time-to-time, I've asked that certain things be allowed
within the kernel such as, most recently, denying a raw write
to a mounted file-system. Such things have been opposed because,
as I have been told, "Policy is not allowed within the kernel...".
Well, with the current GPL code-only fiasco, this is Policy being
enforced by the kernel.
It won't be long before we get:
Script started on Thu Oct 18 08:44:44 2001
# gcc -o applic xxx.c
# ./applic
Kernel panic
Non GPL application pollution of the Linux environment
Application name = ./applic
Virtual address = 0x8048528
Stack address = 0xbffff72c
PID = 32636
System halted
I can understand not wanting to take any responsibility for
some binary-only module when attempting to find a kernel
problem. However, denying the use of non GPL modules is
not the way. As a developer of many modules, I can certainly
add the required object(s) during development and bypass the
current policy. In fact, since the source code of `insmod`
is available, it won't be long before any checks put there
are eliminated.
No publicly-traded commercial hardware company is going to
disclose the inner workings of proprietary hardware without
risking a stockholder's lawsuit. For this reason, there will
always be proprietary hardware and proprietary software to
interface with it. If Linux doesn't allow for such a proprietary
interface then Linux will not be used. It's just that simple.
Even publicly-traded commercial software companies face the
same challenge from their stockholders. The intellectual
property that they have developed must be kept secret from
their competition. Otherwise, one company spends millions
to develop a product only to have another start-up deliver
the same product at a cheaper price with no up-front development
cost because they would use the intellectual property of the
developer.
In the business world, something as simple as puts("Hello World!");
MUST be kept a trade secret. If it was written by an employee
in the context of his or her job, the company's stockholders owns
that line of code so no employee, even the President, is allowed
to give it away.
If Linux intends to become the mainstay for commercial enterprise
then the developers have to accommodate the "impure" commercial
practices that exist in this little cruel world.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
On Thu, 18 Oct 2001, Richard B. Johnson wrote:
>...
> In the business world, something as simple as puts("Hello World!");
> MUST be kept a trade secret. If it was written by an employee
> in the context of his or her job, the company's stockholders owns
> that line of code so no employee, even the President, is allowed
> to give it away.
>...
IOW: Companies like IBM, SAP, Sun and SGI that made code available under
the GPL (e.g. as part of the linux kernel or with of relicensed programs)
weren't allowed to do this???
Am I allowed to consider this a bad joke?
> Cheers,
> Dick Johnson
cu
Adrian
--
Get my GPG key: finger [email protected] | gpg --import
Fingerprint: B29C E71E FE19 6755 5C8A 84D4 99FC EA98 4F12 B400
On Thu, 18 Oct 2001, Adrian Bunk wrote:
> On Thu, 18 Oct 2001, Richard B. Johnson wrote:
>
> >...
> > In the business world, something as simple as puts("Hello World!");
> > MUST be kept a trade secret. If it was written by an employee
> > in the context of his or her job, the company's stockholders owns
> > that line of code so no employee, even the President, is allowed
> > to give it away.
> >...
>
> IOW: Companies like IBM, SAP, Sun and SGI that made code available under
> the GPL (e.g. as part of the linux kernel or with of relicensed programs)
> weren't allowed to do this???
>
>
> Am I allowed to consider this a bad joke?
>
>
It's no joke. Some companies require, in the process of producing
goods and services, that certain interface code and documentation
be provided. For instance, if I make an Ethernet card, it's in
the best interest of the company to sell as many boards as possible.
Therefore, certain information must be given away to obtain those
goals. So, I would provide register-level documentation, sample
source-code, and maybe even drivers for the majority of the known
Operating Systems.
However, If my company makes Bomb Scanners (it does), I cannot
divulge to potential adversaries, either the competition or potential
bombers, how it works. It's just that simple.
If your end product is a board that plugs into a PC, you have a
different set of rules than if your end product is a Bomb Scanner,
a Flight Management System, or a Numerical Milling Machine.
Basically, embedded stuff, both hardware and software, remains hidden.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
* Richard B. Johnson <[email protected]> on Thu, Oct 18, 2001:
>
> >From time-to-time, I've asked that certain things be allowed
> within the kernel such as, most recently, denying a raw write
> to a mounted file-system. Such things have been opposed because,
> as I have been told, "Policy is not allowed within the kernel...".
>
> Well, with the current GPL code-only fiasco, this is Policy being
> enforced by the kernel.
>
> It won't be long before we get:
>
> Script started on Thu Oct 18 08:44:44 2001
> # gcc -o applic xxx.c
> # ./applic
> Kernel panic
> Non GPL application pollution of the Linux environment
> Application name = ./applic
> Virtual address = 0x8048528
> Stack address = 0xbffff72c
> PID = 32636
> System halted
>
> I can understand not wanting to take any responsibility for
> some binary-only module when attempting to find a kernel
> problem. However, denying the use of non GPL modules is
> not the way. As a developer of many modules, I can certainly
> add the required object(s) during development and bypass the
> current policy. In fact, since the source code of `insmod`
> is available, it won't be long before any checks put there
> are eliminated.
>
I've seen this skewed view being reiterated time and time enough on the
list to ask,
Are you people on crack?
Where is policy being enforced? insmod spits out a *warning* and procedes
to taint the kernel. That's it. It doesn't prevent such modules from
being loaded, it doesn't go back on Linus' provision to allow proprietary
modules, and it doesn't e-mail RMS with the subject "Linux (not GNU/Linux) is
no longer pure". From reading Alan's posts, the primary purpose of this
provision is to help kernel hackers determine whether it's worth their
while to follow up on bug reports. You can only do this with a "pure"
kernel, since you have no way of knowing if it's something in the
binary-only module that's killing the kernel.
Why the conspiracy?
As far as EXPORT_MODULE_GPL is concerned, I think that's an excellent idea.
There is *nothing* wrong with a copyright holder enforcing the fair use of
his/her software, and I'd encourage all new GPL'd modules to start
exporting these symbols.
There are some of us who strive to keep the kernel as "pure" as possible,
for a variety of reasons, the main one for me being peace of mind (knowing
my code base is supported, and bugfixes are cheap). Why is this so
difficult for folks to grasp?
I'll shutup now, please read Keith Owen's post ("MODULE_LICENSE and
EXPORT_SYMBOL_GPL") for any more clarification.
M. R.
On Thu, Oct 18, 2001 at 03:38:50PM +0200, Adrian Bunk wrote:
> On Thu, 18 Oct 2001, Richard B. Johnson wrote:
>
> >...
> > In the business world, something as simple as puts("Hello World!");
> > MUST be kept a trade secret. If it was written by an employee
> > in the context of his or her job, the company's stockholders owns
> > that line of code so no employee, even the President, is allowed
> > to give it away.
> >...
>
> IOW: Companies like IBM, SAP, Sun and SGI that made code available under
> the GPL (e.g. as part of the linux kernel or with of relicensed programs)
> weren't allowed to do this???
>
>
> Am I allowed to consider this a bad joke?
Yeah. Let's not forget HP and Apple too. I mean what major hardware
vendors are left after that? Obviously someone has no idea how companies
work. Stockholders own nothing tangible other than a stake in the
company. They control the politics of the companies stradegy, but it's
the CEO on down that makes the decisions.
--
.----------=======-=-======-=========-----------=====------------=-=-----.
/ Ben Collins -- Debian GNU/Linux \
` [email protected] -- [email protected] -- [email protected] '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
On Thu, Oct 18, 2001 at 09:58:33AM -0400, Richard B. Johnson wrote:
> On Thu, 18 Oct 2001, Adrian Bunk wrote:
>
> > On Thu, 18 Oct 2001, Richard B. Johnson wrote:
> >
> > >...
> > > In the business world, something as simple as puts("Hello World!");
> > > MUST be kept a trade secret. If it was written by an employee
> > > in the context of his or her job, the company's stockholders owns
> > > that line of code so no employee, even the President, is allowed
> > > to give it away.
> > >...
> >
> > IOW: Companies like IBM, SAP, Sun and SGI that made code available under
> > the GPL (e.g. as part of the linux kernel or with of relicensed programs)
> > weren't allowed to do this???
> >
> >
> > Am I allowed to consider this a bad joke?
> >
> >
>
> It's no joke. Some companies require, in the process of producing
> goods and services, that certain interface code and documentation
> be provided. For instance, if I make an Ethernet card, it's in
> the best interest of the company to sell as many boards as possible.
> Therefore, certain information must be given away to obtain those
> goals. So, I would provide register-level documentation, sample
> source-code, and maybe even drivers for the majority of the known
> Operating Systems.
>
> However, If my company makes Bomb Scanners (it does), I cannot
> divulge to potential adversaries, either the competition or potential
> bombers, how it works. It's just that simple.
>
> If your end product is a board that plugs into a PC, you have a
> different set of rules than if your end product is a Bomb Scanner,
> a Flight Management System, or a Numerical Milling Machine.
> Basically, embedded stuff, both hardware and software, remains hidden.
But that has nothing to do with stockholders claiming ownership of code
written by an employee. That's a much deeper policy. So your assertions
are way off base.
Now, if your driver just interfaces your hardware with userspace, then
that driver likely contains nothing of extreme importance for how your
"Bomb Scanner" works, and releasing it under GPL is not going to be a
problem. Your application contains those details. I don't see how you
are getting at the application level being considered a corrupter of the
kernel's GPL stringency. Do you actually see this occuring?
--
.----------=======-=-======-=========-----------=====------------=-=-----.
/ Ben Collins -- Debian GNU/Linux \
` [email protected] -- [email protected] -- [email protected] '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
M. R. Brown wrote:
> * Richard B. Johnson <[email protected]> on Thu, Oct 18, 2001:
>
>> >From time-to-time, I've asked that certain things be allowed
>> within the kernel such as, most recently, denying a raw write
>> to a mounted file-system. Such things have been opposed because,
>> as I have been told, "Policy is not allowed within the kernel...".
>>
>> Well, with the current GPL code-only fiasco, this is Policy being
>> enforced by the kernel.
>>
>> It won't be long before we get:
>>
>> Script started on Thu Oct 18 08:44:44 2001
>> # gcc -o applic xxx.c
>> # ./applic
>> Kernel panic
>> Non GPL application pollution of the Linux environment
>> Application name = ./applic
>> Virtual address = 0x8048528
>> Stack address = 0xbffff72c
>> PID = 32636
>> System halted
>>
>> I can understand not wanting to take any responsibility for
>> some binary-only module when attempting to find a kernel
>> problem. However, denying the use of non GPL modules is
>> not the way. As a developer of many modules, I can certainly
>> add the required object(s) during development and bypass the
>> current policy. In fact, since the source code of `insmod`
>> is available, it won't be long before any checks put there
>> are eliminated.
>>
>
> I've seen this skewed view being reiterated time and time enough on the
> list to ask,
>
> Are you people on crack?
>
> Where is policy being enforced? insmod spits out a *warning* and procedes
> to taint the kernel. That's it. It doesn't prevent such modules from
> being loaded, it doesn't go back on Linus' provision to allow proprietary
> modules, and it doesn't e-mail RMS with the subject "Linux (not GNU/Linux) is
> no longer pure".
That's how I understand it as well, it does not stop the loading of the
non GPL module, it just taints the kernel (sets a flag).
> From reading Alan's posts, the primary purpose of this
> provision is to help kernel hackers determine whether it's worth their
> while to follow up on bug reports. You can only do this with a "pure"
> kernel, since you have no way of knowing if it's something in the
> binary-only module that's killing the kernel.
One thing I don't get is; how does this solve the problem? As I
understood it the problem was that people would lie in bug reports and
say that they had no non-gpl modules loaded even if they did, becourse
otherwise people would ignore their reports. Tainting the kernel does
not solve that problem - users who previously lied about loaded modules
will now just edit the Oops before posting and change the "tainted"
message to "not tainted". Unless there is some way to validate the "not
tainted" status of the kernel people are going to continue to lie about
it. Would it maybe be possible to generate some kind of "checksum" on
the taint-state of the kernel that could be verified when recieving the
oops (probably overkill)?
- Jesper Juhl
[email protected]
On Thu, 2001-10-18 at 15:04, M. R. Brown wrote:
>
> As far as EXPORT_MODULE_GPL is concerned, I think that's an excellent idea.
> There is *nothing* wrong with a copyright holder enforcing the fair use of
> his/her software, and I'd encourage all new GPL'd modules to start
> exporting these symbols.
>
It is a completely naive idea. You export some symbols as
EXPORT_MODULE_GPL(). I write a wrapper which is GPL'd but i don't export
my symbols as EXPORT_MODULE_GPL(), i now can interface to your code from
a proprietry module without breach of license through my wrapper with
very little work on my part. Your probably the same people who run about
using ROT13 as encryption.
> There are some of us who strive to keep the kernel as "pure" as possible,
> for a variety of reasons, the main one for me being peace of mind (knowing
> my code base is supported, and bugfixes are cheap). Why is this so
> difficult for folks to grasp?
>
That is you decision and you are free to have it, but don't try and
force it on other people by saying if you don't have a system running
100% GPL'd (or compatibly) licensed kernel - we reserve the right to
ignore any bugs you try and inform us about, regardless of whether or
not is is to do with the binary only module. It isn't exactly
encouraging.
Perhaps a less blunt tool could be used to encourage people to release
GPL compatibly licensed code for their previously binary modules? I
think you risk manufacturers withdrawing the support they have given by
saying if they don't release their code we won't support anything to do
with it. Carrots work better than sticks.
Cheers
Martin
--
A girl and a boy bump into each other -- surely an accident.
A girl and a boy bump and her handkerchief drops -- surely another
accident.
But when a girl gives a boy a dead squid -- *that had to mean
something*.
-- S. Morganstern, "The Silent Gondoliers"
On Thu, 18 Oct 2001, Ben Collins wrote:
> On Thu, Oct 18, 2001 at 09:58:33AM -0400, Richard B. Johnson wrote:
> > On Thu, 18 Oct 2001, Adrian Bunk wrote:
> >
> > > On Thu, 18 Oct 2001, Richard B. Johnson wrote:
> > >
> > > >...
> > > > In the business world, something as simple as puts("Hello World!");
> > > > MUST be kept a trade secret. If it was written by an employee
> > > > in the context of his or her job, the company's stockholders owns
> > > > that line of code so no employee, even the President, is allowed
> > > > to give it away.
> > > >...
> > >
> > > IOW: Companies like IBM, SAP, Sun and SGI that made code available under
> > > the GPL (e.g. as part of the linux kernel or with of relicensed programs)
> > > weren't allowed to do this???
> > >
> > >
> > > Am I allowed to consider this a bad joke?
> > >
> > >
> >
> > It's no joke. Some companies require, in the process of producing
> > goods and services, that certain interface code and documentation
> > be provided. For instance, if I make an Ethernet card, it's in
> > the best interest of the company to sell as many boards as possible.
> > Therefore, certain information must be given away to obtain those
> > goals. So, I would provide register-level documentation, sample
> > source-code, and maybe even drivers for the majority of the known
> > Operating Systems.
> >
> > However, If my company makes Bomb Scanners (it does), I cannot
> > divulge to potential adversaries, either the competition or potential
> > bombers, how it works. It's just that simple.
> >
> > If your end product is a board that plugs into a PC, you have a
> > different set of rules than if your end product is a Bomb Scanner,
> > a Flight Management System, or a Numerical Milling Machine.
> > Basically, embedded stuff, both hardware and software, remains hidden.
>
> But that has nothing to do with stockholders claiming ownership of code
> written by an employee. That's a much deeper policy. So your assertions
> are way off base.
>
The assertions are right on. Not off base. The amount of "ownership"
exercised by the public in a publicly-held company depends upon the
capitalization, share dilution, and amount of outstanding shares. As the
ownership (stockholder votes) increases, the company policy becomes
becomes more of maximizing return on investment, and less of producing
good or services. This is Business 101. As stockholder equity increases,
eventually everything an employee produces becomes more-and-more owned
by the public investors, and less-and-less owned by some company
"division" or "department". In effect, the "company" exists only for
the convenience of its share-holders. General Electric is an example.
> Now, if your driver just interfaces your hardware with userspace, then
> that driver likely contains nothing of extreme importance for how your
> "Bomb Scanner" works, and releasing it under GPL is not going to be a
> problem. Your application contains those details. I don't see how you
> are getting at the application level being considered a corrupter of the
> kernel's GPL stringency. Do you actually see this occuring?
>
We have a data interface that feeds high-speed data from 4,000 +
X-Ray detectors directly to memory at RAM/Bus memory speeds. There
is no way in hell that we are going to let the world know how this
is done. We can't protect it by patent because there is a lot of
"prior art" which has been confused by a Patent Examiner as something
in the past that actually worked.
Review of the driver source-code by a competent hardware designer,
who knows how to read code, will give away the trade secret. Then
anybody, who hasn't bothered to invest the millions of dollars of
Engineering development cost, can make one of these cheaper and
put us out of business.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
> Perhaps a less blunt tool could be used to encourage people to release
> GPL compatibly licensed code for their previously binary modules? I
> think you risk manufacturers withdrawing the support they have given by
> saying if they don't release their code we won't support anything to do
> with it.
This has been the case for a long time already (so long that I can't
remember
if/when it started:), so how did this change recently ? It didn't...
And vendors who supply binary only modules know already that they get to
do
all the support as rules of the game. That didn't change either.
It's just that it's now easier for the people who get to handle
bugreports
to ask "which modules do you use" as first question if the tainted flag
is set,
instead of spending hours investigating a weird oops.
Greetings,
Arjan van de Ven
(and yes, I do get a fair share of bugreports and really like to know
which
reports I should be suspicious of and ask for module lists etc)
"Richard B. Johnson wrote:"
> We have a data interface that feeds high-speed data from 4,000 +
> X-Ray detectors directly to memory at RAM/Bus memory speeds. There
> is no way in hell that we are going to let the world know how this
Oh my gosh. You aren't working on a project for CERN too, are you?
Peter
On Thu, 18 Oct 2001, Peter T. Breuer wrote:
> "Richard B. Johnson wrote:"
> > We have a data interface that feeds high-speed data from 4,000 +
> > X-Ray detectors directly to memory at RAM/Bus memory speeds. There
> > is no way in hell that we are going to let the world know how this
>
> Oh my gosh. You aren't working on a project for CERN too, are you?
>
> Peter
No. Amongst many other things, we make the "Exact" baggage scanners
market by L3 division of Lockheed-Martin. All airplane baggage
will eventually be scanned (at baggage-conveyor speeds) at all
airports serving commercial airliners. The scanning detects
various devices and chemical compounds. It uses X-Rays of different
frequencies (hardness) to actually detect chemical compounds
at their elementary atomic levels.
For instance, most X-Ray systems only detect density. The X-Ray
density of a jar of peanut butter is similar to the density of
the explosive C4. Without chemical discrimination, anybody with
a jar of peanut butter in their luggage is suspect. However,
by using dual-energy, we can zero in on nitrogen, while allowing
the same-density substances containing other atoms.
We do this in an incredibly fast hardware/software environment
so that baggage runs through the machines at normal conveyor
speeds, not slowing down the loading/boarding process.
This is NOT the scanner used to X-Ray carry-on luggage. That
uses a much less robust and cheaper process because there
are attendants present that can ask that suspect carry-on
luggage be opened for inspection.
Presently, we are using DEC/Alpha machines for the hardware/software
interface. Our next generation will use PC/AT/Linux machines for
the same function (at twice the performance).
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
"A month of sundays ago Richard B. Johnson wrote:"
> On Thu, 18 Oct 2001, Peter T. Breuer wrote:
>
> > "Richard B. Johnson wrote:"
> > > We have a data interface that feeds high-speed data from 4,000 +
> > > X-Ray detectors directly to memory at RAM/Bus memory speeds. There
> > > is no way in hell that we are going to let the world know how this
> >
> > Oh my gosh. You aren't working on a project for CERN too, are you?
>
> No. Amongst many other things, we make the "Exact" baggage scanners
> market by L3 division of Lockheed-Martin. All airplane baggage
Well, in that case, you may find that there _IS_ prior art. The
triggers for the LHC at CERN are PCI boards running to linux (or
solaris) machines. I seem to be involved in projects to take the data
off at about 13GB/s (as far as I recall the back of envelope). The
first ring is about 1000 machines in the current design, I believe.
> will eventually be scanned (at baggage-conveyor speeds) at all
> airports serving commercial airliners. The scanning detects
> various devices and chemical compounds. It uses X-Rays of different
> frequencies (hardness) to actually detect chemical compounds
> at their elementary atomic levels.
The CERN stuff gets about 6000 particle traces per collision. Each
particle marks several detectors in a sandwich, and the raw data (lots
of bytes per sandwich layer) is taken off and the trajectories and
timings for each trace are computed. Essentially "digital Xray
detection". I forget what the collision rate is at the target. High
enough that the events aliase.
> For instance, most X-Ray systems only detect density. The X-Ray
> density of a jar of peanut butter is similar to the density of
> the explosive C4. Without chemical discrimination, anybody with
> a jar of peanut butter in their luggage is suspect. However,
I suspect them anyway. I've never seen anything in peanut butter.
> by using dual-energy, we can zero in on nitrogen, while allowing
?? You mean the nitrogen in the explosive?
> the same-density substances containing other atoms.
[to go through]
> We do this in an incredibly fast hardware/software environment
> so that baggage runs through the machines at normal conveyor
> speeds, not slowing down the loading/boarding process.
I've news for you .. the passengers were already slowed down by the
visual Xray inspection as they came in, and as there are on average one
piece of hold baggage per passenger, the bottleneck is at passenger
entry to the airport!
> This is NOT the scanner used to X-Ray carry-on luggage. That
> uses a much less robust and cheaper process because there
> are attendants present that can ask that suspect carry-on
> luggage be opened for inspection.
But it seems to be the bottleneck. I imagine most airports have about 4
carry-on scanners, and each passenger takes 60s to go through, so you
cannot have an overall _average_ flow of more than about 4 pieces of
_hold_ baggage per minute to deal with.
Granted, the peaks might be higher, as they are bottlenecked by the
checkin desks. There may be about 100 of those, and each passenger
probably takes 3mins at them, so the flow can peak at about 33 hold
bags per minute (at 1pc/passenger). But there must be long intervals
of low activity because of the average flow calculation.
> Presently, we are using DEC/Alpha machines for the hardware/software
> interface. Our next generation will use PC/AT/Linux machines for
> the same function (at twice the performance).
I see.
Peter
* Martin Donnelly <[email protected]> on Thu, Oct 18, 2001:
>
> It is a completely naive idea. You export some symbols as
> EXPORT_MODULE_GPL(). I write a wrapper which is GPL'd but i don't export
> my symbols as EXPORT_MODULE_GPL(), i now can interface to your code from
> a proprietry module without breach of license through my wrapper with
> very little work on my part.
Prorprietary modules do that anyways, your workaround isn't anything new
(NVIDIA's module comes to mind). If you don't want to use
EXPORT_MODULE_GPL(), don't use it, and if you're willing to make the effort
to write a wrapper and accept the blight that comes with it, by all means
go ahead. Thanks for pointing out the obvious.
> Your probably the same people who run about using ROT13 as encryption.
I fail to see how this statement has anything to do with the above
paragraph. But anyway, I use PGP-based and other forms of encryption (did
you notice that this e-mail is signed?).
>
> That is you decision and you are free to have it, but don't try and
> force it on other people by saying if you don't have a system running
> 100% GPL'd (or compatibly) licensed kernel - we reserve the right to
> ignore any bugs you try and inform us about, regardless of whether or
> not is is to do with the binary only module. It isn't exactly
> encouraging.
>
It's not force, it's a choice. That taint mechanism is by no means force,
it doesn't force modules to be GPL-compatible, it just taints when a module
isn't. Tainting and EXPORT_MODULE_GPL() are two entirely different things,
intended to accomplish entirely seperate goals. Are you able to make that
distinction? It seems from the posts so far that most people can't. The
only thing in common with tainting and EXPORT_MODULE_GPL() is the
MODULE_LICENSE() macro. Any other comparisons are apples and oranges.
> Perhaps a less blunt tool could be used to encourage people to release
> GPL compatibly licensed code for their previously binary modules? I
> think you risk manufacturers withdrawing the support they have given by
> saying if they don't release their code we won't support anything to do
> with it. Carrots work better than sticks.
>
The GPL was the tool, but since binary-only modules were allowed
EXPORT_MODULE_GPL() takes on that role. And again, you confuse tainting
with GPL-only symbols, the support issue comes from tainted kernels - so
no, we won't support anything to do with unreleased code.
M. R.
On Thu, Oct 18, 2001 at 05:40:08PM +0200, Peter T. Breuer wrote:
> detection". I forget what the collision rate is at the target. High
> enough that the events aliase.
40MHz
In case anybody cares ;-)
Jan
"Richard B. Johnson" wrote:
>
> On Thu, 18 Oct 2001, Ben Collins wrote:
>
> > On Thu, Oct 18, 2001 at 09:58:33AM -0400, Richard B. Johnson wrote:
> > > On Thu, 18 Oct 2001, Adrian Bunk wrote:
> > >
> > > > On Thu, 18 Oct 2001, Richard B. Johnson wrote:
> > > >
> > > > >...
> > > > > In the business world, something as simple as puts("Hello World!");
> > > > > MUST be kept a trade secret. If it was written by an employee
> > > > > in the context of his or her job, the company's stockholders owns
> > > > > that line of code so no employee, even the President, is allowed
> > > > > to give it away.
> > > > >...
> > > >
> > > > IOW: Companies like IBM, SAP, Sun and SGI that made code available under
> > > > the GPL (e.g. as part of the linux kernel or with of relicensed programs)
> > > > weren't allowed to do this???
> > > >
> > > >
> > > > Am I allowed to consider this a bad joke?
> > > >
> > > >
> > >
> > > It's no joke. Some companies require, in the process of producing
> > > goods and services, that certain interface code and documentation
> > > be provided. For instance, if I make an Ethernet card, it's in
> > > the best interest of the company to sell as many boards as possible.
> > > Therefore, certain information must be given away to obtain those
> > > goals. So, I would provide register-level documentation, sample
> > > source-code, and maybe even drivers for the majority of the known
> > > Operating Systems.
> > >
> > > However, If my company makes Bomb Scanners (it does), I cannot
> > > divulge to potential adversaries, either the competition or potential
> > > bombers, how it works. It's just that simple.
> > >
> > > If your end product is a board that plugs into a PC, you have a
> > > different set of rules than if your end product is a Bomb Scanner,
> > > a Flight Management System, or a Numerical Milling Machine.
> > > Basically, embedded stuff, both hardware and software, remains hidden.
> >
> > But that has nothing to do with stockholders claiming ownership of code
> > written by an employee. That's a much deeper policy. So your assertions
> > are way off base.
> >
>
> The assertions are right on. Not off base. The amount of "ownership"
> exercised by the public in a publicly-held company depends upon the
> capitalization, share dilution, and amount of outstanding shares. As the
> ownership (stockholder votes) increases, the company policy becomes
> becomes more of maximizing return on investment, and less of producing
> good or services. This is Business 101. As stockholder equity increases,
> eventually everything an employee produces becomes more-and-more owned
> by the public investors, and less-and-less owned by some company
> "division" or "department". In effect, the "company" exists only for
> the convenience of its share-holders. General Electric is an example.
>
> > Now, if your driver just interfaces your hardware with userspace, then
> > that driver likely contains nothing of extreme importance for how your
> > "Bomb Scanner" works, and releasing it under GPL is not going to be a
> > problem. Your application contains those details. I don't see how you
> > are getting at the application level being considered a corrupter of the
> > kernel's GPL stringency. Do you actually see this occuring?
> >
>
> We have a data interface that feeds high-speed data from 4,000 +
> X-Ray detectors directly to memory at RAM/Bus memory speeds. There
> is no way in hell that we are going to let the world know how this
> is done. We can't protect it by patent because there is a lot of
> "prior art" which has been confused by a Patent Examiner as something
> in the past that actually worked.
>
> Review of the driver source-code by a competent hardware designer,
> who knows how to read code, will give away the trade secret. Then
> anybody, who hasn't bothered to invest the millions of dollars of
> Engineering development cost, can make one of these cheaper and
> put us out of business.
And what about the simple fact that the tainted flag will become
entierly useless when in fact most of us will be using tainted
kernel? Hey anyway most of us are now deploying "tainted" linux
distributions anyway and NOT GNU/Linux Debian. Most of use use
distros and kernels far away from the official Linus kernel too, so
this flagging doesn't help anybody it's just BLOAT.
On Thu, Oct 18, 2001 at 07:02:08PM +0200, Martin Dalecki wrote:
> >
> > Review of the driver source-code by a competent hardware designer,
> > who knows how to read code, will give away the trade secret. Then
> > anybody, who hasn't bothered to invest the millions of dollars of
> > Engineering development cost, can make one of these cheaper and
> > put us out of business.
>
> And what about the simple fact that the tainted flag will become
> entierly useless when in fact most of us will be using tainted
> kernel? Hey anyway most of us are now deploying "tainted" linux
> distributions anyway and NOT GNU/Linux Debian. Most of use use
> distros and kernels far away from the official Linus kernel too, so
> this flagging doesn't help anybody it's just BLOAT.
So you think it is the responsibility of the l-k hackers to field bugs
against highly hacked and forked versions of the kernel from a distro
that you use?
Ben
--
.----------=======-=-======-=========-----------=====------------=-=-----.
/ Ben Collins -- Debian GNU/Linux \
` [email protected] -- [email protected] -- [email protected] '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Ben Collins wrote:
>
> On Thu, Oct 18, 2001 at 07:02:08PM +0200, Martin Dalecki wrote:
> > >
> > > Review of the driver source-code by a competent hardware designer,
> > > who knows how to read code, will give away the trade secret. Then
> > > anybody, who hasn't bothered to invest the millions of dollars of
> > > Engineering development cost, can make one of these cheaper and
> > > put us out of business.
> >
> > And what about the simple fact that the tainted flag will become
> > entierly useless when in fact most of us will be using tainted
> > kernel? Hey anyway most of us are now deploying "tainted" linux
> > distributions anyway and NOT GNU/Linux Debian. Most of use use
> > distros and kernels far away from the official Linus kernel too, so
> > this flagging doesn't help anybody it's just BLOAT.
>
> So you think it is the responsibility of the l-k hackers to field bugs
> against highly hacked and forked versions of the kernel from a distro
> that you use?
Of course not, I never said that. But introducting this
stiupid tagging wan't help them anyway... so why do they introduce it?
The same solution applys as ever - just say: "We don't care about
kernels different from anything on ftp.kernel.org." and let it be...
I really see no advantage in this tagging. It's a common trap
in the western world to beleve that the introduction of some
"anti law" is actually preventing "voilence" from happenning.
> I really see no advantage in this tagging. It's a common trap
> in the western world to beleve that the introduction of some
> "anti law" is actually preventing "voilence" from happenning.
nonsense. tagging is exactly like the seal on a bottle of juice:
it doesn't prevent someone from opening the bottle and contaminating it,
but it does let you to verify that this hasn't happened.
> Perhaps a less blunt tool could be used to encourage people to release
> GPL compatibly licensed code for their previously binary modules? I
> think you risk manufacturers withdrawing the support they have given by
> saying if they don't release their code we won't support anything to do
> with it. Carrots work better than sticks.
Carrots work on rabbits, they don't work on hungry weasels.
Where there are fundamental interfaces for genuinely seperate works then
EXPORT_SYMBOL is appropriate. When its part of a shared library of GPL code
for making GPL driver writing easier then EXPORT_SYMBOL_GPL is appropriate.
In most respects it is up to the authors. You should also bear in mind that
we have authors who are not prepared to see GPL code potentially abused and
who would stop contributing to the linux kernel if EXPORT_SYMBOL_GPL was
not available