Re: General Discussion about GPLness

[Stephan von Krawczynski]

On Mon, 24 Feb 2020 00:46:03 +0100
Bernd Petrovitsch <bernd@xxxxxxxxx> wrote:

> Hi all!

Hello Bernd,
 
> On 23/02/2020 21:47, Stephan von Krawczynski wrote:
> [...]
> > I do understand why you cannot enter a discussion with your real name, as
> > most  
> 
> I ignore folks who don't use their real name - this is since Usenet
> times an indication for a troll ...

Well, yes. But I don't want to start a topic and ignore the first answer right
away ... Call me naive
 
> > of your input is of zero quality - and below.  
> [...]
> >                                                              But our story
> > is about kernel modules, something everybody is free to write and publish,
> > with a  
> 
> ... publish implicitly with a GPLv2 or compatible license ...

Ok, you cannot really mean this. Because what you say is that no company
making some hardware is allowed to produce a closed-source kernel driver for
it. You know who are the last ones on the planet taking that approach? It's
China. If you want to build some car there, you have to give them all the
details of everything and only then are allowed to do a joint-venture with
chinese where you are not allowed to hold a majority.
You are saying that every company creating new hardware must open up the
details to it so that they themselves or someone else is capable to write a
GPL-driver for it. Is that the world you want to live in? China? Really?
 
> > defined and open interface for interaction. No kernel code is modified in
> > that  
> 
> And that's a point which is completely wrong: the only *defined*
> interface of the kernel is sys-calls, /proc and similar. And all of this
> is from user-space to kernel-space and back.

This is "said" to be so. But since I wrote several kernel drivers I know that
there is at least a skeleton of what a driver should look like. And this means
that there is a definition. I know what you mean. It is said that none of the
interfacing is defined as some standard written in stone. But we all know the
reason: the project wants to stay evulatory and wants to be able to implement
new - possibly better ideas. But only because its flowing does not mean there
is none. Else there would not be lots of people working on different drivers,
filesystems and the like. They all have to meet at some point in the code. And
that meeting point(s) is(are) the open interface. And it's open because
everyone is allowed to read the source and use the exported functions (be them
GPL-defined or not) to write some _extensions_.
 
> There is no (and never was) a "defined interface" within the kernel
> (inter-operating in kernel space) in any direction simply because the
> kernel-internal (infra)structure changes more or less constantly - some
> may call that evolution;-)

Yes, read above.
 
> And I don't get what an "open interface" here couls seriously mean. You
> surely don't want to call the list of the GPL_EXPORTed C functions
> (which may change from one kernel version to the next) an "open
> interface" (whatever that should suggest).
> 
> At most the list of GPL_EXPORTed C functions is a de-facto interface and
> that may change from one git-commit to the next.

The lifetime of the details of this interface is not relevant. Some last
years, some maybe only days. Nevertheless the EXPORT per se means that someone
_else_ should and can use them. Otherwise there would be no EXPORT definition.
 
> > sense. But you fail to understand that.
> > Hopefully others here do. I do not expect them to stand up and jump into a
> > discussion where you are a part of. But I hope people start to think about
> > it  
> 
> And you are barking up the wrong tree. The discussion has to happen in
> the ZFS-world so that they fix their license if they want to interface
> with any GPL software (without sys-calls etc. in between - WTF it works
> via FUSE) like they seen to do now.

Ok, now please stay serious. FUSE is nothing more than a hack for people who
want to make case studies on projects but is completely useless in production.
Because it is DEAD slow. If you want to check out, look at glusterfs (that
never managed to be implemented as kernel driver). And nobody used ZFS on FUSE,
because it was unusably slow. Since it has become a kernel space driver it is
amongst the best fs around.
But zfs is not the main issue. It is only an example of the problem. 
Companies and other entities must be allowed to make kernel drivers and
therefore interface with the kernel in kernel space no matter what licensing
they prefer. This is my opinion. I would love to hear if this really is the
projects' policy or not though. This is what this thread is all about.

Of course, I would prefer a GPL driver as well. That's why I use ATI and not
nvidia. But nevertheless I think nvidia and all the others should be allowed
to make their drivers. I'd say the rest is market/customer choice.

> MfG,
> 	Bernd

-- 
Regards,
Stephan