Legal Group Releases Guide To GPL Compliance 141
An anonymous reader brings news that the Software Freedom Law Center has published a guide for compliance with the GNU General Public License. The purpose of the guide is to prevent "common mistakes" the SFLC has encountered during its various GPL violation investigations. Their suggestions include close scrutiny of software acquisitions, more precise tracking of changes and updates, and avoiding "build gurus." They also provide tips for dealing with a violation. The full guide is available at the SFLC's website.
Good fun to make up your own license (Score:1, Informative)
but yes this does rather highlight all the obligations of the GPL, which is a good thing because a lot of companies don't realise what it actually entails.
When making a software product from open source software, one of the tasks is to find out about all the licenses and to be quite honest it is to avoid a lot of software that is GPL, which thankfully most isn't as far as the building blocks go.
GPL software is nice when you want to include a tool that the end user can use but is not central to your software. And, if you have to make alteration then ensuring that alteration is distributed alongside the source for that GPL software is good practice.
Build Guru (Score:1, Informative)
Re:Build Guru (Score:5, Informative)
I don't think that the term is a standard one in the broader sense; but it is clear enough for the purposes of their discussion. Relying on one person's personal knowledge for a vital step in your process is never ideal, especially if you have a legal obligation to provide your customers with some of that knowledge, if they ask for it. Simple enough, really.
Build Gurus (Score:4, Informative)
The GPL requires you to include the scripts used to control compilation and installation of the executable. It does not require you to provide the knowledge needed to use those scripts, if it's all in someone's head. So having "build gurus" doesn't necessarily put you out of compliance, though it might make it hard to demonstrate you are in compliance.
Re:Sounds awefully *AA-ish... (Score:3, Informative)
Copyleft licences are quite explicit about using copyright to achieve their aims, just as ordinary copyright licences are. Now, it is true that people who use and advocate copyleft licences are frequently, though not universally, likely to advocate significant copyright reform of one sort or another; but they cannot be usefully lumped in with pirates or copyright abolitionists.
Re:Question (Score:4, Informative)
Deceptive simplicity is unwise. (Score:4, Informative)
Large corporations (which probably do way more business than you or whomever you're speaking for) don't have that problem. Reasonable business operators recognize that you should not be "confident to use" any software without complete understanding of the terms of the relevant licenses. This goes for any software license. In this way the new BSD license is deceptively simple and framing this issue as though it only affected the GPL is unfair.
Re:From the document... (Score:5, Informative)
You don't mean a "commercial" license. The GPL is a commercial license. Commerce is done with software licensed under the GPL. You mean something else, perhaps "proprietary".
In any event you haven't explained what is so bad about the GPL or that you understand the licenses you deal with (any of them) to warrant such trust in these other more permissive licenses or licenses you erroneously referred to as "commercial".
Re:Context people, context. (Score:3, Informative)
Re:Context people, context. (Score:4, Informative)
If software was written in English instead of programming languages, I think there would be less confusion.
The folks who should be concerned with software are ordinary folks; not programmers.
But of course, in reality, both of these matters are too complex to accurately express in standard English.
The GPL is a hack of the legal system with the goal of turning copyright upside down. That hack only works because it's written in legalese.
Re:From the document... (Score:2, Informative)
Dear Fermion:
If you trust a salesperson to spell out legal limitations, you are a fool.
More than likely, you aren't a fool, but are just working a little weekend overtime at Microsoft.
Am I right?
Re:Context people, context. (Score:5, Informative)
I agree that licences(and law in general) ought always to strive for clarity; but(as I'm sure you know from explaining tech stuff to non techies) real clarity often demands a certain amount of jargon. Concepts, whether they be "JIT Compiler", "Special Relativity", or "Derivative Work", can be glossed in English; but they cannot be fully described without reference to the technical terminology of their fields.
The GPL does pretty well, comparatively speaking, in being precise without being incomprehensible. Unfortunately, it has been forced to become more complex(the difference between version 2 and version 3 is striking) by factors outside of its control, mostly related to software patents, DRM/Tivoization, and technological advances that make the aggregation/derivative work boundary fuzzier.
No -- the GPL is not a usage license (Moglen) (Score:4, Informative)
> [as a user] would I be under any obligation to release the source code to the software I wrote?
No, as a user of GPL software, as opposed to a (re)developer or distributor, you do not engage any of the relevant conditions of the GPL with respect to provision of the source code.
As the ex-FSF's Eben Moglen has said on many occasions (paraphrased but close), "The GPL is not a usage license, but a distribution license". That's a very clearcut distinction, and Eben has written the book in this area.
There is a small corner case to watch out for, however, and that's static linking with GPL libraries --- a few people call this "derivation" despite the fact that you're only an end user and are only aggregating the GPL library functions statically with your code, so the issue is slightly grey. However, most linkage with GPL libraries is dynamic, and even Richard Stallman has conceded that legally, dynamic linking cannot ever be derivation but only mere usage. No doubt Eben put him straight on that. "Aggregation is not derivation" appears in the FSF's own explanatory materials.
On the whole then, the answer is "No, you're safe", unless you go out of your way to use static linking, which would open you up to the possibility of occasional arguments within the community, although probably not legal ones.
So what if it gets patented? (Score:3, Informative)
What if someone takes your code and patents a part of it? BSD then says you cannot claim the patent or protect yourself from it.
And patent law says you can't use your BSD code.
It therefore doesn't matter if you feel confident in obeying the BSD. Your feelings will not make a hill of beans difference. And you will be disallowed.
Re:No -- the GPL is not a usage license (Moglen) (Score:3, Informative)
I'm still very skeptical with regards to what you're saying, because if true, that would open the doors to reuse of GPL code in proprietary closed-source applications on an unprecedented scale. Most certainly that sort of thing would be picked as news of the day by more than one of websites, portals and blogs associated with Linux and OSS - Slashdot, Groklaw etc. Yet I do not recall seeing anything like that. Unless you're implying that FSF is deliberately trying to keep this below radar. Their web site still have numerous places where the claim is made that dynamic linking is derived work:
So, if what you say is correct, and FSF was advised by their lawyers that dynamic linking does not make a derived work, then they are now making deliberately false and misleading statements on their official website. Somehow, it seems rather doubtful.
Of course, you're welcome to prove me wrong, and provide some actual references. Why, this would probably make one of those 1000+-post Slashdot stories if true!