Slashdot Mirror


Salon Article on Red Hat and Cygnus

krshultz writes "Salon has a piece on Red Hat's aquisition of Cygnus Solutions. It mentions concerns that shareholders might see more dollar signs in proprietary software, and there's an interesting bit about the future of things like gcc." I didn't know gcc had a steering committee. It's nice to see its developers concerned about what all this will mean to the community.

20 of 75 comments (clear)

  1. The Future of GCC by devphil · · Score: 3

    Yes, GCC does have a steering committee, mainly to prevent a single person or group from exerting too much control over the project, thus paralyzing development. (The entire EGCS idea was to get away from exactly that problem, which is /why/ there was no new GCC for a long time.)

    The Salon article talks about Jeff [Law] mentioning changes to the steering committee. This is the first article in the thread:

    http://egcs.cygnus.com/ml/gcc/1999-11/msg00421.h tml

    and the "changes" article comes later in the thread IIRC. Currently, Cygnus/RH employees together still don't have anywhere near a majority on the committee.

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  2. Good Grief by Bob-K · · Score: 2

    from the article: "I don't think a corporation, particularly a public one, whose allegiances are only to its shareholders and its customers, can be trusted to keep software free"

    Folks, believe in it. Have all the doubts you want about corporations and the people who operate them. They are, indeed, only out to make a buck. And for some, free software is how they do it.

    A company that deals in free software would not be better off selling proprietary software, otherwise, they'd have started out doing that in the first place.

    Stop worrying. Red Hat is Red Hat, Microsoft is Microsoft. They're both out to make a buck, and they're both doing well. Neither is going to adopt the other's way of doing things.

    It's just weird that so many supporters and developers of free software are fretting about it's future, while at the same time, investors are expressing their confidence by pouring money into it.

  3. Should we fear Red Hat? by bgarcia · · Score: 3
    I'm sure we'll now see another round of everyone calling Red Hat "the next Microsoft". I was always one of the first to defend Red Hat. They have a great history of releasing everything they create under the GPL. There was absolutely no reason to expect them to do something wrong.

    But I recently discovered something that now has me wondering if this will continue to be the case.

    In Red Hat 6.1, there is a new program called the Red Hat Update Agent . Basically, it appears to be a program that allows you to automatically download and optionally install updated RPM's. It sounds like a wonderful new addition, and I wanted to try it out.

    Well, you have to be a registered user. But that's fine, there's nothing wrong with that. They only want registered users to access their upgrade site (priority.redhat.com). I completely understand and agree with that. This is a service after all.

    Because of this, I imagined that I (or anyone else) could simply setup one of these Update Agent servers myself. Knowing that Red Hat releases everything they create under the GPL, I started looking for the server-side CGI scripts.

    I couldn't find them.

    Now, it might just be that I didn't look hard enough. I have looked all over the FTP site, and I've tried several queries in their site's search engine. I haven't tried to actually send email to anyone at Red Hat, and I haven't actually asked anyone on a public forum (until now). But I'm still a little worried that the source for this script wasn't as easy to find as the sources for any other Red Hat software.

    So, is it available? Or is Red Hat going to keep this script secret so that only registered Red Hat users can enjoy the benefits of the Update Agent?

    --
    I'm a leaf on the wind. Watch how I soar.
    1. Re:Should we fear Red Hat? by acroyear · · Score: 2
      There's a difference between releasing software under the GPL and not releasing software at all.

      RedHat is fully entitled to developing software that is never released and strictly used internally (and code executed on a server machine, not on your machine, could definitely be called "internal"). This code, therefore, does not need to be GPL, nor do you have any "right" to see it. You have the right to the source code of the update agent client (assuming its GPL like everything else), because that is run by you on your machine. A GPL client does not require a GPL server (look at gAIM).

      Or is Red Hat going to keep this script secret so that only registered Red Hat users can enjoy the benefits of the Update Agent?

      Why do you feel that you have the "free" right to services that others pay for?

      The code and the binaries for RedHat are "Free" (in Stallman's sense of the word). The service by which you acquire them is NOT. If someone you know does the upgrade, they can give you the RPMs all they want. RedHat does release the RPMs on their main servers for free. This is more than is necessary for compliance with GPL. They don't have to even put them on the servers at all. Simply offering to sell the media with the source codes at the cost of the media is all that is required (like when you could buy the GNU tapes, back in the early nineties; hence, the 1.95 redhat cds from third-party types).

      The Priority server and its interfaces are not for everybody. Access to them can be restricted without any violation of the GPL, nor any "bad attitudes" on their part. It is the service of speed/ease that you pay for, not the code.

      The service is why RedHat is what it is today. If you don't like the terms of service, go to another distribution vendor.

      --
      "But remember, most lynch mobs aren't this nice." (H.Simpson)
      -- Joe
    2. Re:Should we fear Red Hat? by bgarcia · · Score: 2
      RedHat is fully entitled to developing software that is never released and strictly used internally
      Absolutely. I totally agree. However, Red Hat has stated in the past that they will release all their software under the GPL. I guess I was just trying to hold their feet to the fire. Turns out that I was off base, and it wasn't necessary.
      Why do you feel that you have the "free" right to services that others pay for?
      I don't want access to the service. I wanted access to the code so that others (me) can provide the same service (in my lan, to support a bunch of machines internally, for example).

      But as Michael Johnson has explained, the code is pretty much tied to thier internal systems, and thus probably wouldn't be too useful in and of itself. But they have made the protocol available, which is just as good as far as I'm concerned.

      I'm sorry if I gave the impression that I wanted the service for free. I don't. I just want the code (or the protocols).

      --
      I'm a leaf on the wind. Watch how I soar.
  4. Panic mongering by DaveWood · · Score: 2
    Companies are fragile endeavors. "Free software" is a social force - perhaps it's the manifestation of a collective frustration with commercial software? ;) But one way or another, as long as programmers have free time, there's nothing Redhat's shareholders, Bill Gates, or anyone else can do to stop them from coding what they feel like coding. And as long as Windows is still out there crashing desktops with abandon and wasting smart people's time all over the world (God bless it), anyone with a sense of self-respect and a modest ability to write code will work on Linux... or FreeBSD... or whatever's next.

    Barring any harrowing advances in intellectual property law, Stallman's gift, the GPL, insures that no one, no matter how eeee-vile, will ever be able to take the codebase from them.

  5. GCC is copyrighted by FSF, RH can't change that by rsidd · · Score: 2

    I don't see why anyone is worried about Red Hat changing the GPL status of GCC. The entire existing codebase is copyrighted by the FSF. So there is no way Red Hat can alter the licensing of that. Therefore any contribution they make should also be GPL'd. Of course they may or may not assign the copyrights to the FSF, but they certainly will if they want their changes to be used. In any case, they can't change the licence without rewriting the entire existing code base.

    1. Re:GCC is copyrighted by FSF, RH can't change that by Per+Abrahamsen · · Score: 2

      > Wanna bet it's *all* copyrighted by the FSF? I
      > submitted a small patch once, and it was
      > accepted, and I never signed any forms.

      The policy is that contributions of less than 10 lines of code are too small to fall under copyright law, and thus does not need papers. I don't know US law in details, but that would certainly be true under Danish law. Also, sometimes the maintainers rewrite patches rather than ask for papers.

  6. The Concept of Freedom by The+Dodger · · Score: 2

    Anyone who's heard RMS speak on the subject of free software will be well aware that the "free" bit doesn't just refer to the fact that you don't have to pay for it - it also refers to the fact that the user is free to do as he likes with the software. Because the source is available, he can modify it, something which can't be done with close, proprietary software.

    The GPL also ensures that anyone who benefits from free software also has a responsibility to ensure that others can benefit from any improvements they make to it. It's a two-way street - if I use a piece of GPL'd software, and add extra functionality, I can't exploit it commercially (i.e. sell it to people) unless I make it available under the terms of the GPL.

    Now, having said that, there is, of course, a danger that, if a piece of software was written and GPL'd by a company (or, indeed, an individual), they may decide to revoke it's free status and create a prorietary version. That is their right. There is nothing wrong in doing that, in and of itself. Obviously, there are some situations where companies have allowed something to be used for free until it becomes a de facto standard, and then started charging for it. But, with GPL'd software, things are different.

    There is a danger that a company such as Red Hat could acquire the copyright to some open source software and revoke the GPL, in an attempt to profit from a commercial version, thus forking the software. However, some companies already have both free and commercial versions of their software, and it doesn't cause many problems. Plus, the potential for backlash against Red Hat should make them careful of doing this sort of thing.

    In a sense, by going public, Red Hat has put itself in a position where it needs to be more careful about pissing us off than before. If the Linux community boycotted Red Hat, their stock price would take a serious nosedive.

    However, I am concerned that Red Hat employs (and, therefore, controls) too many of the key open source programmers. I don't think there's any ulterior or sinister motive in it, but I would much prefer if, instead of employing these coders, they allowed them to go work for, say, the FSF, and sponsored their salaries.

    That way, Red Hat would still be giving something back to the open source/free software movement, but it wouldn't actually be controlling it directly.

    Just my 0.05! ;-)

    D.
    ..is for Disastrous!

  7. not forking kernel by Michael+K.+Johnson · · Score: 3
    Red Hat is not creating a forked kernel; we maintain our patches as patches to Linus's kernel, allow anyone to use them, and try to push back everything that is not a customization specific to Red Hat Linux back to Linus on a time scale that he is comfortable with.

    Your differentiation between "the normal kernel dev people/the kernel development team" and Red Hat does not make a lot of sense in context, because Red Hat's kernel developers are a subset of "the normal kernel dev people" and, in fact, Alan Cox, who is one of the kernel developers who work for Red Hat, is the one who does most of the kernel patch integration work for the stable kernels for Linus.

    In any case, we actively integrate our patches with Linus's kernel. This is done individually by the developers working on their particular areas. The idea of maintaining a truly forked kernel is a nightmare to us, and no one in their right mind would want to do it.

    So we are, in this context, just another group of highly-motivated and focused kernel hackers contributing code to the Linux kernel in the normal way, which involves maintaining patches outside the Linux kernel until Linus accepts them.

    In a production context, we don't want to add patches to our official products that extend APIs beyond what Linus has blessed. The specter of us blessing an API that was subsequently cursed by the chief penguin himself would haunt us horribly.

    --

    -- "Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?"
  8. Embedded Redhat? by Indomitus · · Score: 2

    When I look at this, I don't see Redhat taking over GCC, I see Redhat taking over Cygus' expertise in the embedded OS space. Most of Cygnus' revenues come from their work on embedded systems and I don't see Redhat ignoring that. There's already a lot of work on Linux in embedded systems and if Redhat's smart, they'll push that work forward. Embedded is where it's at for the future IMHO. Just a thought...

  9. up2date servers by Michael+K.+Johnson · · Score: 3
    We aren't keeping it secret, we just haven't released it yet because there is no product to release. What we have is mostly code that is tied into our internal systems and is not generic. We don't have a product, just a bunch of custom code...

    So, we aren't going to keep the server functionality secret, it will just take time to create a release of the pieces you need to build a server. It will be released when it is ready.

    In the meantime, the the protocol is documented to some extent.

    --

    -- "Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?"
    1. Re:up2date servers by bgarcia · · Score: 2
      In the meantime, the the protocol is documented to some extent.
      Wonderful! The code isn't nearly as important as the protocol.

      I'm sorry I ever had doubts about the integrity of Red Hat! I give you my most humble apologies!

      --
      I'm a leaf on the wind. Watch how I soar.
  10. I wonder what Stallman thinks of this by DragonHawk · · Score: 2

    Does anyone have any information about what Richard Stallman thinks of the Red Hat+Cygnus merger?

    (Other then what they should call their products, I mean. ;-)

    --

    dragonhawk@iname.microsoft.com
    I do not like Microsoft. Remove them from my email address.
  11. cygwin licensing terms. by Joseph+Vigneau · · Score: 2
    From http://sourceware.cygnus.com/cyg win/licensing.html:

    What are the licensing terms?

    Most of the tools are covered by the GNU GPL, some are public domain, and others have a Berkeley style copyright. To cover the GNU GPL `restrictions', the basic rule is if you give out any binaries, you must also make the source available. For the full details, be sure to read the text of the GNU General Public License (GPL).

    The Cygwin API library found in the winsup subdirectory of the source code is also covered by the GNU GPL. By default, all executables link against this library (and in the process include GPL'd Cygwin glue code). This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library, your compiled programs will also have to be free software distributed under the GPL with source code available to all.

    Cygnus' Native Win32 GNUPro subscriptions include a commercial license for Cygwin that is more suitable for commercial use of the Cygwin library. Pricing for a GNUPro Subscription starts at $6000 for three developers and includes GNUPro Toolkit, Developer Support, and a commercial-use license for 100 copies of the Cygwin library. Contact info@cygnus.com for more information about this license. All other questions should be sent to the project mailing list cygwin@sourceware.cygnus.com.

  12. Sounds like FUD by Stephen · · Score: 2
    This sounds like a load of FUD to me. In fact the article just about admits as much. As it says at the end (and keeps emphasising in other words all the way through)
    "So, in theory, there may be a problem. In reality, nothing to get agitated about, at least not yet."
    So they know there isn't a problem, but they wanted to write a story with a new angle on the takeover anyway?
    --
    11.00100100001111110110101010001000100001011010001 1000010001101001100010011
    1. Re:Sounds like FUD by Chalst · · Score: 2

      I don't think this is fair. The fears are real, the article explores them, and with a reasonable caveat, puts them to rest. No FUD, no groundless Redhat bashing.

  13. Assigning copyright to the FSF by Carl · · Score: 2

    I found the following piece amusing:

    Any code that has at one time been protected by the GPL will still always be freely available, but new versions of that code could conceivably be released under different terms, even, potentially, as proprietary, closed-source software. The Free Software Foundation (FSF) is considered by most programmers to be highly unlikely to perpetrate any such license changes for the software to which it holds the copyright.

    It is simply impossible for the FSF to distribute proprietary code. If you have ever assigned any code to the FSF you would know that the assignment contract you sign obligates the FSF to always distribute the assigned code and any code based on your work as Free Software, although they might not distribute it under (a specific version of) the GPL.

  14. Re:Two Reasons It Won't Happen by the+eric+conspiracy · · Score: 2

    Red Hat won't be "forced" by shareholders to switch over to developing proprietary variants of Linux, GNU, etc. for two reasons I can think of:

    A third reason is that Redhat has only sold about 10% of the company stock on the open market. The same people who founded RedHat still own the vast majority of RedHat stock.

  15. Re:Precompiled headers and -frepo by Per+Abrahamsen · · Score: 2

    -frepo works fine for me on Solaris, but not on any other platforms where I have tried it (aix, hp/ux and cygwin). The official policy of the gcc maintainers is that -frepo is depreciated, and linker smartness is the way to go.

    Precompiled were implemented by Michael Thiemann at Cygnus for Corel, but apparently the gcc maintainers doesn't like the implementation, so it may never reach the public distribution.