OpenBSD Journal

SFLC Completes Review of Linux Wireless Code

Contributed by merdely on from the upon-further-review dept.

The Software Freedom Law Center announced that they have completed a review of Linux's Atheros wireless driver and its licensing issues and arrived at the following conclusion:

All the copyright holders of the Linux ath5k-driver code, derived from ar5k, have been contacted and have agreed to license their changes under the ISC license, thus allowing improvements to be re-incorporated into OpenBSD.

The full text of SFLC's announcement follows.

Note that the issue of authorship has been conveniently glossed over.

The Software Freedom Law Center (SFLC), provider of pro-bono legal services to protect and advance Free and Open Source Software (FOSS), today announced that it has carefully reviewed the lineage of the open source Atheros wireless driver for Linux and determined which portions can be distributed under the ISC license (also known as the 2-clause BSD license).

The licensing situation for the Atheros driver is complex because much of it was originally derived from an OpenBSD project called ar5k. This original code is licensed under the ISC license, but Linux code is typically licensed under the GNU General Public License (GPL). The GPL places specific additional requirements on distributors of software to ensure that its users are able to obtain the software's source code, and freely to copy, modify, and redistribute all subsequent modified versions.

Ultimately, all the copyright holders of the Linux ath5k-driver code, derived from ar5k, have been contacted and have agreed to license their changes under the ISC license, thus allowing improvements to be re-incorporated into OpenBSD. One of the three historical branches of the code reviewed by SFLC, however, included portions that are only licensed under the GPL, and SFLC has determined that it would be very difficult to re-incorporate that code into OpenBSD.

To share its knowledge with the FOSS and legal communities and to share background regarding its analysis, SFLC today has also released two documents of general interest. One document is a set of guidelines for developers who wish to incorporate code with a permissive license, such as ISC, into a GPL-licensed project. The other paper discusses the legal standards of originality with regard to computer programs under U.S. and international copyright law.

The two general papers, as well as a detailed document explaining SFLC's review of the Linux Wireless team's ath5k driver, are available at http://www.softwarefreedom.org/resources/

"We're pleased to help bring clarity to the Linux Wireless Developers as they work towards inclusion of their code in the Linux kernel," said Karen Sandler, SFLC Counsel.

This is not the first time that SFLC has worked with the Linux Wireless developers. In July, SFLC announced that it had performed a confidential audit of the open source Atheros driver and determined that no portion of it was illegally copied from Atheros' proprietary code.

(Comments are closed)


Comments
  1. By Anonymous Coward (24.89.228.211) on

    It sounds to me like everything has been resolved in an amicable fashion after all -- which probably means I've missed a key point ;)

  2. By Marc Balmer (213.189.152.34) on

    It sucks that lawyers need be involved in free software development.

    Comments
    1. By Pizza is your friend (68.125.31.8) on

      > It sucks that lawyers need be involved in free software development.

      At least their service is "pro-bono" instead of the usual requirement to feed the parasites.

      Comments
      1. By Anonymous Coward (58.168.49.65) on

        > At least their service is "pro-bono" instead of the usual requirement to feed the parasites.

        Many business models are built in giving away services for free initially.
        Drug dealers spring to mind.

        Comments
        1. By Anonymous Coward (165.228.157.146) on

          > > At least their service is "pro-bono" instead of the usual requirement to feed the parasites.
          >
          > Many business models are built in giving away services for free initially.
          > Drug dealers spring to mind.
          >

          BSD licensed software is another.

          Comments
          1. By Anonymous Coward (67.53.116.122) on

            > > > At least their service is "pro-bono" instead of the usual requirement to feed the parasites.
            > >
            > > Many business models are built in giving away services for free initially.
            > > Drug dealers spring to mind.
            > >
            >
            > BSD licensed software is another.

            If someone is making a profit by writing BSD-licensed software, I would like to know who it is and why people are paying for it.

            Comments
            1. By sqrt (84.166.73.127) on

              > If someone is making a profit by writing BSD-licensed software, I would like to know who it is
              > and why people are paying for it.

              I've written some (very special) software and some tools for customers paying me for this. And yes... BSD-licensed... why not?

          2. By Anonymous Coward (128.171.90.200) on

            >> Drug dealers spring to mind.
            > BSD licensed software is another.

            BSD is a drug ?

            I don't know what to say but ... thanks :)

            Comments
            1. By Anonymous Coward (170.22.76.10) goodb0fh@gmail.com on

              > >> Drug dealers spring to mind.
              > > BSD licensed software is another.
              >
              > BSD is a drug ?
              >
              > I don't know what to say but ... thanks :)

              Well, remember, the only two things to come out of Berkeley are LSD and BSD (and call their users, users).

    2. By Anonymous Coward (216.68.198.57) on

      "> It sucks that lawyers need be involved in free software development."

      Lawyers ~regulate society and development...anything of value, use, or whatever, is fought over. Strong community is a partial solution. Sucks, especially when lawyers start to infiltrate OSS, as a way to fight technology with technology. They get to point lots of business and risk where they want. Grr, I hope OpenBSD and etc communities stay strong.

      Software and IT skills with good practices is worth major dollars, and influence. Expect law firms to stake out territory and deals in the future. EDD, electronic data discovery, is one "tool." Life, lawyers and the "system," can't beat em, you ~have to "join em," hopefully you get your pick of which to join and how you help them. Hopefully a strong OpenBSD community can keep things in check.

      Comments
      1. By Anonymous Coward (85.178.54.162) on

        > "> It sucks that lawyers need be involved in free software development."
        >
        > Lawyers ~regulate society and development...anything of value, use, or whatever, is fought over. Strong community is a partial solution. Sucks, especially when lawyers start to infiltrate OSS, as a way to fight technology with technology. They get to point lots of business and risk where they want. Grr, I hope OpenBSD and etc communities stay strong.
        >
        > Software and IT skills with good practices is worth major dollars, and influence. Expect law firms to stake out territory and deals in the future. EDD, electronic data discovery, is one "tool." Life, lawyers and the "system," can't beat em, you ~have to "join em," hopefully you get your pick of which to join and how you help them. Hopefully a strong OpenBSD community can keep things in check.

        Sorry, but 'life' belongs NOT in the same sentence as 'system' and 'lawyers'; the latter are products of a civilization in which a minority has a god called capitalism and doesn't care about 100,000 deaths because of hunger and war EACH DAY.

        Life is different. It was on this planet for billions of years, and it will be here much longer than 'mankind'.

        (Sorry, but this is really ridiculous; every day in my life I see more and more that John Zerzan is perfectly right... :)

  3. By Anonymous Coward (70.173.172.228) on

    so in summary:
    Theo was right and got what he wanted?

    Comments
    1. By Bastiaan Jacques (86.83.136.97) on

      > so in summary:
      > Theo was right

      Theo made a lot of statements about this and many of them were speculation about advice given by the SFLC to their clients (in this case, Linux developers). If the advice given by SFLC was anything like the documents posted today, then no, Theo probably was not right. However, since this concerns a private communication between two parties and neither of those has shown what exactly was communicated, we'll probably never know.

      However, there were statements that were clearly false, for instance:

      Those files are still invalidly being distributed -- Nick and Jiri did not proveably do enough original work to earn copyright on a derivative work, since their work is just an adaptation.

      Which is in contradiction to the "Originality Requirements under U.S. and E.U. Copyright Law" document posted by SFLC.

      Theo also said: a dual licensed file always remains dual licensed, every time it is distributed. However, the plain language of the dual license in question contradicts this statement:

      Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: [list of conditions] Alternatively, this software may be distributed under the terms of the GNU General Public License ("GPL") version 2 as published by the Free Software Foundation.

      Given that one chooses the latter, then one would not be bound by the license requirements of the former, i.e., to preserve the dual license header.

      That said, the SFLC recommends that Permissive-licensed code authors do not need to dual-license their code, because permissively licensed code can be included in a GPL project as is. SFLC also recommends that if GPL-only changes are applied to a Permissively licensed file, then the original copyright notice should be preserved using indentation when the GPL is added.

      > and got what he wanted?

      That, I think he did, although it probably took a lot longer than he was willing to wait.

      (The usual "I am not a lawyer" disclaimer applies.

      Comments
      1. By Anonymous Coward (70.173.172.228) on

        >
        >> so in summary:
        >> Theo was right
        >
        >
        > However, there were statements that were clearly false, for instance:
        >
        > Those files are still invalidly being distributed -- Nick and Jiri did
        > not proveably do enough original work to earn copyright on a
        > derivative work, since their work is just an adaptation.
        >
        > Which is in contradiction to the "Originality Requirements under U.S. and E.U. Copyright Law" document posted by SFLC.
        >

        Only if it has sufficient non-trivial, original work in it.

        >
        > Theo also said: a dual licensed file always remains dual
        > licensed, every time it is distributed. However, the plain language of the dual license in question contradicts this statement:
        >
        > Given that one chooses the latter, then one would not be bound by the license requirements of the former, i.e., to preserve the dual license header.
        >

        The license talks about distribution, not relicensing. Removing terms of the dual license is relicensing. By allowing distribution under the terms of the GPL or a modified BSD license, the license does not grant the right to relicense the code. The terms of the license are not what bind you to preserve the license header, its the fact that to do so would be relicensing it.

        (At this point you will want to paste the comments from the author, please don't. The fact that he has to be explicit about it does mean that his license was not sufficiently clear about his intentions.)

        >
        > That said, the SFLC recommends that Permissive-licensed code authors do not need to dual-license their code, because permissively licensed code can be included in a GPL project as is. SFLC also recommends that if GPL-only changes are applied to a Permissively licensed file, then the original copyright notice should be preserved using indentation when the GPL is added.

        Actually its not that code authors do not /need/ to dual-license their code, the SFLC specifically recommends that developers NOT dual-license their works that will be incorporated into GPLed projects.

        The dual licensed code that was in dispute was not actually GPL compatible, so that advice would not have been useful.

        >
        > (The usual "I am not a lawyer" disclaimer applies.

        Comments
        1. By Anonymous Coward (86.83.136.97) on

          > The license talks about distribution, not relicensing. Removing terms
          > of the dual license is relicensing. By allowing distribution under
          > the terms of the GPL or a modified BSD license, the license does not
          > grant the right to relicense the code. The terms of the license are
          > not what bind you to preserve the license header, its the fact that
          > to do so would be relicensing it.

          In fact, I would say that relicensing of a source file under different terms is the same as distributing that file under different terms.

          Imagine for the sake of this discussion that you wanted to distribute one of the dual-licensed files. Say, you choose to distribute it under the terms of the GPL (which the license permits you to do). Instead of removing the license, you add a note on the top that says: "I, Jane Doe, am distributing this source file under the terms of the GPL, as described in the dual-license header which follows."

          Now, you have left the dual license intact, but since you've chosen the GPL as the license under which the work has been distributed, the BSD-part of the license is no longer in effect <em>as you distribute it</em>. This would have the exact same effect as removing the non-GPL part of the license header.

          > The dual licensed code that was in dispute was not actually GPL
          > compatible, so that advice would not have been useful.

          I'm afraid you are mistaken. The non-GPL part of the license is the modified BSD licenses, which the FSF contends is compatible with the GPL:

          "This is the original BSD license, modified by removal of the advertising clause. It is a simple, permissive non-copyleft free software license, compatible with the GNU GPL."

          Comments
          1. By sthen (85.158.44.149) on

            > I'm afraid you are mistaken. The non-GPL part of the license is the modified BSD licenses

            "a modified BSD license", not "the modified BSD license". Sam Leffler's license, unusually, does not require binary distributions to include a copyright notice, but it does have an additional disclaimer requirement on further redistribution.

        2. By Anonymous Coward (213.47.101.10) on

          > >
          > > Theo also said: a dual licensed file always remains dual
          > > licensed, every time it is distributed. However, the plain language of the dual license in question contradicts this statement:

          > The license talks about distribution, not relicensing. Removing terms of the dual license is relicensing. By allowing distribution under the terms of the GPL or a modified BSD license, the license does not grant the right to relicense the code. The terms of the license are not what bind you to preserve the license header, its the fact that to do so would be relicensing it.
          >


          not to derail, but isn't this exactly what damien@ did here:
          http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211.c#rev1.21

          Comments
          1. By Anonymous Coward (84.24.146.79) on

            > > >
            > > > Theo also said: a dual licensed file always remains dual
            > > > licensed, every time it is distributed. However, the plain language of the dual license in question contradicts this statement:
            >
            > > The license talks about distribution, not relicensing. Removing terms of the dual license is relicensing. By allowing distribution under the terms of the GPL or a modified BSD license, the license does not grant the right to relicense the code. The terms of the license are not what bind you to preserve the license header, its the fact that to do so would be relicensing it.
            > >
            >
            >
            > not to derail, but isn't this exactly what damien@ did here:
            > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211.c#rev1.21
            >

            No, he didn't. It's being distributed under a BSD license, which is allowed. He's not removing the license, which is not allowed. Future changes can be distributed under a BSD license, NOT the original work.

            Comments
            1. By Anonymous Coward (84.24.146.79) on

              > No, he didn't. It's being distributed under a BSD license, which is allowed. He's not removing the license, which is not allowed. Future changes can be distributed under a BSD license, NOT the original work.

              That should read "Future changes can be released under a BSD license, NOT the original work."

      2. By sthen (85.158.44.149) on

        > permissively licensed code can be included in a GPL project as is.

        yeah, but then they get those ugly "tainted module" warnings because it doesn't contain the string GPL.

  4. By Anonymous Coward (150.101.113.50) on

    For example, ar5k uses macros to build various tables:
    #define AR5K_AR5212_RATE_DUR_0 0x8700  
    #define AR5K_AR5212_RATE_DUR(_n) (AR5K_AR5212_RATE_DUR_0 + ((_n) << 2))
    
    I see no table here, I see a macro which calculates constant values which could be used in a table or inline.
    while ath5k-driver does the following:
    { AR5K_RATE_DUR(0),0x00000000 },  
    { AR5K_RATE_DUR(1),0x0000008c },  
    { AR5K_RATE_DUR(2),0x000000e4 },
    
    Now that looks like a table.

    Their reasoning is ok, but their wording could be better.

    A lawyer giving an opinion in such a issue should be more careful.

  5. By Anonymous Coward (67.53.116.122) on

    Maybe I am not following the story closely enough lately, but this statement from the SFLC has me confused. As I understand things:

    Someone takes BSD-licensed code and makes a trivial adaptation of it and then makes up a new kind of license called "Dual BSD/GPL" and replaces the original BSD license with this new license. The original authors object. SFLC weighs in and essentially says "It is quite legal for the adapting party to do this."

    Now the SFLC is saying that they are kind enough to make the dual-licensed source code BSD-licensed? Wasn't it BSD licensed in the first place?

    My second question is regarding the seeming illogicality of appending a GPL license to code that is already BSD licensed.

    The BSD license grants you redistribution rights, requiring only that you abide by the conditions of the BSD license. One of these conditions is that the BSD license must remain intact.

    The BSD license does not restrict you from appending additional things to the file. You can append additional license restrictions if you want, but wouldn't these restrictions be meaningless? The BSD license, which must remain intact, already grants redistribution rights in ALL cases as long as you abide by the BSD license. So a GPL license after the BSD license is just extra verbiage which cannot really take away anything that the BSD has granted.

    Is there a lawyer who can answer that? Not really interested in the "IANAL but..." responses.

    Comments
    1. By Anonymous Coward (128.171.90.200) on

      > Is there a lawyer who can answer that? Not really interested in the "IANAL but..." responses.

      Probably not round here, but that is beside the point in some respects, if you hire a lawyer, they are there to argue the toss on the wording of the law. Lawyers tend to reference previous rulings in their arguments, I cannot think of a single dual-license or GPL case that could be quoted.

  6. By Karl Sjödahl (Dunceor) dunceor@gmail.com on

    There are a few comments that don't get you a good view of these 'laywers'.

    ''The file ath5k.h seems to be derived from ar5k’s ar5xxx.h and perhaps a few other header files.''

    Perhaps?

    ''The Linux Wireless Team, along with some Madwifi developers, have indicated a desire to collaborate with the OpenBSD team working on ar5k.''

    Eh....

  7. By Anonymous Coward (62.1.120.69) on

    Its obvious that the linux developers were wrong.

    How about leaving intact the initial source code under the ISC and making a patch file for the code distributed under GPL, is that acceptable?

    Comments
    1. By Anonymous Coward (194.45.26.221) on

      > Its obvious that the linux developers were wrong.

      It's obvious that you didn't read the article and the stuff that is linked in there correctly.

    2. By Anonymous Coward (81.129.109.142) on

      > Its obvious that the linux developers were wrong.

      What do you think people outside the OpenBSD community are going to remember? That the Linux developers were wrong or that Theo completely lost it, showed all the restraint of a hyperactive child and made stupid legal threats?

      If you think it's the former and that it will speed OpenBSD adoption, then my reply is "Ho, ho, ho".

      I hope that the OpenBSD devs don't make another mistake like the BCM driver affair in future, because now that Theo's pissed everyone off it's unlikely to be treated with any sympathy no matter how insulting he is about it.

      Comments
      1. By Karl Sjödahl (Dunceor) on

        > > Its obvious that the linux developers were wrong.
        >
        > What do you think people outside the OpenBSD community are going to remember? That the Linux developers were wrong or that Theo completely lost it, showed all the restraint of a hyperactive child and made stupid legal threats?
        >
        > If you think it's the former and that it will speed OpenBSD adoption, then my reply is "Ho, ho, ho".
        >
        > I hope that the OpenBSD devs don't make another mistake like the BCM driver affair in future, because now that Theo's pissed everyone off it's unlikely to be treated with any sympathy no matter how insulting he is about it.

        The question is rather, would SFLC even have this press release if it wasn't for Theo sticking up for Free Software? It wasn't stupid legal threats, they were correct legal threats. The article above show that Theo was right and it how can it be 'stupid' then?

        And once again that all these trolls seems to forget, Theo is not out to make big companies adopt OpenBSD, Theo wants a project that develops free code for the developers.

      2. By Gilles Chehade (veins) gilles@openbsd.org on http://www.evilkittens.org/

        > > Its obvious that the linux developers were wrong.
        >
        > What do you think people outside the OpenBSD community are going to remember? That the Linux developers were wrong or that Theo completely lost it, showed all the restraint of a hyperactive child and made stupid legal threats?
        >

        Frankly, it does not really matter what people outside the OpenBSD community are going to remember as long as they also remember that it is not ok to replace a license or add yourself as a copyright holder. I think that most of the OpenBSD users did not chose that system because they were in love with Theo but because OpenBSD fits their needs.

        Now, tell me what the people inside the OpenBSD communinty are going to remember ?

        I will remember that my mailbox was *overflowed* by the same clueless comments repeated dozens of times, I will remember that a portion of the Linux community tried to hide the issue by attacking Theo instead of focusing on the real problem (Ooops you did it again ...), I will remember that sometimes it's better to work with a company that has ethics than with some people of the open source community, and I will remember that too many people from the Linux community are unable to read three lines of english, yet are able to expand on their (mis-)interpretation for pages and pages and pages ...

        Fortunately, I will also remember that most of these people are not representative of the Linux developers.


        > If you think it's the former and that it will speed OpenBSD adoption, then my reply is "Ho, ho, ho".
        >

        From above:

        "I think that most of the OpenBSD users did not chose that system because they were in love with Theo but because OpenBSD fits their needs."

        This is only my opinion, but as long as it fits my needs I don't really care about the speed of adoption. I can't speak for other developers, but I haven't heard about any plan for world domination.


        > I hope that the OpenBSD devs don't make another mistake like the BCM driver affair in future, because now that Theo's pissed everyone off it's unlikely to be treated with any sympathy no matter how insulting he is about it.

        Please. read the thread ...
        You are just showing that you are among the people who fail to read past the first lines but feel the need to comment anyway.

        I am too lazy to go look it up for you, but Theo started his first or second mail with something like "yes, it is wrong and we will fix it". There has been no arguing to determine if it was ok or not, there's been arguing that this could have been handled in private and that it was not nice to go public over a mistake.

        Gilles

  8. By daan (217.19.26.102) on

    HMMM this verdict is not on the headlines on herneltrap.org why not ?:P

    When this conflics was on they put it on the headlines and comments say'd theo was talking BS, i want to see there comments now :)

    Comments
    1. By Anonymous Coward (70.153.211.253) on

      "HMMM this verdict is not on the headlines on herneltrap.org why not ?:P  When this conflics was on they put it on the headlines and comments say'd theo was talking BS, i want to see there comments now :)"

      The SFLC decision is referenced in this KernelTrap story.

      Comments
      1. By Anonymous Coward (217.19.26.102) on

        > "HMMM this verdict is not on the headlines on herneltrap.org why not ?:P When this conflics was on they put it on the headlines and comments say'd theo was talking BS, i want to see there comments now :)"
        >
        > The SFLC decision is referenced in this KernelTrap story.

        well thats something then but not the story as is like on this site

        Comments
        1. By Anonymous Coward (70.153.211.253) on

          > well thats something then but not the story as is like on this site

          Agreed, undeadly and kerneltrap are two different websites. Your point?

          Comments
          1. By Anonymous Coward (217.19.26.102) on

            > > well thats something then but not the story as is like on this site
            >
            > Agreed, undeadly and kerneltrap are two different websites. Your point?
            >

            try this: why does kerneltrap put the driver to discussion on headlines and not the outcome on it's headlines

            if you going to tell the story than the whole story not parts of it.

    2. By Anonymous Coward (208.152.231.254) on

      > HMMM this verdict is not on the headlines on herneltrap.org why not ?:P
      >
      > When this conflics was on they put it on the headlines and comments say'd theo was talking BS, i want to see there comments now :)

      Well, it got posted, actually. See other comment.

      Theo was talking BS about a number of things, one of which was the Linux development community's attitude towards this issue and the good faith (or Theo's assertion the lack there-of) of the SFLC. And that's not counting the exaggerations.

      Here are the facts:

      1. The Linux developers can use BSD licensed code and license their modified versions under the GPL.
      2. The Linux development community, in an entirely unnecessary act of good will, are going to use the ISC license for this driver so the BSD community can benefit from it.
      3. The SFLC has spent a lot of time behind the scenes making this possible.
      4. Theo's comments suggesting otherwise were completely unfair and uncalled for.

      The depressing aspect to all of this is that some in the BSD community may get the impression that the correct way to get what you want is to scream and cry like a child, insulting and lying about the motives of the people you want help from.

  9. By Bob Beck (129.128.11.43) beck@openbsd.org on


    Well, not quite. I think we need the original author (reyk) to speak
    up here. but there is still a major issue with this.


    Yes, the sflc has told the linux developers how to use ISC licensed code
    within the linux tree.

    They have even gone so far as to say that puttin a gpl on stuff that is shared with people like us with more permissive licenses is impolite, and
    that linux developers should consider keeping the code under an ISC license.

    This is all good, assuming that the files in question all had contributions made by others that were sufficiently original to warrant them claming copyright on them.

    However, this is the actual contention: if you look here:

    http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=blob;f=drivers/net/wireless/ath5k_hw.c;h=07ad1278b39037caf68825cabcf9469db059dfc8;hb=ffca09d95ccb02d716b41a3f6796d2c75b6ea882

    This shows the problem. Notice those names added to reyk's license. When I look at this file and compare it to the ar5k file, I see that the file
    has ben re-indented (basically run through linux indent) and had a few
    variable and stylistic changes made. There does not appear to be any
    significant contribution made here. And that's really the point. Now,
    reyk should be speaking up on this subject, as he's the author, but what you are really looking at here is the same thing as if, for example,
    you took a copy of "harry potter", changed the typeface and fonts,
    then changed the spellings in it from english to american, and then
    attempted to add your name on it with J.K. rowling's as an author. The point is it isn't a derivative work. The contention here is what amount of change constitutes original work that is copyrightable.

    While yes, the license issue is for the moment, corrected, the issue
    of significant contribution and authorship is not. Would you like it if someone took code you wrote, ran it through indent, added a comment or two and changed some variable names, and then listed themselves as the author same as you?




    Comments
    1. By Bob Beck (129.128.11.43) beck@openbsd.org on


      > While yes, the license issue is for the moment, corrected, the issue
      > of significant contribution and authorship is not. Would you like it if someone took code you wrote, ran it through indent, added a comment or two and changed some variable names, and then listed themselves as the author same as you?

      And I suppose the other question is, Will this go into the Linux kernel
      when the authorship is under question?



      Comments
      1. By Anonymous Coward (85.178.71.99) on

        >
        > > While yes, the license issue is for the moment, corrected, the issue
        > > of significant contribution and authorship is not. Would you like it if someone took code you wrote, ran it through indent, added a comment or two and changed some variable names, and then listed themselves as the author same as you?
        >
        > And I suppose the other question is, Will this go into the Linux kernel
        > when the authorship is under question?

        We should STFU and just sue them if it happens...

        And sorry for this "cross post" but because I see "some" developer here: Any chance for a OpenSSh Update for "older" OpenBSD Versions (like 4.1 or 4.0.... ;-/ )

        Comments
        1. By Anonymous Coward (74.13.40.224) on

          Re: OpenSSH

          Sometimes it happens, but usually only when it matters. But not really when it's neither a security fix nor a reliability fix.

        2. By sthen (85.158.44.148) on

          > Any chance for a OpenSSh Update for "older" OpenBSD Versions (like 4.1 or 4.0.... ;-/ )

          Did you see something in the new OpenSSH that you particularly need right now? It's there in the -current snapshots. If you're used to the quality of development code from other projects you might be pleasantly surprised...

          If not, it's not a long wait for 4.2; there are plenty of improvements all over the OS.

          Comments
          1. By Anonymous Coward (85.178.71.99) on

            > > Any chance for a OpenSSh Update for "older" OpenBSD Versions (like 4.1 or 4.0.... ;-/ )
            >
            > Did you see something in the new OpenSSH that you particularly need right now? It's there in the -current snapshots. If you're used to the quality of development code from other projects you might be pleasantly surprised...
            >
            > If not, it's not a long wait for 4.2; there are plenty of improvements all over the OS.

            It's not about the "I wanna upgrade to 4.2".
            F.e. the speed improvements or the new HMAC would be pretty cool to have on OpenBSD 4.0 and 4.1.

            Also the OpenSSL Patches to fix some "issues" (there 2! one is listed at plus.html) would be nice....

            I#m sorry and it's no begging but I would like to see that "old" OpenBSD Systems (3.9-4.1) get up2date before they get droped (end of life).
            And if the new OpenBSD 4.2 gets released the Fixes/patches or the OpenSSH update wont get into the CVS trtee for the old mashines.

            Comments
            1. By sthen (85.158.44.149) on

              > It's not about the "I wanna upgrade to 4.2".
              > F.e. the speed improvements or the new HMAC would be pretty cool to have on OpenBSD 4.0 and 4.1.

              > I#m sorry and it's no begging but I would like to see that "old" OpenBSD Systems (3.9-4.1) get up2date before they get droped (end of life).

              The networking speed improvements would be cool to have too. And the better pkg_add. And isakmpd interoperability fixes for PKI. To name but a few. Not going to happen... Serious problems get fixed for past releases, but if you want the shiny new stuff without waiting for another release, -current is where it's at.

              Comments
              1. By Brad (2001:4830:122b:4:216:6fff:fe3e:6327) brad at comstyle dot com on

                > > It's not about the "I wanna upgrade to 4.2".
                > > F.e. the speed improvements or the new HMAC would be pretty cool to have on OpenBSD 4.0 and 4.1.
                >
                > > I#m sorry and it's no begging but I would like to see that "old" OpenBSD Systems (3.9-4.1) get up2date before they get droped (end of life).
                >
                > The networking speed improvements would be cool to have too. And the better pkg_add. And isakmpd interoperability fixes for PKI. To name but a few. Not going to happen... Serious problems get fixed for past releases, but if you want the shiny new stuff without waiting for another release, -current is where it's at.

                Stuart,

                Instead of being a smartass you could read the -stable web page.

                Comments
                1. By sthen (85.158.44.149) on

                  > > > It's not about the "I wanna upgrade to 4.2".
                  > > > F.e. the speed improvements or the new HMAC would be pretty cool to have on OpenBSD 4.0 and 4.1.
                  > >
                  > > > I#m sorry and it's no begging but I would like to see that "old" OpenBSD Systems (3.9-4.1) get up2date before they get droped (end of life).
                  > >
                  > > The networking speed improvements would be cool to have too. And the better pkg_add. And isakmpd interoperability fixes for PKI. To name but a few. Not going to happen... Serious problems get fixed for past releases, but if you want the shiny new stuff without waiting for another release, -current is where it's at.
                  >
                  > Stuart,
                  >
                  > Instead of being a smartass you could read the -stable web page.

                  ok, I hadn't read it for a while and had forgotten the bit about OpenSSH.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]