Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Mosix looking into GPL concerns 90

Posted by sengan from the doing-the-right-thing dept.
The Mosix people are now looking into the Linux GPL issue. Since it was Linus and the other core kernel developers who gave the binary module dispensation (binary modules may be inserted into the kernel as long as they do not require kernel modifications of their own) it seems odd they are talking to the FSF about this. But at least this is a move in the right direction.
This discussion has been archived. No new comments can be posted.

Mosix looking into GPL concerns More

Mosix looking into GPL concerns

Comments Filter:
  • The GPL makes exceptions for libraries included with the compiler or operating systems, such that they may be non-free.
    And if you don't distribute the binaries, you're not in violation of the GPL, because it doesn't cover use, only distribution.
  • Don't waste /. bandwith with stupid, inaccurate drivel.

    I think you summed it up right there (the only accurate part of your post).

    Linus does not have any legal authority over Linux. He holds copyright over the portion of the Linux code that he himself wrote (he estimates that to be around 10%). In order to give permission to link binary modules, every copyright holder would have to authorize the license change. That includes everyone who has ever contributed code to Linux, or whose GPLd code the Linux team has used.
  • Posted by Mr. Assembly:

    Why do they need a "support package" to screw an interface for their binaries?? The argument I find cogent is other people hooking on proprietary doo-dads eventually effecting a closed, non open source standard that is owned by some large company that would just assume to pee on your need for know how "their" interface works and implement FUD policy torwards anybody who might.
    Stallman today called this a "big loophole" given by Linus, and would "take a lot of work to close". I would suggest that the other owners of the kernal code tell these guys to back off...

  • It goes against the spirit of the GPL (and Linux). The module is, for all practical purposes, and enhancement to the Linux kernel. It's not a device driver or file system or other traditional "add-on". It should be free, but they found a loop-hole.


    On the bright site, we know this kind of thing won't become common because their patches will never make it into the mainstream kernel. They'll have to keep producing patches against each new kernel version.


  • But wouldn't that only apply to distributing statically linked binaries? Dynamically linked binaries (which are almost always what is distributed) do not contain the libraries until they are linked together at runtime, which is when the derived work is formed. The only issue is whether the header files that are compiled into KDE are restricted by the Qt license. Whether this is true depends on what they contain... IANAL, but IIRC #defines and prototypes and the like are not copyrightable. If, OTOH, there are macros or inline functions in there, that could be a problem, unless Qt were to exempt the header files from their license.
  • Their page says that they will stop distribution if there are license problems. That, however, won't cut it. If Linus et al. determine that the binary module exception doesn't apply since the mosix module requires kernel modifications, the binaries which have been distributed since yesterday automatically fall under GPL. This means that source for the module has to be provided for the cost of shipping. Linus et al. can demand that, and I sure hope they will.

    --

  • The only source they have to provide is the modified kernel, because it's a derivative work. Their module is their own code.

    The module uses GPL'ed kernel header files and requires extensive kernel modifications to function; the module cannot be separated from the modifications: it is one functioning whole. And that whole is a derivative work of the kernel and hence has to be licensed under GPL unless Linus et al. grant an exception.

    --

  • The way to do that would be to specify that derivative works must export have the same interface, or else the license reverts from GPL+exceptions to GPL. That probably necessitates a *detailed* binary interface definition for each release.
  • It wasn't a bad decision when he made it. Coming from a position of weakness as Linux was, it was a good way of boosting 3rd party driver support.

    Today however, now that Linux is enjoying a stronger position, I think it would be a good idea to reevaluate that decision.


    --
  • IIRC, the GPL has safeguards against linking GPL code to code with incompatible licenses, a la QT/KDE.

    Correct me if I'm wrong, but doesn't that mean Linus' decision was unconstitutional?


    --
  • Isn't that what all the hubub about QT was about? Linking against a non-GPL library?

    If one was in violation, the other would surely be too.


    --
  • they are technically correct except it's wrong what they are doing. did the kernel modification provision say absolutely no kernel modifications or no compiled kernels?? in my opinion it's stupid to make kernel modications because if that code is changed, you have a maintanence nightmare!

    "The lie, Mr. Mulder, is most convincingly hidden between two truths."
  • Face it, we are not going to get most new hardware support without this. So there. And what Linus allows sounds no different than allowing binary-only programs to run on Linux and people don't seem too upset about that (yea, some are...)

    What Mosix is doing should be totally disallowed. Even if they give the complete source code for the "kernel mods". With these rules MicroSoft could make "MSLinux with Windows compatability" where they provide a giant "binary module" and "kernel mods" which implement 500 new system calls, all of which call a numbered entry point in the "module".

    Any kernel modifications must be approved by the development team and Linus and put into the official source tree. And if somebody convinces them that they really need their new module interface added (unlikely imho), there should be a requirement that a "reference implementation" of that module be provided with working source code so other people can understand exactly what the modifications do. (this reference implementation must be fully functional, but it may be useless, possibly because it is no faster than doing the same function some other way because it does not include the secret hardware/software that the module writers have).
  • calm down, Linus and co are *not* clueless, when it comes to licensing. You are allowed to make binary-only modules for Linux, as long as 1) you stick to the published, exported interface (i.e list of symbols), and 2) your module doesn't require specific kernel mods. so MOSIX is wrong on the 2nd count, and no, you can't port Linux to the BlahBlahCrap processor and hide most of the code in a binary-only module, or anything like that. you can, however, hide most of the drivers that way.
  • Since a module for Linux can do almost anything, his decision to allow binary-only modules means that the Linux kernel is down the toilet, since almost anything can be done to it without revealing the sources. The kernel could be heavily modified or ported to new platforms with most of the code kept in a ``module''.

    I think I will stick with GNU. They understand that freed software means just that: freed. There are no exceptions for ``modules'' to be nonfree. Given the recent thrust towards the commercialisation of Linux, this could be the beginning of the end of free GNU/Linux was we know it. Thank God that GNU will go on.

    Cheers,
    Joshua.

  • Firstly, I did not realise Linus said that non-freed-source modules were valid only without kernel modifications. My error; that's quite a bit more reasonable.
    I have a question, however, concering a project on which I am working:
    I am working to getting a highly modified Linux kernel running in OS/2. It's difficult, due to things like the fact that Linux and OS/2 have different ideas of what the flat selector should be, and the gyrations neccessary to trap software interrupt 128 in OS/2. But it's doable. (No mail about it please; it's nowhere near pre-alpha quality yet.)
    This kernel is compiled with a non-free compiler (IBM C Set/2) and linked with a number of non-free libraries. They aren't kernel modules, either: they are statically linked with VMLINUX.DLL. Am I violating any licences?
    I have decided my situation is the same as running Linux on a CPU that uses lots of microcode. Since JCXZ or LAHF is probably invoking reams of microcode, and that microcode is non-free, it's the same situation as linking VMLINUX.DLL with DOSCALL1.DLL and DDE4CRTM.DLL.
    Feel free to post your comments or mail them to me.
  • I use the GPL because I want to be compensated for my hard effort in writing software. I consider having other people add to my work, and in reciprocalicity allowing me to use their works, to be compensation.

    MOSIX is violating the Linux copyright. They can't do that. It's no different than making pirated copies of Quake 2; you have to either follow the software licence, or not use the software at all.

    If you don't like the GPL, don't use it. Stay away from GPLd works. Use only non-free software. But do not dare to join the Church of Emacs!
  • From Kernel Traffic [opensrc.org]

    "Bend Over, Boy, Because You Have It Coming To You."

  • The COPYING file in the Linux source tree is helpful:

    NOTE! This copyright does *not* cover user programs that use kernel
    services by normal system calls - this is merely considered normal use
    of the kernel, and does *not* fall under the heading of "derived work".
    Also note that the GPL below is copyrighted by the Free Software
    Foundation, but the instance of code that it refers to (the Linux
    kernel) is copyrighted by me and others who actually wrote it.

    Linus Torvalds

    ----------------------------------------

    GNU GENERAL PUBLIC LICENSE
    Version 2, June 1991



    [I won't reproduce the rest of it here.]

    Which brings up the question: Does the term "user programs" also include modules? Obviously a module runs in kernel space, but for the same reason can't use "normal system calls". I think that passage was probably written to reassure developers that they could write proprietary apps. And supposedly Linus has given the okay to proprietary modules, so long as they don't require kernel modifications.

    The MOSIX developers are walking a very thin line here. They have a proprietary module that requires kernel mods, but the kernel mods themselves are GPL'd. OTOH, it sounds like the only mods they are making are in adding a /proc interface. It's too bad there's no method of having a module make additions to /proc when it is loaded. We could avoid the whole issue that way. Looks like maybe it could be done with a proc_register() call, but then I'm no kernel hacker.

  • From what I can see, they provide two things: the binary-only module, and the GPL'd modifications to the kernel sources needed to use the module. As long as they keep any mods to the kernel sources themselves GPL'd and in source form, the module itself should fall under the module exception. What would violate the license would be distributing a modified, binary-only kernel, and they aren't doing that.

  • The exception only covers modules that don't require kernel modifications. So it doesn't matter that they're claiming that the two are seperate products--the modules dependancy on the patches means it has to be GPL'ed.

    I don't see this. You might have a point, if the kernel mods depended on the module ( ie. you can't run the modified kernel without the non-GPL module ). Their mods, from what I can tell, leave the kernel usable without their module and could in fact be used by modules other than theirs if someone wanted. When they released the GPL'd patches they essentially created a new published kernel interface subject to the GPL, and they can release a non-GPL module that uses that interface.

    Frankly I'd rather not require all kernel modules to be GPL'd. It's just not in our interest. I'd like everything to be GPL'd, but given the choice between having the functionality non-GPL'd and not having the functionality, I'd rather have it.

  • Actually, EULAs have been upheld in court. The judge, however, seems to have made enforceability dependent on three conditions. One of those conditions is that a refund must be available for those who don't agree to the terms. I forget what the other two are. You will find links to the case and an analysis of it at http://www.metasystema.org/dell.mhtml [metasystema.org]. The links I refer to are near the bottom of the page.
  • Everyone:
    Copy and send this to mosix@cs.huji.ac.il [mailto]

    Dear Sirs:

    While I have no interest at this moment in pursuing load balanced clusters in linux, it is something that I believe is a powerful and useful addition to the linux computing environment.

    As such I respectfully implore you to consider releasing the load balancing and process migration tools under the gpl.

    While this is of prime political interest within the open source community, it would garner tremendous publicity and also aid you in providing a rich tool set.

    Other similar efforts like Beowulf have made significant impact in the programming community and it would be a shame if your efforts, especially as they are research oriented , go unappreciated, since the research community at large cannot benefit from it.
  • With respect to copyright law, what Linus says about works derived from the Linus kernel is pretty irrelevant, since he does not control the copyright to the entire kernel.
  • What is to prevent the MOSIX guys from "forking the tree" and making their own Linux kernel, releasing it under the GPL, and claiming the exact same "binary module" rules?

    I dunno. What's to prevent MS from firing all their programmers? It's the same situation.

    The Mosix people, if they fork the code, keep the benefits of Free Software (think speech not beer), but lose most of the benefits of the Open Source development of Linux. In short, what they have to lose is the massive free (think beer not speech) labor of all the developers who have worked on Linux up to this point, and who will continue to improve Linux in years to come.
  • IF they distribute a work derived from Linux, they MUST do so under the terms of the GPL.

    The only practical exception I can come up with is if the Israeli governmental-military-industrial-research complex says "This is for us, it's classified, you can't have it!"

    Copyright law? What copyright law? We have this fission bomb, see, and we're just itchin' to use it...
  • It doesn't really matter to me if you run Linux or NT Server - Enterprise. What does matter to me is that the Linux kernel be protected against commercial interests who would take the code and hijack it if they could. This is not as farfetched as it sounds. Imagine this -

    Microsoft Linux. Linux at the core, with loads and loads of MS extensions built in. Per the GPL, they release their mods to the kernel, with great fanfare - "MS has joined the Linux community!" However, all their mods amount to would be APIs for their proprietary, non-GPL, non-free modules. They would ship this as part of Windows 9x, Windows NT, Windows 2000, etc. Suddenly, MS- Linux (tm) is shipping on 50,000 machines per day, and before too long, thanks to the MS marketing machine, "Linux", in the mind of the computing public, means "MS-Linux". Naturally, all the commercial software provideers would jump on THIS bandwagon, and Linux would be back to being a niche OS. All the gains made in the marketplace in the last year would be lost, as Linux was uninstalled and MS-Linux was installed on servers throughout the corporate world.

    Now, there's nothing wrong with being a niche OS. It's just that I have this dream that someday EVERYONE will have free software, not just the techno-elite who feel that if you can't write a browser in PERL then you barely deserve to compute :)

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close