7

Since everyone can sell open source software, modified or unmodified, at any price, under GPL and MPL as long as I know, can I do it without providing the source code since the recipients are just "end users", I'm already selling a lot of copies of installer downloaded straight from their official builds. I am not providing the source code but providing the license text files together with the binary.

Is it enough to put an instruction text file on how to obtain a copy of the source code? Like "To get a copy of the full source code of this software, you can go to github.com,......"

1
  • 10
    Generally to note that GPL isn't really concerned with the selling of software at all. Whether you convey the program to somebody who should test and/or develop it further, or to an end user who's unlikely to be interested or capable of using the source, doesn't matter to it. Jun 27 at 11:21
20

GPLv3 directly addresses your question, so no speculation is required. Conveying unmodified code is covered in s4, and conveying other forms than source code in s6. s6 says that

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.

It seems to me that telling people who download your code that the source is available on github, and providing a link to the repository, satisfies that obligation, provided they are told prominently, clearly, and at the point of binary download. Tucking this notification away in a file buried five levels deep in your documentation, called wombat_equivalence.tex, will not satisfy this requirement. Note also that if github goes offline or the original author deletes the repository, that's your problem, not your users'.

GPLv2 contains similar language at the end of s3. I'm less sure about MPL but I'd be surprised if it were not also similar.

In passing, I don't quite understand why you think that "the recipients are just "end users"" would make any difference, here. The GPL doesn't distinguish between developers who need source code and end-users who don't: to it, all users are developers in potentia, and are protected accordingly.

11
  • 1
    Very informative, thank you, now i am rest assured that i can not possibly disobey some rules after reading the GPLv3 and MPLv2 again and again. Anyways, could you also give me an idea how most , vendors, or bundlers of open source software , package their "Product". Example, when conveying a copy of a opensource software installer, on that same directory there should be the corresponding license text file. Installation instruction and further instructions how to get full source code. What other stuffs do i need to bundle for the sake of validity of my .... Sale.... Thank you again.
    – jayjay19
    Jun 27 at 10:06
  • 4
    @jayjay19 you're very welcome. Source packaging doesn't have much in the way of rules. A gzip'ed tar file is almost always acceptable; many OS-distro packaging systems have package forms for source (srpm, dsc); git-based repositories allow the whole of a package's source to be downloaded with the git command. The important thing is not so much the format, but that the source provided be the Complete Corresponding Source, ie source that with standard tools can be used to rebuild the accompanying binary. If you're making that available, things should be fine regardless of the precise form.
    – MadHatter
    Jun 27 at 10:07
  • 5
    I think the OP may technically need to fork the source code to be able to provide a download link under their own control - they can't rely on the original source repo staying up. As a distributor of the compiled code they are responsible for ensuring that the their customers have continuing access to the source code.
    – bdsl
    Jun 27 at 12:40
  • 3
    @bdsl I agree with the latter part of your comment, and I hope I'd made that clear. Forking the repo would be one way to make sure the source was available, assuming github stayed up, but they could equally take a copy and host the tarball themselves.
    – MadHatter
    Jun 27 at 14:47
  • 3
    @MadHatter: Strictly speaking, you need to make sure the source is accessible at the moment the user downloads the binary. There is no requirement (unlike the "written offer" option) that the source continue to be available indefinitely once you stop distributing binaries. So if the original GitHub link goes dead, you can just stop offering binaries.
    – Kevin
    Jun 27 at 18:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.