Previous Entry Share Next Entry
happy
yesthattom

"Gnu Public License" Policy question

[Note: I've hurt my shoulder and typing is painful. This will be terse and I may not correct typos.]

I thought this would be directly in the Gnu Public License but I don't see it anywhere.

How soon after I write the code (i.e. make changes to a GPL-licenced work) do I need to release the change?  Obviously "immediately" doesn't make sense... how soon is now?  After each keystroke?  No.  After I save the file?  no.  After I'm fairly sure it works as expected?  (I could just use the excuse "it isn't ready yet" over and over and never actually release the change).

I had heard it was 12 months (or was it 6 months?) but I don't see that in the license.  (I admit I skimmed it, but I also grepped for the words "day" "month" and "year")

The FAQ says:
http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic

So, I assume it is "as soon as you release it to the public" but is there precident for waiting some amount of time?

  • 1
(And I'm on my phone...)

Well, until you *distribute* your work, you're under no obligation to make your changes available at all. If you're just tweaking (say) Emacs for your own personal use, for instance, you never need to make those changes public.

So as you're making your changes, you haven't yet distributed a binary, so you don't need to distribute your source. But when you give somebody else a binary (whether modified or not) you also need to provide them (or offer to provide) the corresponding source.

Details vary between GPLv2 and GPLv3, since part of the point of GPLv3 was to prevent using hosted software (SaaS) as a loophole to avoid releasing your code.

(I don't remember enough of GPLv2, and never read the right bits of GPLv3, to know whether there are explicit time constraints. But I think the main reason companies get away with releasing binaries and waiting weeks or months to release corresponding source code is that GPL advocates don't tend to sue untill they've exhausted other options for achieving compliance. And of course, sometimes you have a "product" like Android or Zimbra which is an aggregation of Free, open-source, and closed-source components, and different rules apply to the different components.)

This -- you can change whatever you want without releasing. Just because the mainstream FLOSS community has said "it's not really open source until people can contribute back" doesn't mean it's true. Nor does it mean you HAVE to contribute back any derivative work.

However, if you distribute the change you have to distribute the source, with the same license.

This is my understanding based on GPLv2.

Note that that only includes changes to the source code that IS under GPLv2. If you're building something using the code (say, using an API) you don't have to release the source of your code (for instance, if you develop a plugin for MySQL).

I think most lawyers would argue that you need the source code to create a binary, and thus there's no real reason *not* to release the source code at the same time as the binary.....thus if you release a binary and not source code (when you're obligated to also release the source code) lawyers would argue you are not "acting in good faith".

PS — Again, IANAL nor a Free Software or Open-Source licensing expert, but since GPLv2 doesn’t explicitly stipulate a timetable for fulfilling your offer to provide source (if you choose that option), I would guess that standard case law regarding fulfilling contracts would come into play, and if somebody sends you email at 12:30 am asking for the source, and you don’t send it until you check your email at 9:00 am, a court would say that was fine, but if somebody sends you email on January 3d and you reply on April 12th saying you’re awaiting a new shipment of zeros before you can put all the bits on the wire, and you hope to send it out sometime early next year, a court would not consider that a good-faith effort to comply with the terms of the license.

i have no idea about your Gnu question, but i'm sorry to hear that your shoulder is still hurting!

(Deleted comment)
What are the internal code controls?
Well, a best practice would be to tag the open source release when you check it in and publish a diff from that tag until the release tag.
If you don't have such sophistication, just download the open source tarball from back when you forked and diff against the tree.

Veyr best practice? Have a person at the company who's full-time job is to assure compliance with F/OSS licences, making the inclusion of FOSS code into the source code a well-defined process with tools that make it easy to do things like publish releases, tell which internal products used code of which license type, etc. Part lawyer, part toolsmith.

Thanks, Everyone! That answers it for me. The answer being "ship the source at release time; no release == no need to ship".

Pretty nice post. I just stumbled upon your blog and wanted to say that I have really enjoyed browsing your blog posts. In any case I’ll be subscribing to your feed and I hope you write again soon!


  • 1
?

Log in

No account? Create an account