Forgot your password?
typodupeerror
Data Storage Red Hat Software Software Linux

Red Hat Developer Demands Competitor's Source Code 394

Posted by samzenpus
from the let-the-drama-begin dept.
sfcrazy writes "A very serious argument erupted on the Linux kernel mailing list when Andy Grover, a Red Hat SCSI target engineer, requested that Nicholas A. Bellinger, the Linux SCSI target maintainer, provide proof of non-infringement of the GPL. Nick is developer at Rising Tide Systems, a Red Hat competitor, and a maker of advanced SCSI storage systems. Nick's company recently produced a groundbreaking technology involving advanced SCSI commands which will give Rising Tide Systems a lead in producing SCSI storage systems. Now, RTS is blocking Red Hat from getting access to that code as it's proprietary. What's uncertain is whether RTS' code is covered by GPL or not — if it is then Red Hat has all the rights to get access to it and it's a serious GPL violation."
This discussion has been archived. No new comments can be posted.

Red Hat Developer Demands Competitor's Source Code

Comments Filter:
  • by johnjones (14274) on Wednesday November 14, 2012 @06:58PM (#41986431) Homepage Journal

    thats what makes the difference...

    if its just something he is developing at the moment AFAIK then he does not have to release it until he gives it to others...

       

    • by johnjones (14274) on Wednesday November 14, 2012 @07:04PM (#41986497) Homepage Journal

      ok reading the list nick had this to say :

      "
      Accusing us of violating GPL is a serious legal claim.

      In fact, we are not violating GPL. In short, this is because we wrote
      the code you are referring to (the SCSI target core in our commercial
      RTS OS product), we have exclusive copyright ownership of it, and this
      code contains no GPL code from the community. GPL obligations only
      apply downstream to licensees, and not to the author of the code. Those
      who use the code under GPL are subject to its conditions; we are not.

      As you know, we contributed the Linux SCSI target core, including the
      relevant interfaces, to the Linux kernel. To be clear, we wrote that
      code entirely ourselves, so we have the right to use it as we please.
      The version we use in RTS OS is a different, proprietary version, which
      we also wrote ourselves. However, the fact that we contributed a
      version of the code to the Linux kernel does not require us to provide
      our proprietary version to anyone.

      If you want to understand better how dual licensing works, perhaps we
      can talk off list. But we don’t really have a responsibility to respond
      to untrue accusations, nor to explain GPL, nor discuss our proprietary
      code.

      We’re very disappointed that Red Hat would not be more professional in
      its communications about licensing compliance matters, particularly to a
      company like ours that has been a major contributor to Linux and
      therefore also to Red Hat’s own products. So, while I invite you to
      talk about this with us directly, I also advise you – respectfully – not
      to make public accusations that are not true. That is harmful to our
      reputation – and candidly, it doesn’t reflect well on you or your
      company.
      "
      so basically if they developed the code and use a closed source OS that is not linux then redhat don't have a leg to stand on...

      if they use a module inserted into linux then it will "taint" the OS then it gets shifty...

      have fun

      john

      • by idontgno (624372) on Wednesday November 14, 2012 @07:24PM (#41986733) Journal

        The version we use in RTS OS is a different, proprietary version, which we also wrote ourselves.

        This is probably what Red Hat thinks needs to be proven.

        Pure hypothetical in contradiction of RTS's statement follows. Entirely fictional. However, I'm betting this is what Red Hat is worried about.

        RTS writes Linux SCSI core driver. Contributors improve it. RTS backports Linux SCSI core driver, including contributed improvements, to RTS OS and then closes it off as proprietary.

        This scenario would be a GPL infringement. This is probably what Red Hat suspects. This is contrary to RTS' claim, which is: The RTS OS codebase is clean, and is not a derivative product of the GPLed Linux codebase (with other contributions).

        But I agree... the burden is on Red Hat to prove it. Demanding a code audit of a proprietary software codebase just because you suspect non-compliant backporting doesn't sound like it would work. In the meanwhile, they've poisoned relationships with a major code contributor. I hope it was worth it.

        • by LordNimon (85072)

          This is probably what Red Hat thinks needs to be proven.

          Yes, and RTS has no obligation to comply. Red Hat could sue, but only if they have basis for claiming that they own the copyright of the "stolen" code.

          RTS could make Red Hat happy by running a Black Duck analysis on their proprietary code and sharing the result.

          • by icebike (68054) * on Wednesday November 14, 2012 @08:15PM (#41987187)

            RTS could make Red Hat happy by running a Black Duck analysis on their proprietary code and sharing the result.

            That would likely not be reliable, since the wrote the original and forked it into the kernel, and developed the original further into their own product. The analysis would certainly contain many false positives since the kernel source came from proprietary source.

            Besides, its only the back-flow of contributed changes that would make the GPL apply to their original code, and perhaps not even that
            would be sufficient. Does a contributed two line patch drag the entire original proprietary source into the GPL?

            • by Immerman (2627577) on Wednesday November 14, 2012 @10:57PM (#41988345)

              Besides, its only the back-flow of contributed changes that would make the GPL apply to their original code, and perhaps not even that
              would be sufficient. Does a contributed two line patch drag the entire original proprietary source into the GPL?

              Not quite - if the proprietary module links into the Linux subsystems, as seems extremely likely, then the whole module likely becomes a derivative work, the exact details become very important in that case. The nVidia drivers walk this line, which is why you don't see them integrated into with any Linux distro - doing so would tilt the balance towards the derivative work interpretation and is likely to elicit a cease-and-desist letter.

          • by akpoff (683177)

            RTS could make Red Hat happy by running a Black Duck analysis on their proprietary code and sharing the result

            Bradley Kuhn addressed [lkml.org] this already with two objections:

            1. Blackduck can only confirm that the code in question doesn't copy directly from code in it's look-up database. It can't determine whether a given bit of modified code is a derivative work under copyright law and hence a possible GPL violation (where GPL code is involved).
            2. The Blackduck software is proprietary. While their clients may feel
        • This scenario would not be a GPL infringement.

          The main point of the GPL is: you give me some binary, my it payed or volunary, you have to give me (on request) also the source.

          As Red Hat has no way to get the binaries, without buying them first, talking about GPL infringement is a step to early.

          • That is oversimplifying it too much. It does also state that if you make changes and distribute to anyone as binary or otherwise, you have to make those changes available to any third party, not just the recipient of the binaries, as per:

            b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

        • by pla (258480) on Wednesday November 14, 2012 @10:17PM (#41988143) Journal
          This is probably what Red Hat thinks needs to be proven.

          Then they would have it completely wrong.

          "As you know, we contributed the Linux SCSI target core, including the relevant interfaces, to the Linux kernel. To be clear, we wrote that code entirely ourselves, so we have the right to use it as we please."

          RedHat would, instead, need to disprove that. I honestly don't know the truth of it, offhand. But, if true, RedHat doesn't have a leg to stand on.

          If I modify your GPL'd code, I need to release my changes. If I releasing my own code under the GPL, I can also release it however else (ie, closed and proprietary) I want, and you can't do a goddamned thing about it. You have no rights to my further improvements thereof, you have no rights to me continuing that codebase in the future, you simply have no rights beyond what I've granted you with the GPL version.

          More to the point - The GPL doesn't change the ownership of a snippet of code. It only changes the terms under which others can use that code. The original author still retains the right to do whatever the hell he wants with his code.
      • by bug1 (96678)

        "so basically if they developed the code and use a closed source OS that is not linux then redhat don't have a leg to stand on..."

        Is RTS OS is a closed source OS, or is at a dressed up Linux kernel ?

      • by wvmarle (1070040)

        so basically if they developed the code and use a closed source OS that is not linux then redhat don't have a leg to stand on..

        The OS they use is irrelevant. You can very well have closed-source, proprietary software (or even drivers) that run under Linux. That the Linux source falls under the GPL doesn't mean your software has to be GPL, too.

        You only need to release your code under the GPL if you use other software that is GPL licensed (and to which you do not own copyright yourself).

      • by saleenS281 (859657) on Wednesday November 14, 2012 @09:01PM (#41987543) Homepage

        They use Linux, there is no proprietary OS. From their own description:

        RTS OS is a single-node integrated storage operating system based on Linux and the standard Linux Unified Target, developed by RisingTide Systems (RTS), including support for iSCSI, Fibre Channel, FCoE, InfiniBand, SMB2 and NFS3/4.

        http://www.linux-iscsi.org/wiki/RTS_OS [linux-iscsi.org]

      • Re: (Score:2, Insightful)

        by hairyfeet (841228)

        I'll get hate for saying this but NOW does everyone see why words like "viral" get applied to the GPL? Here they gave code they wrote to the Linux SCSI team which they used. They can take that same code and make a proprietary version all they want because THEY WROTE IT yet the are being accused of violating the GPL because they have a proprietary version of their own code?

        It is THEIRS, they wrote it, they can do what they will and license it any damned way they want! The only thing they CAN'T DO is take the

    • by wvmarle (1070040)

      It is most definitely something that's intended to ship to third parties, so this may just be a pre-emptive move by this Red Hat developer to make sure no infringement will take place.

      • If so, he did it in a rather bone-headed way. A nice, polite letter from an attorney is usually considered the standard way to go about this; not yelling at somebody in a public forum.
  • Epic grammar fail (Score:5, Insightful)

    by Anonymous Coward on Wednesday November 14, 2012 @07:00PM (#41986461)

    Now, RTS is blocking Red Hat for getting access to that code as its proprietary.

    What is this I don't even

  • by YodasEvilTwin (2014446) on Wednesday November 14, 2012 @07:00PM (#41986465) Homepage
    That's what it seems like from the summary. If not can anyone explain why? I'm not about to read a kernel mailing list.
    • by greg1104 (461138) <gsmith@gregsmith.com> on Wednesday November 14, 2012 @07:31PM (#41986809) Homepage

      This is a no lose political play by RedHat; they never expected there was a real licensing violation. Consider the two outcomes here:

      -Rising Tide Systems says that it developed their EXTENDED_COPY and COMPARE_AND_WRITE commands under a different license, walled off from the main code they contributed to the kernel under the GPL. (That's what they've done now). Then RedHat's sales position is that people who buy Rising Tide's Linux are getting a licensed closed-source product. It is guaranteed not to integrate smoothly with the *real* Linux kernel because of the architecture needed to keep it licensed differently, it's not getting community review for features and security issues, and if Rising Tide goes out of business their customers are screwed--good old fashioned vendor lock-in.

      -Rising Tide rolls over and releases their code into the mainline kernel. Now RedHat benefits from it being available too.

      RedHat makes much of its money from companies that are moving to open-source because they are sick of the downsides of commercial software, which go from quality issues to vendor lock-in. They're compelling Rising Tide to either give away somethings they're trying to keep closed, or to shame themselves by admitting they're not really an open-source team player. RedHat can launch that sort of acusation safely because they are operating very transparently. We know that companies are not locked in to RedHat from how many clones of it exist. When CentOS and Scientific Linux work, clearly RedHat is sharing all the important parts. And if you've made that part of your competing position, preaching down to people who are not sharing as being sellers of inferior products is very easy to do.

      • Re: (Score:3, Interesting)

        by Anonymous Coward

        I think the more interesting concern isn't so much RH v. RTS, it's what happened to SCST not long ago. Vladislav Bolkhovitin has a nice, solid option in SCST (http://scst.sourceforge.net/index.html) that was skipped over in the upstream kernel in favor of the LIO stuff from Rising Tide Systems. We moved away from SCST to LIO at work even though we didn't think it was quite as good simply because being embraced by the community usually means that you win long term. Andy basically makes this point:

        "But let

    • by evilviper (135110)

      The LKML thread isn't long, and it's entirely on-topic, unlike most.

      RTS (the accused) engineer and lawyer have asserted they are not violating the GPL, but things they've said to justify that don't hold up to scrutiny, and at least imply license violation. They may well be correct, but they're completely failing to explain their position and answer questions.

  • Someone ought to tell the fucking idiot that the onus is on the ACCUSER to prove his case, not the other way round!

  • Proof of evil always has to be shown by the accuser. Not the other way around. Otherwise all companies could get the family jewels of all other companies.
  • by bogaboga (793279) on Wednesday November 14, 2012 @07:04PM (#41986501)

    From the LKML [lkml.org]

    Your company appears to be shipping kernel features in RTS OS that are
    not made available under the GPL...

    I've heard such statements before. They remind me of SCO and their lawyers back in the last decade, when they accused Linux of containing copyrighted source code.

    Result: Not good. I hope it isn't the case for Red Hat.

    • Yep, features aren't in the scope of copyright, specific implementations are.
  • by Sloppy (14984) on Wednesday November 14, 2012 @07:07PM (#41986537) Homepage Journal

    Seems like RTS customers are the ones who would have a right to demand the source to whatever GPLed software they bought or been given. And any of them could legally "leak" to Grover. Not sure how RTS currently has any obligations to Grover, though. Why would they?

    Remember that GPL is about protecting users. As handy as it usually is for developers, that's incidental; it's not for developers.

    • by DragonWriter (970822) on Wednesday November 14, 2012 @07:31PM (#41986805)

      Seems like RTS customers are the ones who would have a right to demand the source to whatever GPLed software they bought or been given. And any of them could legally "leak" to Grover. Not sure how RTS currently has any obligations to Grover, though. Why would they?

      Presumably because Grover as the Red Hat SCSI target maintainer (or, more likely, Red Hat as his employer) contributed, under the GPL, code (patches, etc.) to the piece of Linux he accuses RTS of infringing, thus what Grover is doing is accusing RTS of infringing the copyright on his (or Red Hat's) code by not complying with the GPL with regard to that code.

      Remember that GPL is about protecting users. As handy as it usually is for developers, that's incidental; it's not for developers.

      The GPL, like all copyright licenses written or chosen by the licensor with a take-it-or-leave-it choice for the licensee is used by copyright owners to protect the interests of the copyright owner; its not a contract, so users don't even have the arguable enforcement rights they might have as intended third-party beneficiaries of a contract. Now, it may be that the FSF, as the original authors and users (as licensors) of the GPL had, as their interests in mind for it to protect, what they perceived to be the general public interest or the interests of end-users. But it would be a mistake to forget that its for copyright owners, first, last, and only.

    • by wvmarle (1070040)

      Seems like RTS customers are the ones who would have a right to demand the source to whatever GPLed software they bought or been given.

      Which, according to RTS, is none at all. No GPL software included in their offerings, so no source needs to be given to anyone.

  • by Anonymous Coward on Wednesday November 14, 2012 @07:10PM (#41986577)

    Hi Alan and others,

    I've been advising Rising Tide Systems (RTS) in this matter. Please let me reassure you that RTS is acting on advice of counsel.

    RTS (and specifically Nicholas Bellinger) wrote the scsi target code and owns its copyright. We registered that copyright at the Library of Congress. RTS contributed a version of the scsi target to Linux for distribution under the GPL. On behalf of Marc Fleischmann, CEO of RTS, I can reassure you that RTS remains committed to the Linux project and will continue to contribute to it. We are pleased that RTS software is a part of the Linux distribution under the GPL.

    RTS also has a commercial software business. It distributes versions of its scsi target code that support features and functions not officially in Linux (or at least, not yet). That commercial RTS business includes the licensing of those derivative works of its own code to its own customers. Nothing whatsoever in the GPL or in the policies of the Linux Foundation prohibits that.

    I would also like to address some comments made on these lists by Andy Grover and Bradley Kuhn.

    First, I hope that we can tone down the arguments about whether the use of Linux APIs and headers automatically turns a program into a derivative work
    of Linux. I think that argument has been largely debunked in the U.S. in the recent decision in Oracle v. Google, and in Europe in SAS v. World
    Programming. Does anyone here question whether the original work that RTS contributed to Linux (and that *is* under the GPL) is an original work of
    authorship of RTS despite the fact that it links to other GPL code using headers and APIs?

    Second, we are grateful for the efforts that Bradley Kuhn and others put in to enforce the GPL. As I said above, RTS owns and has registered the
    copyright on its scsi target and will enforce it if necessary. So Brad, we may solicit your assistance if we find any third party who is distributing
    an unauthorized non-GPL derivative work of the scsi target now in Linux. RTS, of course, retains the exclusive right to do so, but no third party can
    do so without a license from RTS.

    Best regards, /Larry

    P.S. In accordance with my obligations as an attorney when communicating with a represented person, I am copying attorneys for Red Hat and Linux Foundation on this email. If anyone wishes to respond to me, please copy me directly since I am not subscribed to these lists.

    Lawrence Rosen

    • Don't blame me. I voted for Kodos.

    • I'm afraid that seems pretty clear cut.
      No developer in their right mind would claim that including APIs induces a derived work (LOL Oracle).
      It's actually a shame that this took place in public. Whichever way it goes someone looks bad.
      There could be defamation or libel claims.

      • by pavon (30274) on Wednesday November 14, 2012 @08:55PM (#41987501)

        First off this is nothing like the Oracle case. That was a case about reimplementing APIs, and has nothing to do with linking against someone-else's code that provides APIs. Secondly, it is a stretch to say that the RTS SCSI target is just including APIs. It is using all sorts of internal kernel functions that go far beyond what most reasonable programmers would consider to be an API to the kernel. If you interpret things that liberally, then any proprietary modifications to a GPL application would be allowed by just bundling up the list of functions you happen to use and calling it an API.

        • I didn't bring up Oracle vs Google, Larry did. Apparently there was argument that including header files and using the Linux APIs automatically makes software a derivative.
          This position is absurd. If that's the whole argument then it's clear cut.
          That's my only point.

          I know quite a lot about the Oracle vs Google case, and I agree this is quite different.
          However, it's not the specifics of the case that are important: it's the HOLDINGs.

        • by arkhan_jg (618674) on Thursday November 15, 2012 @03:08AM (#41989387)

          First off this is nothing like the Oracle case. That was a case about reimplementing APIs, and has nothing to do with linking against someone-else's code that provides APIs.

          Actually, the Oracle case is pretty relevant. Oracle's argument was that the API itself of java - the structure, sequence and organization of it - was copyrightable, not just the code that implemented the API. Google clean room re-implemented the code that made up the API, but kept much of the structure of the API itself. The court decided that the API wasn't copyrightable, a good decision. Ergo, anything that merely USES an API cannot be a derivative work of the code that implements the API, as the API itself isn't copyrightable - if that wasn't the case, that would open up a really huge can of worms. In effect, the API becomes a firewall between two differently licenced bits of code. Which is of course what nvidia use for their binary blobs, for example.

          Anyway, even if we assume the scsi target code in question static links to code beyond the API and does thus become a derivative work, then the upshot would be the code in the kernel... would have to be under the GPL v2. Which it already is. So it's rather a moot point.

          As long as the code in RTS' private repository has no back-ported GPL code from the kernel, i.e. they haven't imported 3rd party written GPL covered patches into
          their own private code, then they can dual licence their private version however they like. Putting a version of their scsi target software into the kernel under the GPL makes no impact whatsoever on their copyright of said code, even if it is subsequently modified in the GPL kernel version by others. They can't of course fork the GPL version with others contributions and take it private without every contributors permission; but that's not what they're doing by the sounds of it.

          As long as the code-flow was one-way - i.e. private to GPL, not two-way including GPL into private, they can write performance improvements to their commercially licenced one all day long and not port them to the GPL version in the kernel as much as they like.

          And so what, anyway? Linux gets a decent SCSI target (I've used it a few times in production; it does what it says on the tin) it wouldn't otherwise have; and RTS have a commercial product for those wanting a higher performance product for high-end usage, thus allowing them to actually stay in business. Most code in the kernel, and the gnu/linux platform comes from individuals working for or sponsored by companies; those companies make money by various means, and that's what pays for the coders. Hobbyist coders do produce quite a bit of course, but linux wouldn't be where it is without commercial support.

          And I've just realised why the API argument is important. If using the API makes code a derivative work, then the commercial version of the SCSI target module using the GPL kernel APIs would also have be GPL licenced. But given the Oracle-google case, that seems a hell of a reach, and certainly APIs were not considered to create derivative works before anyway - that's rather the point of an API, to allow two pieces of code to communicate without getting up in each other's business...

      • No developer in their right mind would claim that including APIs induces a derived work (LOL Oracle).

        This is exactly the position that the FSF takes (and led to their creation of the LGPL).

    • by shutdown -p now (807394) on Wednesday November 14, 2012 @07:52PM (#41987005) Journal

      It's the most interesting part of this whole affair by far, since they are, essentially, arguing that linking with GPL'd code does not make your own code GPL'd, even if you redistribute the result as a single work. If this can, indeed, be successfully argued in court, this would significantly change the nature of GPL - in effect, making it more like LGPL if not weaker (if static linking is fine also).

      • Your parent talked about linking AND referencing APIs via includes.
        The former is considered to be a derived work, the later not.
        So the former is relevant for/falling under the GPL, the later not.

        • Yes, but they are effectively challenging the former here, as well. There is no other way they can claim to have kernel-mode non-GPL'd code here, at least without some kind of shim (though even that was historically treated with skepticism).

      • by Rich0 (548339)

        He's talking about header files. The GPL is a license - it lets you do things that you couldn't otherwise do. Copying header files is something you can do with or without a license, as they define an interface, and tend to be trivial. Both of these are grounds for fair use.

    • and be replaced by the BSD license. What RH is doing is sickening and as another pointed out, very much SCO like. And lets not pretend that there is no software released under the BSD or similar license either (see PostgreSQL for one). While I loved Slackware for over a decade, one of the reasons I switched to FreeBSD was the GPL (and the legions of Stallman). It will be a very happy day when FreeBSD is rid of the last of remains of GPL.

  • If you don't comply with the GPL, than at most, you are violating copyright law.
    Following the GPL is optional. It grants you certain rights if you follow it.
    You might have those rights anyway, or you might decide it's better to pay the fines for copyright violation, but I don't see how you can be forced to follow the GPL.

  • by hey! (33014) on Wednesday November 14, 2012 @07:49PM (#41986985) Homepage Journal

    Red Hat hires a software development consultant who is not competing with RTS to examine the code (probably a respected academic). After signing an NDA with RTS, they give him access to the source control archive. He pokes around in the commit history and writes his report. If there *is* infringement, it'll show up and RTS pays the consultant's fee and desists from using the GPL'd code. If there is no evidence of infringement, Red Hat pays the consultant's fee and issues an apology.

    Note that I said this *should* be easy to resolve. If RTS is deliberately infringing the GPL, they won't go along with this reasonable suggestion. If Red Hat is just trying to stick a thumb in a competitor's eye while scoring some trade secrets, they wouldn't agree with the suggestion. Both conditions might apply at the same time.

    • by HornWumpus (783565) on Wednesday November 14, 2012 @08:02PM (#41987093)

      Easier to resolve.

      RTS issues single fingered fertility gesture. Suggests GPL advocates take it up with brick wall. Resolved.

      • by jedidiah (1196)

        That's fine as long as litigation doesn't ensue.

        RTS would be sued or prosecuted like any other accused pirate.

        • by The Rizz (1319)

          RTS would be sued or prosecuted like any other accused pirate.

          Told their IP address looks funny, and they need to pay $$$ or have their internet cut off?

        • by Rich0 (548339) on Wednesday November 14, 2012 @09:42PM (#41987875) Homepage

          Yup, and if found innocent they'd countersue for defamation and slander. You can't just go around accusing people of committing a crime without proof.

          Can you prove to me that you didn't beat your wife this morning? How about we find a third party and have them set up cameras and monitor you 24x7 at home for a few weeks just to be sure?

          You can't go around accusing people without proof and expect them to jump through hoops to prove their innocence.

    • by LingNoi (1066278)

      There already is evidence of infringement they cite code that intel contributed and shows up in their proprietary version of the module. If you're developing a competing proprietary module you shouldn't be the kernel maintainer anyway. This guy has the power to refuse patches to the open sourced version to make his company's version remain better. The fact there is a conflict of interest there shows he shouldn't be in that position regardless of the fact that he's probably the best guy for the job.

  • Assuming the code in question falls under GPL that gives no one the right to request it, unless he is a customer.

    If you sell me a device, plus binary code like drivers, where the source code is under GPL then I have the right to request the source code.

    If I'm just a random nitpicker who has not said binary code, I have no righs to demand the source code.

    • by Todd Knarr (15451) on Wednesday November 14, 2012 @08:29PM (#41987305) Homepage

      That would be correct if and only if the vendor is providing the source code along with the device. If they aren't, then GPL v2 section 3b [gnu.org] applies:

      Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

      Emphasis mine. It doesn't say just customers. It doesn't say just people who have the binaries. It says "any third party". That means any third party, no further restrictions or conditions. The GPL v3 would let you limit your obligation to provide source to only those who have the binaries, but the Linux kernel is under GPL v2 without the clause allowing use of later versions.

      • Oh that is interesting, the emphasizis, that is. Perhaps licences should be written in a way that they emphasize such important stuff.
        For some reason I have difficulties to note such minor but important words.

      • by Kjella (173770) on Wednesday November 14, 2012 @11:14PM (#41988439) Homepage

        Emphasis mine. It doesn't say just customers. It doesn't say just people who have the binaries. It says "any third party". That means any third party, no further restrictions or conditions.

        I think your interpretation is wrong. If company A makes a special binary for company B along with an offer for source code, then random company C can't come and demand the source code for company B's version. The FSF FAQ says:

        (...) When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. (...) The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.

        That is to say, if you have an offer they must honor it no matter who you are. If you don't have an offer, you get nothing. It's like a cashier's check, whoever holds it can cash it. But no check, no money.

  • by Theovon (109752) on Wednesday November 14, 2012 @09:48PM (#41987919)

    I and an employer put a ton of code out under GPL. We had an arrangement, like TrollTech and MySQL, that contributors could only get their contributions into our trunk if they gave us copyright. (Otherwise, the licencing terms clearly stated, they could strip off our licensing terms, fork, and put out a derivative strictly under GPL that we wouldn't touch.) This was plainly stated, contributors agreed to it, and most certainly, all of our code and that of our contributors has always been made available under GPL in addition to our ownership of the original copyright. It was even clearly stated on our wiki and in our source files how this works and that we might license the code commercially. One day, some dude comes along and contributes like a single line of code. Unless he was blind, he read the licensing and contribution terms. Then years later he "discovers" that that very same employer put out a commercial product based on this code that we had original copyright for. As if a company that developed a bunch of IP wasn't going to use it in their products? But he claims they're violating the GPL, makes a big stink about it, and then he brings up again a few more years later, and someone on one of the tech news sites picks it up, and it gets worse from there.

    I'm a huge fan of the GPL, but I'm sick of these dipwads who can't distinguish between a version licensed under GPL and the original work that's derived from. Meanwhile, they brainwash a bunch of other losers into thinking we're doing something wrong, while the whole time, we've worked carefully to ensure that we've been 100% precise and explicit and open about our intentions and careful attention to the terms of the GPL. (And BTW, I'm married to a lawyer, so I have extra help being ultra-precise about the GPL and copyright law.) To those people, the GPL is a religion, and anything not under GPL is evil. Moreover, anything related to a GPL'd work MUST be a derivative of the GPL'd work (not the other way around), because no commercial company is ever capable of producing anything that good, and when they release works under GPL, they must have hidden motives.

    In our case, the only reason we bothered to retain original copyright was because we were making open source HARDWARE and hoped to be able to fund development by commercially licensing our IP, which we did, which was the main reason we were able to build real hardware in the first place, which everyone knew we were going to have to do, which is why we added those licensing terms in the first place. Hardware is expensive to manufacture. Because of this (and plenty of other contributors and some donations), we were successful at producing 100% open source hardware.

    Sometimes, I feel like some of these people actually know they're being idiots. They're trolling, and they're doing it in an intentional attempt to derail an open source project. Like they're bribed by Microsoft, there to stir up trouble for FOSS projects by making political waves. But someone will come along and point out that if you have to choose between malice and stupidity, stupidity is the more probable option.

    Personally, my motivation is to make things that work and contribute to the global mindshare. It's not so much source code that I want to share. Source code is only one form of expression. It's KNOWLEDGE that I want to share. And I enjoy creating new knowledge. Now, we always have to consider the ethical consequences of what we do in science. We do science to improve the world, so if there's some way we might harm it instead, we have to find alternatives. But I'm tired of these jerks whose sole purpose in life seems to be to confuse people and make life all-around more difficult for everyone. This is just as bad as people who try to legislate creationism into the science class. (But you know what, they do this because they're jobless losers with too much time on their hands; the rest of us actually have useful work to do.)

"Everything should be made as simple as possible, but not simpler." -- Albert Einstein

Working...