Forgot your password?
typodupeerror
Linux Software

Usenix President - Linux Needs Better Paper Trail 166

Posted by simoniker
from the follow-the-shredded-lawsuits dept.
Anonymous Coward writes "Usenix Association president Marshall Kirk McKusick is a veteran of BSD's intellectual property scuffle with AT&T in the 1990s, and he's got some thoughts and advice for the keepers of the Linux kernel going forward, commenting: 'There isn't a well-documented ownership trail with Linux. So, they have opened themselves up to a swamp of 'he said-she said' about where code came from'."
This discussion has been archived. No new comments can be posted.

Usenix President - Linux Needs Better Paper Trail

Comments Filter:
  • Dating back to when linux (the kernel) didn't even have a version number, code was always attributed to where it came from. I'm sure everyone is familiar with at least the changelog [kernel.org] and its attributions. And of course actual comments with names and email addresses are all over the sourcecode itself.

    Now, Mr. McKusick might have a partial point. Its entirely possible that some gremlin over at Caldera took a bunch of SCO's 'Intelectual' Property and threw it into the main kernel under the GPL. In which case once the lines of code are actually identified, I suspect we will know who contributed them in under 20 minutes (10 minutes of which will be the article sitting on /. in The Mysterious Future!) In the unlikely event of SCO ever saying which lines are thiers, we may end up with the interesting situation where a Caldera/SCO employee put them there - and get to slap SCO for abusing the legal system.

    In any event, I'd be willing to put money on Linux's source code source documentation beating SCO's out any day of the week.
    • by Anonymous Coward
      Ehh. Linux /always/ had a version number. Since day one, with v0.01, back in 1991.
    • You know, I suspect they've already discovered copied code...by a Caldera employee. Possibly even with written permission on file.

      But the point of their lawsuit is to prove that at least some of the code in Linux came from SCO's IP through IBM. They're damned sure not to point out any pasting they did. It would point to an apparent flaw in their logic.

      (And whether that flaw is really a flaw, and not a dynamic company changing its policies, is a subject for another debate. But I won't represent them.)
    • by imp (7585) on Monday May 24, 2004 @02:54PM (#9240225) Homepage
      The changelog is insufficient documentation. It contains vague attributions that something changed somewhere in the code. It isn't specific as to what lines of code changed. Later, when you go back and try to find where a set of lines came from, a changelog doesn't help much.

      With a source code control system, you know that so and so added on such and such a date. You can then go to that person and ask them where they got it from if there's ever any question.

      In the BSD world (I do a lot with FreeBSD), this has come in very handy when code disputes come up. Being able to talk to the actual people that inserted the code into FreeBSD has helped to clear up what otherwise might have been viewed as something improper.

      I've tried to do similar things with versions of linux in the past, only to discover that I could, at best, find what version they came into the tree at, and who collected the patch and sent it to Linus. I wasn't able to track it further without searching public mailing lists for the information (with mixed results).

      while you might believe that it will take 20 minutes to identify the code in question, my guess is that's overly optimistic, unless the code in question was contributed since bk. It usually takes me at least 5 minutes to find out where code comes from in FreeBSD when there's a question, and cvs annotate makes the process *MUCH* faster.

      I'm not sure I'd disagree with your comments about SCO being able to come up with where the code came from relative to Linux.
      • We all know Linux hasn't been in any sort of a version control system since version 2.2 after which the issues started alledgedly creeping up.
      • by hughk (248126) on Monday May 24, 2004 @03:26PM (#9240510) Journal
        In theory, you need a CVS diff list at least. However, unless the commit comments are linked to a meaningful entry somewhere that shows where a change come from, you will have problems. It doesn't matter whether you use CVS or BK, you still need underlying mechanisms. One issue with Linux, is that it has a lot more contributors than *BSD, which tends to make things more complicated.

        In the commercial world, you have change numbers which link to a documentation trail which shows who implemented something and why and who approved it. Linus is trying at least to improve the code provenance by looking at a certification chain between the patch generator, the maintainer and eventually Linus as release manager. Unfortunately, it still looks like a hunt through LKML for the documentation as you suggest.

        • by imp (7585) on Monday May 24, 2004 @08:03PM (#9243087) Homepage

          In theory, you need a CVS diff list at least. However, unless the commit comments are linked to a meaningful entry somewhere that shows where a change come from, you will have problems. It doesn't matter whether you use CVS or BK, you still need underlying mechanisms. One issue with Linux, is that it has a lot more contributors than *BSD, which tends to make things more complicated.

          cvs annotate is an excellent first start to see where code came into the tree. Other tools allow one to see where the code really came from in the face of formatting changes and the like.

          Like I've said in prior posts, having this information is invaluable. It also allows one to more easily back out changes that might be tainted, reguardless of where they come from, since you know all the parts to that change, which is impossible with the changelog data. In this respect, bk is better than cvs since bk's change mechanism links multiple files that have changed, while CVS does not.

          In the commercial world, you have change numbers which link to a documentation trail which shows who implemented something and why and who approved it. Linus is trying at least to improve the code provenance by looking at a certification chain between the patch generator, the maintainer and eventually Linus as release manager. Unfortunately, it still looks like a hunt through LKML for the documentation as you suggest.

          You *MAY* have this, or you may not. There are many shops that don't have this level of beaurocracy. However, I've never worked for any place that has had this independent of an underlying source code control system (and many places that didn't have source code control systems, let alone change numbers).


          The issue can be further complicated if there's been a cross fertilization between projects for things like device drivers. Project A figures out how to do feature Z and project B integrates it. B then figures out Y and project A integrates that. Project C takes code from a data sheet and includes that under license X and Project A then takes it and incldues it under license Y and then Project B wants to bring it it, but is unsure if they can because they see substantially similar code under both X and Y licenses, not being aware of the common datasheet code example being present and gets confused. In situations like this, a clear SCM trail can help sort out who to talk to and how to resolve what might appear to be something bad.


          I've seen many organic patches/drivers grow up over the years in linux that are litterally impossible to track down who wrote what originally. Some have email addresses, some do not, some have had them removed, some email addresses are stale, etc. In such a chaotic enviornment, it can be difficult to know where code came from. There are many strengths to this model, but code history isn't one of them.

          Warner

          • I would agree with you but luckily most places I ahve worked have attempted some form of central change control tracking bureaucracy. It may have CVS underneath, it may have something totally different.

            Yes, I'm aware of the problem of 'organic code', something that was based on something from another OS that was cribbed out of a databook. However, when a change is moved from one project to another, you can still trace back by cross referencing the change that you based it on and only importing it if you k

      • >With a source code control system, you know that so and so added on
        >such and such a date. You can then go to that person and ask them where
        >they got it from if there's ever any question.
        While ofcourse a source control system will help alot, it won't always reveal the whole truth about
        where the code comes from. For the 2.6 kernel you can view the changes here [bkbits.com].
        On thing you might notice is alot of changes from e.g. akpm(Andrew Morton). But he didn't write that all code.
        Alot of the changes commited by
      • There is also lkml and that pretty much existed from day one. What Linus was complaining about is that searching and correlating lkml, the changelogs, and the comments is tedious. Everything can be accounted for, it's just hard. What Linus whats now is to have machine readable assertions of who contributed what and the rights they had to do it.
    • by Anonymous Coward
      The paper-trails of Linux are far better than most corporations.

      Just because a corporation has a SourceSafe system doesn't mean people actually enter into the comments when they steal GPL'd code.

  • by Anonymous Coward
    http://news.com.com/Linux+contributors+face+new+ru les/2100-7344_3-5218724.html?tag=nefd.top
  • Source (Score:5, Funny)

    by funkdid (780888) on Monday May 24, 2004 @02:33PM (#9240016)
    I wrote it, the whole thing. Linus was my roomate at the time, he took credit for all of it. I was the one that worked with Santa Claus and the tooth fairy to develop it, not Linus! Problem solved.
  • by deft (253558) on Monday May 24, 2004 @02:35PM (#9240031) Homepage
    About a thousand geeks just simutaneously
    wondered what the hell paper is.

    Oddly enough, all of those thousand geeks could tell you what a scroll is.
    • by happyfrogcow (708359) on Monday May 24, 2004 @02:42PM (#9240092)
      paper trail? it's the stuff stuck to your shoe when you leave the restroom.

      how this applies to Linux, I have no idea. no need for the core dump jokes... we've seen em all.

    • "Oddly enough, all of those thousand geeks could tell you what a scroll is."

      Well, of course. Your mage writes spells onto scrolls, or finds them. I mean, what else would a scroll be?

      BTW, What the hell is paper anyways? Is it anything like papyrus?
      • BTW, What the hell is paper anyways? Is it anything like papyrus?

        Sort of. They're both made of wood.

        Unfortunately, while you can make papyrus with a good hand planar, it takes a dickens of a time to chew wood shavings into something that when dried makes good paper.

        Not worth the trouble, IMO.
        • Re:paper trail? (Score:2, Interesting)

          by ichimunki (194887)
          Papyrus is not made of wood. It is made of reeds. Neither is a lot of your better paper made of wood. The better stuff is pure hemp or cotton in the West and bast (mulberry) in the East. In fact, even your basic wood pulp papers these days have so many clays and polymers (sizing and bindings which make it possible to even run paper through something like an ink-jet printer without it falling apart) in them that saying they are made from wood pulp is almost misleading.

          If Linux is going to need a paper tra
          • Papyrus is not made of wood. It is made of reeds. Neither is a lot of your better paper made of wood. The better stuff is pure hemp or cotton in the West and bast (mulberry) in the East. In fact, even your basic wood pulp papers these days have so many clays and polymers (sizing and bindings which make it possible to even run paper through something like an ink-jet printer without it falling apart) in them that saying they are made from wood pulp is almost misleading.

            Huh. I don't doubt you, it's just tha


    • Oddly enough, all of those thousand geeks could tell you what a scroll is.


      Sure. That's an object you can collect in your favorite online game and sell on eBay. It's really a collection of bits - virtual property. What this has to do with paper, I have no idea. :)
    • Re:paper trail? (Score:3, Insightful)

      by irokitt (663593)
      pencil and paper: n.

      An archaic information storage and transmission device that works by depositing smears of graphite on bleached wood pulp. More recent developments in paper-based technology include improved 'write-once' update devices which use tiny rolling heads similar to mouse balls to deposit colored pigment. All these devices require an operator skilled at so-called 'handwriting' technique. These technologies are ubiquitous outside hackerdom, but nearly forgotten inside it. Most hackers had terri
  • News at 11 (Score:3, Informative)

    by joib (70841) on Monday May 24, 2004 @02:35PM (#9240036)
    It's not like this is some surprising new insight, see another article posted today: here [slashdot.org].
  • by LouisvilleDebugger (414168) on Monday May 24, 2004 @02:36PM (#9240037) Journal
    Is intended to allow the developers of Linux, as well as the various UNI*es, to register and tell what they know of their own roles, as well as the development of each feature of each version of UNIX flavored operating system. Stay tuned to Groklaw for the official announcement...we're working on getting the site up within the next couple of days.
  • Site's a little slow (Score:2, Informative)

    by karmatic (776420)
    Site's a little slow already (darn subscribers), so here's a Mirror [tinyurl.com].

    Note: This doesn't mean I agree with this crap. As a coder, I can certainly understand their wanting to write code more than document everything. Really, shouldn't CVS logs be as much "proof" you wrote it as you need? It's far more work to try to fake writing it by changing other's code, than it is to just do the work itself.
    • One of the main points of the article is that the (earlier) Linux versions lack any kind of CVS logs. The situation has been remedied when Linus started using BitKeeper, but there are years of development that cannot be tracked using a single source revision control system. This makes things quite complicated as the developers must dig through mailing lists and other means of communication to find out who really wrote what. "[...] they will have to dig themselves out of the swamp [...]", as said by McKusick
    • Really, shouldn't CVS logs be as much "proof" you wrote it as you need?

      Not at all. Your CVS logs will show who committed the code, but not who wrote it. The commit also needs to attribute the author. Looking at logs for various projects, some do this, but many do not.

      Besides which, Linux isn't under CVS, it's under Bitkeeper. And the Bitkeeper repository is still pretty new.
      • Your CVS logs will show who committed the code, but not who wrote it.
        Uh... no system can possibly do that. Think about it for a moment. How, exactly, can any system just "magically know" whether or not the person who committed the code to a project was genuinely authored by the person who committed it?
        • Isn't that what I just said? CVS can't possibly know who authored the code.
          • My point was that *NO* system possibly can.

            Your implication was that CVS is somehow deficient because of this, which is what I was trying to adress, but I fail to see how that could be if no other system exists that can do any better.

  • by Anonymous Coward on Monday May 24, 2004 @02:39PM (#9240060)
    Uh, this must be a typo. Linux developers arguing over the source for changes would always be; "he said-he said - then they got into a hissy fit hair-pulling fight"

    Glad I could clear that up.
  • A new agreement (Score:5, Interesting)

    by ch-chuck (9622) on Monday May 24, 2004 @02:41PM (#9240082) Homepage
    I guess, in the spirit of the GNU GPL, they'll have to come up with something, call it the FDA - a "Full Disclosure Agreement" that you *must* sign before contributing code, stating that you WILL tell everybody about the project and publish your code contribution, sort of a bizarro-world NDA.

    • If that is going to be the standard, then Linux-ISVs better get cracking and provide a digital signature capability.

      Or is there one around already? The only reason I continue to maintain a Windows partition is because our time cards are electronic and our digital signature software is Windows-only.

      • Re:A new agreement (Score:4, Informative)

        by Anonymous Coward on Monday May 24, 2004 @03:11PM (#9240362)
        You are using digital signatures that aren't based on a standard, documented algorithm like SHA1? Better make sure your closed-source Windows implementation isn't snake oil... You should read what Schnierer has to say about unpublished proprietary encryption algorithms (for example in 'Applied Cryptography 2nd Ed'). FWIW, there are Linux implementations of just about every significant published digital signature standard.
      • Or is there one around already?

        GnuPG, as a standalone product and a sort of industry standard. OpenSSL, libmcrypt, and libmhash as libraries of algorithms and functions, the latter two also with PHP interfaces. And *many* more. :)

  • Uh. What's this crazytalk about ownership?

    Isn't the whole purpose of GPL that no-one can "own" any of the code?

    • Re:Ownership trail? (Score:2, Informative)

      by chromatic (9471)

      No. It's that no one can take away your right to fork the software, your right to use the software as you see fit, your right (or your proxy's right) to examine and change the software if you desire, and your right to redistribute the software, as long as you allow other people the same rights.

      • by Anonymous Coward
        It actually is inaccurate to call what the GPL grants you a "right." A right can only be granted to you by a sovern governmental entity, or God. The GPL only grants you permission to share code, modify, fork, etc... Now, that permission comes with the promise that they will never be modified. That, combined with the reality of the hodgepodge of copyright ownership all mixed into a program all work to make it near impossible to revoke that promise; but it is still, nonetheless, a promise.
        • > A right can only be granted to you by a sovern governmental entity, or God.

          Where do you think the government got the rights in the *FIRST* place?

          Let me ask you this, to help illustrate my point...

          Does government create people, or do people create the government?

          --
          So when 2 buildings in America blow up, that's called Terrorism.
          But when America genocides a nation, its your patriotic duty to kill others and Win the War.
    • Re:Ownership trail? (Score:3, Informative)

      by julesh (229690)
      No, the purpose of the GPL is to provide everyone with access to the code and allow them to use it in their own GPL programs.

      All contributors to Linux still own the sections that they contributed. Some projects are run differently, for instance the FSF owns the code to all of the official gnu projects, because they ask contributors to assign copyright to them.

      The ownership is important if you later want to change the license, for example by granting somebody permission to do something that isn't usually
    • IANAL, but as I understand it, even with the GPL, someone still owns the rights to the code. Typically this is the author. But the author may convey those rights to another entity - such as another user, a corporation, or the EFF.

      The GPL gives the users some rights - such as the ability to modify the code, and redistribute the code.

      Even after distributing code under the GPL, the author could decide to distribute it under a commercial license.
    • It been said before:
      The GPL is not about ownership, it is about distribution rights.

      The ownership remains with the Copyright holder. In the case of the GPL the Copyright holder allows for redistribution under the GPL.

      The owner could release the same code under a different license, whereas somebody who received the code under the GPL cannot.
    • His point is that you need to be able to document that no one else owned the code before it was merged into the kernel. If someone did own it, you need to document that they legally passed rights to the code to your project.

      What the GPL says is not pertinent to that issue. Put the SCO hysteria aside momentarily. This guy is speaking from his own experience in a very similar environment: When someone gets a lawyer and says they owned some of the code in your project, you'd better come up with documentati
  • by maximilln (654768) on Monday May 24, 2004 @02:43PM (#9240112) Homepage Journal
    From what I've seen ownership never becomes a problem until large amounts of money become involved or until one group attempts to sandbag another group based upon their ownership. Since this is the open source community, most commonly under the GPL license, there is no worry about this sandbagging unless someone attempts to take a fork and make it commercial.

    Is this where the need for a paper trail comes in? Suppose someone takes the kernel and starts their own independent development on it. Hypothetically, in five years, they could rewrite or replace over 50% of the kernel with their own code. From what I understand the GPL license requires that any code that it becomes part of must also be GPL. If the total code package is several million lines, however, who is going to pay to subpoena the source code for a commerical product to prove that it was indeed started from a GPL/open source project? Who will pay to have the code audited and what prevents a potentially unscrupulous commerical entity from playing mix and match with subroutines so carefully that the resulting audit would take more time to arrange properly that to actually audit the lines one by one?

    I suppose, in this case, the paper trail wouldn't make a darn bit of difference. The paper trail isn't going to make it any easier to subpoena source code from a commercial entity if they're stonewalling.

    Enter my tin-foil argument that Windows9x/2x is nothing more than badly mangled Linux and a customized window manager built with a crytpically designed compiler--but no one ever gets to see the source code so they'll never be able to prove it.
  • by Eberlin (570874) on Monday May 24, 2004 @02:43PM (#9240115) Homepage
    Ok, so if I hypothetically had this idea to include a few lines into the kernel...I managed to slip a couple of lines of code into a "thank you" postcard to Linus eons ago. After reading it, he thought it was utter rubbish and tossed it away.

    Actually, he was so pissed off about the whole stupidity that it motivated him to stay up an extra two hours hacking away. So technically, some of his code should be attributed to me, right?

    Much like how some of that code should be credited to Pizza Hut, Starbucks, and a few different candy bars. So where's the documentation on that?

    All the changelogs, the comments, and any other bits of documentation aren't enough. Where's the credit to the pizza delivery guy? He helped develop some of that code! Ingrates, I tell ya.
  • by yarrick (583362) on Monday May 24, 2004 @02:43PM (#9240116)
    Slashdot: Process Improvements [slashdot.org] Wasn't Linus just talking about authors signing kernel submissions?
    • I think it's three things that must be considered: process ( the code ), parliamentary procedure [rulesonline.com] ( codification between people ) and defining standards. If someone makes a point of order about the kernel and this motion is "filed" online in a routine manner then it should be received in open format. I think these things in part will determine how far a paper trail can go.
  • they have opened themselves up to a swamp of 'he said-she said' about where code came from.

    He said "If I tell you, i'd have to kill you".
  • And ironically... (Score:5, Insightful)

    by Fnkmaster (89084) on Monday May 24, 2004 @02:47PM (#9240147)
    The ad on the right part of the screen is a Microsoft ad claiming that "Mainframe Linux was found to be 10x more expensive than Windows Server 2003" at fileserving. Jeez, apparently you need a mainframe to work as a fileserver these days... sounds like somebody was comparing apples to oranges there. Great ad for "searchenterpriselinux.com".


    Also, I would imagine that pretty much every kernel code submission is traceable to it's submitter. As far as I know, every specific line of code that has been brought up by SCO has been tracked down and attributed to it's submitter. Beyond that, there's really no way for BSD, Linux or anybody else to _know_ that the person submitting a patch really owns the copyright to it, or is acting as an authorized agent of their employer who owns the copyright to it. At some point, there is good faith. Yes, a well-documented paper trail would be nice, but requiring patch submitters to submit signed documentation with their patches would place an immense administrative burden on somebody, and it wouldn't prove that no copyright infringement has occurred, it would just blame-shift to whoever submitted the patch. I don't think that would legally remove the possibility that an unscrupulous company could go fishing for damages, a la SCO. It would also effectively remove the bazaar-like openness that Linux has, in contrast with more closed, insular projects with their rigid committer lists and uberpolitical machinations (XFree86 anyone?).


    But I guess from a PR perspective this guy has a good point. Having some big pile of papers to point to and say "look, this documents that all contributers have copyright to their patches, and every line of code is accounted for" - this might help dissuade outrageous claims like SCOs and allay the fears of the business community, which likes to know that there are reams of bureaucratic documentation proving that the code is clean.

    • by Brandybuck (704397) on Monday May 24, 2004 @03:56PM (#9240816) Homepage Journal
      Also, I would imagine that pretty much every kernel code submission is traceable to it's submitter.

      Actually, no. It can be pretty difficult to know where a particular line of code ultimately came from. It can be done, but it will be time consuming. That's because Linus has lots of filters in place before the code reaches him, and historically, no formal repository for the submissions to sort it out. So while you can find out relatively fast that the John gave a patch to Linus, it's much harder to find out who gave that patch to John, and who gave it to the person who gave it to John.

      You Linux advocates need to stop taking every piece of constructive criticism as an attack! If there is a problem, you should go fix it, instead of arguing that it doesn't exist.

      But I guess from a PR perspective this guy has a good point.

      This "guy" is the Grand Master of unencumbered, free and open software. He's also a 32nd Degree Kernel Hacker. When he speaks, you should listen.
      • Because I'm not a programmer or coder, maybe you could answer this question. How is the kernel code documentation (where the code came from) different than that in any other business? In other words, if Megacorp A wanted/needed to track down who added a particular line of code, could they? Could they determine it wasn't stolen, copyrighted, etc? Knowing how documentation is done (or not done) in organizations or lost over time, etc., is this a problem unique to the Linux kernel, or is the fact that the k
      • Re:And ironically... (Score:2, Interesting)

        by Fnkmaster (89084)
        You Linux advocates...

        I don't think I ever said I was a Linux "advocate" - I advocate the right tool for the job. Sometimes it's Linux, sometimes it's not.

        I take all people's opinions and weigh them based on their own value, unless somebody has demonstrated a track record with me of excellent quality thought. I won't accept anybody's argument by authority, thank you very much. I do however think that everybody has known for some time that Linux kernel development needed more structure, needed SCM and
        • Re:And ironically... (Score:2, Informative)

          by Brandybuck (704397)
          When I said "you Linux advocates", I was not referring to you specifically. I was referring to the masses of posts here saying that there isn't a problem. The fact is that there is a problem. Even Linus Torvalds admits it [linuxtoday.com].

          I apologize if I singled out your specific instance of this attitude.
  • Isn't that sort of like trying to trace the sources of popular fables after years of circulation? I agree that for any new module, the author information should be included. For existing modules, however, trying to figure that out is gonna be really hard. Except for the guy that has the patent on the blinking cursor, and other places where a clear intent to earn $ was present from the get-go. Unlike SCO, which seems to only care since Linux became^H^H^H^H^H^H started looking like a threat to UNIX.
  • by Anonymous Coward on Monday May 24, 2004 @02:51PM (#9240185)
    How many closed source companies copy code from various places? I would say open source is the least likely place people will do this considering how easy it is to get caught.

    Anyone out there have personal knowledge?

    • How many closed source companies copy code from various places?

      I can't tell you about the industry as a whole, but so far I haven't seen even one case of a large body of source that didn't have code cribbed from somewhere else (my current employer excluded, I haven't been here long enough to know one way or the other).

      Often this is not widely known, i.e. only one developer might know it happened.

      I do note that over time the practice has become more strongly discouraged. I believe it was the GPL tha

  • When someone submits a potential change to Linux, what mechanisms are in place to verify that the submission is not copyrighted material? Also, what mechanisms are there to eliminate a copyright infringement once one is discovered?
  • by Mustang Matt (133426) on Monday May 24, 2004 @03:00PM (#9240275)
    Paper? What's paper?
  • That we should call this Unix-like operating system Linux.

  • The FSF has been covering their/our asses [fsf.org] on this kind of stuff for years.
  • Kirk has been involved with FreeBSD since forever and knows damn well that FreeBSD isn't documenting where code contributions come from any differently than Linux is.

    Yes, it's an important topic, but Kirk choosing Linux as his example is just plain wacko.
    • by mph (7675)
      Kirk has been involved with FreeBSD since forever and knows damn well that FreeBSD isn't documenting where code contributions come from any differently than Linux is.
      Well, gee, I guess all those "Submitted by:" notes and PR numbers in the CVS logs are in my imagination.
    • Kirk has been involved with FreeBSD since forever and knows damn well that FreeBSD isn't documenting where code contributions come from any differently than Linux is.

      FreeBSD commmit messages routinely contain submitted by: lines. The commit logs are routinely scrubbed for contributors that wind up in the handbook. FreeBSD has been using CVS for 8 years longer than Linus has been using bk, which documents where changes come from much better than linux's former source code control system. The FreeBSD

  • In the end, I think SCO will look foolish.

    In the end ? I like to think there's no time like the present.

  • by Animats (122034) on Monday May 24, 2004 @03:15PM (#9240405) Homepage
    I wouldn't worry about it. Look how much effort SCO has put into finding infringements, how unsuccessful they've been, and how much trouble they're in now. Once the SCO case is over, nobody is going to challenge Linux for a long time.

    Meanwhile, SCOX [yahoo.com] is down to 4.74 today. Volume is about a third of the 3-month average; they're falling off the investment radar. IBM's latest set of legal moves put SCO in worst shape than they've been since the litigation started. SCO has an earnings call and webcast [yahoo.com] on June 2. Tune in and hear Darl try to talk his way out of this one.

  • What? (Score:4, Interesting)

    by Anonymous Coward on Monday May 24, 2004 @03:16PM (#9240409)
    'There isn't a well-documented ownership trail with Linux. So, they have opened themselves up to a swamp of 'he said-she said' about where code came from'

    So what? There is a basic flaw in this argument! In the USA anyway, you are presumed innocent until proven guilty. Anybody alleging that source was stolen and placed into Linux must prove that source code:
    a. existed somewhere prior to being placed into Linux
    b. was stolen, not just happens to resemble code that might have been developed independently by someone else

    In short, there should be no burden of proof on Linux's part to prove that the source was not stolen; the burden of proof must be on the accuser to prove that the source was stolen!

    Knowing who submitted exactly which piece of code to Linux will not drain the swamp of 'he said-she said' about where code came from'. In fact, it will make it a lot worse. Consider: company A claims that some portion of Linux source, submitted by person B, was stolen. Person B had business dealings with company A prior to or during the time that the source was submitted. Company A will say that this proves the source was stolen from them since person B obviously had opportunity! They will claim this even if person B had dealings totally unrelated to software within company A.
    • Re:What? (Score:5, Interesting)

      by praksys (246544) on Monday May 24, 2004 @03:28PM (#9240531) Homepage
      In the USA anyway, you are presumed innocent until proven guilty.

      That is only true in criminal trials, and not always true even then. Copyright is civil matter, so the standard is usually "on the balance of the evidence". If one side can produce a pile of documents relating to the development of some code, and the other side can only produce a guy who says "I wrote it" then it is a pretty safe bet that the side with all the ducuments will win.

      Sound stupid? Welcome to the wacky world of intellectual property.
    • In short, there should be no burden of proof on Linux's part to prove that the source was not stolen; the burden of proof must be on the accuser to prove that the source was stolen!

      It might sound strange to folks with a modern education, but the notion of innocent until proven guilty was really designed to protect the innocent. It was not designed as a clever way to secure title to the things one steals. Filing the VIN off the engine block doesn't give you title to the Porsche. Nor should it be used as j

  • by JessLeah (625838) * on Monday May 24, 2004 @03:19PM (#9240428)
    It's very easy to document where code did come from. But it's virtually impossible (if not 100% impossible!) to document that code did not come from any commercial source. By definition, to "prove" that any given piece of code didn't come from a commercial source, you'd have to take every single piece of commercial source code written up to and including the day of the disputed source's release, and grep it.
  • RMS:I told you so (Score:5, Interesting)

    by line-bundle (235965) on Monday May 24, 2004 @03:25PM (#9240496) Homepage Journal
    Was this not one of the reasons the GNU project wanted copyright assigned to it?
    • >

      Was this not one of the reasons the GNU project wanted copyright assigned to it?

      Precisely. It would have made SCO charges much more difficult to come up with in the first place, and much easier to dismiss now.

      The way I see Linus' initial refusal to request assignments or to allow FSF to do so, and his current partial implementation of the idea, it looks like a marketing get-to-the-market-fast idea: do it quick and dirty, once you're established you can go back and fix it. Only you will only fix

  • foo (Score:4, Interesting)

    by JDizzy (85499) on Monday May 24, 2004 @03:30PM (#9240551) Homepage Journal
    This is why the old 4-clause bsd license enforced the notion of not being able to remove the copyright notice itself, and always giving credit for authorship of the code, plus the normal lack of warranty bits. RMS has quotes on the internet and his fsf.org site about this, and to summarize he says that it is too much of a burden to mark the names of each and every contributor to the code. This is just the way the GPL assymilates code, and makes it stink. Marshal is probably right about this since he was at the CSRG when BSD came under the gun about att code infringment..
  • At least for patch submissions anyway. new patch submissions [linuxtoday.com] It's going to take a while to integrate full blown political ass-covering into the linux kernel process -- if that's even what the developers/Linux want. Adding too much of that stuff eventually makes it hard to even fart without signing-off on a dozen "TPS reports" first. Good luck guys.
  • by Thoron (19565) <petri.koistinen@iki.fi> on Monday May 24, 2004 @04:19PM (#9241112) Homepage
    Linus has already acted.

    Date: Sun, 23 May 2004 06:48:09 GMT
    From: Linus Torvalds <torvalds@osdl.org>
    To: Kernel Mailing List <linux-kernel@vger.kernel.org>
    Subject: [RFD] Explicitly documenting patch submission

    Hola!

    This is a request for discussion..

    Some of you may have heard of this crazy company called SCO (aka "Smoking
    Crack Organization") who seem to have a hard time believing that open
    source works better than their five engineers do. They've apparently made
    a couple of outlandish claims about where our source code comes from,
    including claiming to own code that was clearly written by me over a
    decade ago.

    People have been pretty good (understatement of the year) at debunking
    those claims, but the fact is that part of that debunking involved
    searching kernel mailing list archives from 1992 etc. Not much fun.

    For example, in the case of "ctype.h", what made it so clear that it was
    original work was the horrible bugs it contained originally, and since we
    obviously don't do bugs any more (right?), we should probably plan on
    having other ways to document the origin of the code.

    So, to avoid these kinds of issues ten years from now, I'm suggesting that
    we put in more of a process to explicitly document not only where a patch
    comes from (which we do actually already document pretty well in the
    changelogs), but the path it came through.

    Why the full path, and not just originator?

    These days, most of the patches in the kernel don't actually get sent
    directly to me. That not just wouldn't scale, but the fact is, there's a
    lot of subsystems I have no clue about, and thus no way of judging how
    good the patch is. So I end up seeing mostly the maintainers of the
    subsystem, and when a bug happens, what I want to see is the maintainer
    name, not a random developer who I don't even know if he is active any
    more. So at least for me, the _chain_ is actually mostly more important
    than the actual originator.

    There is also another issue, namely the fact than when I (or anybody else,
    for that matter) get an emailed patch, the only thing I can see directly
    is the sender information, and that's the part I trust. When Andrew sends
    me a patch, I trust it because it comes from him - even if the original
    author may be somebody I don't know. So the _path_ the patch came in
    through actually documents that chain of trust - we all tend to know the
    "next hop", but we do _not_ necessarily have direct knowledge of the full
    chain.

    So what I'm suggesting is that we start "signing off" on patches, to show
    the path it has come through, and to document that chain of trust. It
    also allows middle parties to edit the patch without somehow "losing"
    their names - quite often the patch that reaches the final kernel is not
    exactly the same as the original one, as it has gone through a few layers
    of people.

    The plan is to make this very light-weight, and to fit in with how we
    already pass patches around - just add the sign-off to the end of the
    explanation part of the patch. That sign-off would be just a single line
    at the end (possibly after _other_ peoples sign-offs), saying:

    Signed-off-by: Random J Developer <random@developer.org>

    To keep the rules as simple as possible, and yet making it clear what it
    means to sign off on the patch, I've been discussing a "Developer's
    Certificate of Origin" with a random collection of other kernel
    developers (mainly subsystem maintainers). This would basically be what
    a developer (or a maintainer that passes through a patch) signs up for
    when he signs off, so that the downstream (upstream?) developers know
    that it's all ok:

    Developer's Certificate of Origin 1.0

    By making a contribution to this project, I certify that:

    (a) The contribution was created in whole or in part by me and I
    have the
  • by IBitOBear (410965) on Monday May 24, 2004 @04:41PM (#9241429) Homepage Journal
    No matter how convoluted the system you propose to "track" this stuff, it will *always* come down to whether you beleive or can trust "the first order contributer".

    If we knew where every last keystroke came from, there would still be the "bob is lying, that keystroke didn't come from him, he stole it from his bos/frind/company/disassembly-fo-windows or whatever. Or worse, he typed in the code but he got the idea from watching the wonderful-world-of-Disny while reading Cryptonomicon so Eisner and Stephensen are the inventors and deserve X in consideration.

    Many jobs worth doing are only worth doing to a certian standard of completeness. The problem with the porely-named Intellectual Property domain is that, reguardless of whether ideas want to be free or $40 a barrel, the boundary and origin of all ideas is undocumented-bastardary at best.

    All works of any creative mind are, at least in part, stolen from the fertile field of experience.

    There is no fixing that, and the supposition that all the progenitors of what came before do *NOT*, a-prioria, deserve recognition and a stake.

    Turning the provenance of each line of code into a preverse kind of Oscal(tm) acceptance speach *still* wont insure that someone isn't slighted somewhere.

    "I'd like to thank the academy, and my third grade comp-sci teacher for this for-loop, without them I would have never understood that pre-increment saves a temporary. And of course a shout-out to the CPU manufacturer, without whom I'd have never had a chance at direct increment of non-register memory. And of course my Mom, who never let me leave the table without eating all my peas; if it weren't for her I'd have never learned the value of bounds-checking in the completion of a problem domian. I know I'm forgetting someone, but you have all been so wonderful..." -- Rob White, Linux Kernel 6.2 Changelog for kernel.c line 722.

    NOTE: The Above attribution is Under Dispute from the GCC board of optimizers for failure to credit the optimizing community's efforts in envisioning the need for loop unroling and the value of peep-hole allocation of registers...

    Really, how bad does "intellectual property" have to get before people get it into their heads that the Founding Fathers *DID* understand that you cannot own an idea. The absence of computer science from their accumen doesn't mean that these topics are sacrocant, wholly new, and innumerable to that prior understanding.

    Clue please people...

  • The Linux based email lists [theaimsgroup.com], related Usenet postings [google.com] and the raft of public position papers [google.com] is the Linux kernel paper trail. There is heaps of publicly established provenance, it's just scattered all over the internet and residing on people's old harddrives, backup tapes and CD-ROMs.

    To quote Linus Torvalds [lwn.net]:

    People have been pretty good (understatement of the year) at debunking those claims, but the fact is that part of that debunking involved searching kernel mailing list archives from 1992 etc. Not much fu

  • Unisex President, and began to wonder if someone had taken the knife to W or we had elected Michael Jackson. Gad, some Mondays it's hardly worth chewing through the straps to get out of bed.
  • Just in case there are any UNIX/Linux history experts here.
  • You think the code's stolen, you prove it.

    SCO couldn't and they spent a lot of Bill's money trying to convince people that they could.

    TWW

  • With their typical prescience, the FSF discussed this issue. Read the transcript of Eben Moglen's talk [groklaw.net] or listen to the talk [harvard.edu] and you'll find this segment about one hour into the talk (during the Q&A section):

    One of the legal consequences of the SCO affair is that people are going to start to pay closer attention all the time to how free software products are put together. They are going to discover that what really matters is how you deal with the questions of, for example, possible lurking work-for

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Working...