Slashdot Mirror
SFLC's Legal Guide On Free Software
An anonymous reader writes "Last week the Software Freedom Law Center published A Legal Issues Primer for Open Source and Free Software Projects. The primer, written for developers, has sections on copyrights, trademarks, patents, and organizational structure. Linux-Watch has reviewed the guide, saying 'I think any open-source developer or open-source group administrator must read this paper.'"
Surely the more information is available and easily-accessible (from an introduction point of view) the better, right?
I'm happy to see more resources aimed at educating developers. Particularly new ones.
This is the "free software" crowd! C'mon people! If it's any good at all they would charge for it! That is human nature! The more it cost the better it is! Sheesh! http://fakesteveballmer.blogspot.com/
But, legally speaking, you should read the license you pick. Don't just assume any summary is correct. I am not saying this summary is not accurate, I am just reminding you that you actually need to read what you "sign".
This issue is a bit more complicated than you think.
The parent poster's nick says it all. Truly a man of his convictions, this "AC" fellow.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
The Software Freedom Law Center, eh?
Personally, I wouldn't trust an organization whose four-word name is composed entirely of nouns.
You must be new here
Make SELinux enforcing again!
They will be like me, punk kids with big ideas in some godless bureaucracy, hacking away into the night on any computer available, moving stuff between home and work work and home. Not realizing the big bad wolf wants to eat up your ideas and 'monetize' or 'propertize' or 'utilize' or god knows what else. Anything but actually serve your customers/the public, which is what you were probably interested in.
Ok, if even one young punk kid reads this and goes about their business in a little wiser fashion, it will be worth it.
The content looks OK, but whatever app they used to convert from TeX to HTML not only produces ugly code that gives Frontpage a run for it's money, it also didn't close the <address> tag near the top, making the entire document right justified and italic.
Horribly broken HTML in a bunch of respects. Stick with the PDF version.
I was expecting to read a biased view toward the GPL, etc. Went straight to the BSD(-style) section and it's exactly what I found. Not about what the BSD(-style) licenses do/do not permit, but a commentary about what features of the GPL aren't in the BSD and how that's "good" "according to some people."
Gotta say that I've read a lot about licenses, etc and have yet to see one that isn't biased in one direction or another. And this is certainly no exception. I'd just love to see a commentary that keeps people's fucking politics out of it.
What I object to is the "you should ..." bits which indicate that the authors are suggesting courses of action. I'd rather just have the lawyers unwind the legalese and make it human readable and let me make the decisions as to what I should and should not do. This makes it feel like the authors have an agenda that they are pushing.
Engineering is the art of compromise.
In this case, the politics are the indirect reason. I think the writers (which were all part of the "FSF" cadre) are simply more knowledgeable about the GPL-style licensing than about BSD-style licensing. They have considerable experience and expertise drafting and enforcing the GPL and LGPL, but they have not been, for example, part of the AT&T-Berkeley BSD litigation. The discussion of copyright enforcement would have been more interesting if it included examples of successful enforcement of both the types of licenses.
The discussion of "copyright assignment" falls under the same heading: that's what the FSF does, and they are telling us what they learned about this kind of setup. Better they share their knowledge than leaving others to rediscover it.
I think the best way to view this document is as follows: "we are laywers, who have been helping FOSS projects. Here are some lessons we learned, in non-technical language. Read this before talking to your lawyer and you'll get more mileage out of him/her".
IANAL used to stand for "I Am Not A Lawyer". Now it's "I-read-an-article-and-so Am Now A Lawyer". Now I can finally tell /.ers what to do when their employer works them uber overtime without overtime pay!
(... the article did cover that, right?)
Some licenses (particularly long ones like the GPL v3) may need to be read many times, argued with many lawyers, etc. before one can even hope to have even a partial understanding of it....
IANALE
LedgerSMB: Open source Accounting/ERP
IANAL, so a lot of this is in the context of listening to a lot of other lawyers talk.
I think the document seems to be a reasonable summary of the concensus view in a lot of cases. I think it is a good read.
There are a few areas where I would prefer to see more detail (it is my understanding that prior to pursuing legal action for copyright infringement, one must register the copyrights but this may be different than enforcement as other forms of leverage may be applied in those cases).
One thing I thought was particularly well put forward was the patent section and the question as whether to apply for patents. The key thing I have heard from patent lawyers is that unless you intend to monetize an invention in a major way, it is not worth applying for a patent for the simple reason that patent enforcement is difficult and expensive.
LedgerSMB: Open source Accounting/ERP
There are a few areas where I would prefer to see more detail
Me too. Here is another such area where a key element is missing from the document.
In the section on the Affero GPL, these not-so-eminent lawyers failed to identify the key conceptual AND LEGAL difference between GPL and Affero GPL: that while all other FOSS licenses trigger at the point of distributing the work (because it's the copying that triggers copyright), the terms of the Affero GPL trigger on ***USAGE*** of the server-side software. Affero GPL is therefore a usage license.
Since there is no copying involved when users of a service use that server-side software remotely, copyright does not get engaged at all. This means that copyleft doesn't get engaged either (since copyleft is based on copyright), and that means that the Affero GPL is not a copyleft license when it is applied to server-side software. Instead it is a EULA controlling *usage* of a work. This sits extremely badly alongside Eben's common statement that the GPL is not a usage license. That's true for the GPL, but the Affero GPL is precisely that, a usage license by definition.
That is such a central and fundamental difference in concept with respect to FOSS copyleft licenses that it boggles the mind that the lawyers just glossed over it.
I haven't read it (YET!), but as legal issues mentioned on Slashdot tend to have a very US-centric perspective, and as I live outside the US, I'm curious as to how much of it will be applicable to me.
To be honest, I would say that all developers, even those who are firmly based in the US, need to be considering international law in this regard -- you may be based in the US, but your software will almost certainly end up all over the world.
(Spudley Strikes Again!)
I wrote this goal oriented guide for picking a free software license some years ago. It is slightly out of date (I would out suggest QPL anymore).
"If the BSD code is always going to be available under BSD then what's the problem? Nothing lost, nothing gained."
And yet when a similiar argument was applied to Tivo all hell broke loose.
It's still not incredibly helpful as it doesn't take into account international associations etc.
This is the internet, not a garage band.
I went right to the section that looked like it might explain the considerations in choosing GPL license options (2 vs 3 vs 2 or later vs 3 or later vs LGPL, etc.), and found it very disappointing. The relevant section starts with a mention of the two versions (2 and 3), but then drifts off into vague generalities about how you should consider a version of the GPL if you want to take advantage of GPLed code. They don't even mention the important and difficult issues having to do with the emergence of GPLv3, but seem to assume that the GPL is the GPL.
An Article in Slashdot telling us to RTFA? Not bloody likely.
It is quite true that forming a corporation you control may in various cases limit your personal losses from the results of the actions of others you employee (e.g. an employee does something wrong, so the only assets at risk are the corporations *and* the employee's for personal negligence, not yours). However, from discussing this issue myself with a non-profit lawyer, my understanding is that if *you* are the one writing the code, you remain personally liable for any problems it has even if you are totally working in good faith, like if you unknowingly infringe a software patent (good licenses can limit these liabilities somewhat). So I think this document is misleading in that it can be read to imply forming a corporation would protect the *author* of the code, when it really at best protects those who participate in the organization (board members) and who do not contribute code. For example, if you contribute problematical code to Apache, the Apache board may not be liable personally (even if Apache organization assets may be at risk), but you still are. So, in short, my understanding is that forming a corporation does not protect the individual contributors significantly from liability for their own personal actions, only from the actions of others (and even then, only when they are unaware of them or not directing them to various degrees). Perhaps they can address that issue in a future release; either indicating I am mis-informed or indicating that what I say is true. This is a very essentially point for individual developers to understand. It is one reason for liability insurance (and maybe the free software world could benefit by a good liability insurance system?) I think this is an important issue to get right, because otherwise it tempts free software developers (like myself) to spend a lot of time (and money) pursuing corporate forms which in the end may not provide much protection anyway for your personal efforts (compared to say, putting assets in the name of your spouse or having professional liability insurance). There may be other good reasons to form or join a non-profit though, but individual liability protection for the developer may not be one of them.
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
This is technically accurate but potentially dangerously misleading. For virtually all actual ways in which you are likely to want to enforce copyright, in the US at least, registration is a prerequisite for legal action.
Also, section 2.5 on "Copyright enforcement" skips over a rather critical area for a legal issues primer: the law. It focusses on knowing the license and its terms, and knowing the facts. It doesn't discuss much at all about the law which is necessary to understand how licenses apply to the facts. Now, for one audience that the piece is directed to (lawyers), this may be okay, since presumably the step of researching the applicable law isn't something they need to be told about (but then again, neither "gathering the facts" nor "knowing the license" are things that they should need to be told about, either.) For the other stated audience (developers, risk managers, etc.), though, this is a rather important point, and its kind of odd that "A Legal Issues Primer for Open Source and Free Software Projects" would skip over most of the legal issues almost entirely in the section on copyright, and be dangerously misleading on the one point where it does discuss the legal issues as opposed to the terms of particular available licenses. The Copyright section reads more as a primer on and promotion of the GNU Licenses and the FSF as a resource on the GNU licenses than a legal issues primer.
The rest of primer, OTOH, seems a bit more substantial.