Weekly Edition
Return to the Announcements page
| |||||||||||||
FSF: Announcing our license recommendations guide
Brett Smith of the Free Software Foundation has announced a license recommendation guide. "Today I'm happy to share something we've been working on for a little while: "How to choose a license for your own work" is a comprehensive set of license recommendations for new projects. This page explains what factors are important to consider when making licensing decisions, and suggests specific licenses for different scenarios. If you're starting a new project (whether it's software, documentation, or something else related) and unsure what license to use, you just need this one link to find our recommendations." (Bradley Kuhn has some comments on the recommendation site on his blog as well.)
(Log in to post comments)
FSF: Announcing our license recommendations guide Posted May 26, 2011 15:46 UTC (Thu) by iabervon (subscriber, #722) [Link]
This is a nice guide to why you might want to use different licenses. The only thing I'm a bit sad about is that it only entertains "competing against proprietary standards" as a reason to use a permissive license. I think it would be better to include other possibilities there; for example, it would be good if there were an SSL implementation under a permissive (and non-broken) license, such that everybody who needed SSL support used that and everybody who was concerned about the security of SSL implementations inspected it. Ask yourself: "If Microsoft used my code in the next version of Windows in order to provide some great new functionality to its users and didn't give me anything for it, not even credit, would I: (a) be upset or (b) be relieved that I don't have to cope with the buggy implementation they would have written themselves." If the answer is (b), you want a permissive license.
FSF: Announcing our license recommendations guide Posted May 26, 2011 16:07 UTC (Thu) by Trelane (subscriber, #56877) [Link]
> I think it would be better to include other possibilities there; for example, it would be good if there were an SSL implementation under a permissive (and non-broken) license, such that everybody who needed SSL support used that and everybody who was concerned about the security of SSL implementations inspected it.
Why would using a "permissive" (i.e. permits adding further restrictions on downstream users of the library) cause this scenario to be more likely than it would be were the library to use the LGPL?
FSF: Announcing our license recommendations guide Posted May 26, 2011 18:57 UTC (Thu) by iabervon (subscriber, #722) [Link]
Vendors that produced static-linked embedded system images can't use LGPL libraries. These vendors might include the company that makes your network provider's switch hardware, or a company that makes equipment used by a certificate authority that your browser trusts. With a permissive license, these vendors could use the code that open source developers have written and academic researchers have analyzed. It's essentially the same argument as to why libpng or a WebM implementation should be under a permissive license: it is better for the copyright holders if even companies which would not accept the LGPL use the code.
FSF: Announcing our license recommendations guide Posted May 26, 2011 19:07 UTC (Thu) by aleXXX (subscriber, #2742) [Link]
There are some projects which are offered under GPL/LGPL with an special additional exception, as e.g. eCos (a free RTOS): http://ecos.sourceware.org/license-overview.html
or also Qwt: http://qwt.sourceforge.net/qwtlicense.html
Alex
FSF: Announcing our license recommendations guide Posted May 26, 2011 19:30 UTC (Thu) by ballombe (subscriber, #9523) [Link]
In this instance, this is not a very good argument: if a bug is found in the SSL library, the ability for the user to update it without having to wait for the vendor is very important. The LGPL does not require static linking, only the ability to update the library.
FSF: Announcing our license recommendations guide Posted May 26, 2011 19:45 UTC (Thu) by Trelane (subscriber, #56877) [Link]
> With a permissive license, these vendors could use the code that open source developers have written and academic researchers have analyzed.
And they can mutate it without allowing further analysis.
FSF: Announcing our license recommendations guide Posted May 27, 2011 14:09 UTC (Fri) by vonbrand (subscriber, #4458) [Link] The vendor can legally change the code without analysis, if the license is BSD or GPL is completely irrelevant.
FSF: Announcing our license recommendations guide Posted May 27, 2011 19:27 UTC (Fri) by jthill (guest, #56558) [Link] It's very relevant. With the GPL, they have to show their changes.
FSF: Announcing our license recommendations guide Posted May 26, 2011 19:03 UTC (Thu) by xtifr (subscriber, #143) [Link]
Only possibly if the downstream users are unnecessarily paranoid about anything with "GPL" in the name, or even simply put off by the complexity of the license, both of which, unfortunately, are possibilities that cannot be entirely dismissed.
The complexity issue is the main reason that I still keep the BSD or MIT licenses in my bag o' licensesalthough those are the only ones not mentioned that I'd consider for my own works.
FSF: Announcing our license recommendations guide Posted May 27, 2011 6:02 UTC (Fri) by oldtomas (guest, #72579) [Link]
There's definitely a place for MIT, BSD and all of them. And they are way simpler than any of the GPLs. Still: have you ever read through a proprietary license?
For me, it's hard to believe that someone accepting proprietary licenses dismisses any of the GPLs as "too complicated": I'm convinced that this is a red herring (or they don't read what they sign).
Of course, a radical BSD person, not accepting any proprietary license would have a convincing point.
FSF: Announcing our license recommendations guide Posted May 27, 2011 0:00 UTC (Fri) by rahvin (subscriber, #16953) [Link] Ask yourself: "If Microsoft used my code in the next version of Windows in order to provide some great new functionality to its users and didn't give me anything for it, not even credit, would I: (a) be upset or (b) be relieved that I don't have to cope with the buggy implementation they would have written themselves." If the answer is (b), you want a permissive license.The problem with the permissive license is EEE (Embrace, Extend, Extinguish). It's appropriate that you would use Microsoft in your scenario as they would be the most likely to use the code, extend it with proprietary extensions to provide vendor lock-in then over time and eventually extinguish the entire ecosystem. Just look at what they did with Active Directory, they took open standards put proprietary undocumented extensions on them and used it as a weapon in the marketplace. At least with the GPL they have to tell you how they broke the system.
FSF: Announcing our license recommendations guide Posted May 26, 2011 16:42 UTC (Thu) by josh (subscriber, #17465) [Link]
This guide comes *so* close to providing a helpful and accurate guide, right up until the point where it recommends the GFDL for documentation. It makes the right recommendation for other data: use the same license as the program unless you have a good reason to do otherwise. Unfortunately, it doesn't even suggest that as a viable alternative for documentation.
gfdl Posted May 26, 2011 18:29 UTC (Thu) by coriordan (guest, #7544) [Link]
It was to be expected. The GFDL is GNU's licence for documentation, so it would be strange if they didn't see it as the best licence for this purpose.
To solve the problem, RMS has to be convinced to remove the invariant sections problem (plus other more minor problems) from the next version of the GFDL.
gfdl Posted May 26, 2011 21:29 UTC (Thu) by pboddie (subscriber, #50784) [Link]
There was some draft of the "Simpler FDL" I remember commenting on (suggesting that for images made from vector artwork, the "source" is the vector file - something that probably wasn't stipulated in the draft or in other such licences), but I think the FSF postponed doing any more work on it.
gfdl Posted May 26, 2011 21:54 UTC (Thu) by foom (subscriber, #14868) [Link]
The only way the GFDL can ever be a good choice for the license of the documentation of a GPL'd program is if it's GPL-compatible. There are some entertaining threads on the gcc mailing list about how the GFDL/GPL license incompatibility causes issues.
gfdl Posted May 27, 2011 20:14 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] Yes, there are major difficulties because of the use of doxygen to generate documentation for the standard C++ library, plus the existence of a GFDL manual for the library. The only way to maintain this is to, in essence, have two manuals.While it's possible to get the FSF to approve moving text from one to the other, it creates a situation where end users who try to do the same are violating the license, and if GCC shipped scripts to automatically integrate information extracted from source files into a manual containing GFDL text, if changes were made by third parties the result might be illegal to distribute (or even to print out!). So it's a big hairy legal mess. It's currently dealt with by treating the doxygen documentation and the libstdc++ manual as separate documents; the former is LGPL and the latter is GFDL. It's a big PITA. Change might come eventually, but typically what happens in these cases is that any proposed text gets run past lawyers and is thought about for a year, and ideas are proposed for *further* license changes that tend to alarm users, and did I mention that I hate legal issues?
gfdl Posted May 27, 2011 15:31 UTC (Fri) by josh (subscriber, #17465) [Link]
I don't particularly care if the GFDL gets fixed; I just wish that in the common case where the work has no Invariant Sections, Cover Texts, and so on, that the FSF would consider the GPL equally reasonable for documentation.
FSF: Announcing our license recommendations guide Posted May 27, 2011 2:50 UTC (Fri) by yarikoptic (subscriber, #36795) [Link]
Moreover the catch in "GPLv3, LGPLv3, AGPLv3, and GPLv2 can all be applied to any kind of worknot just softwarethat is copyrightable" is the word COPYRIGHTABLE... and data in many jurisdictions is not copyrightable ATM AFAIK. That is why such new license-like beasties were born as CC0 and PDDL were born. AINAL, just absorbing what I saw/was told. Relevant links:
http://bibwild.wordpress.com/2008/11/24/creative-commons-...
FSF: Announcing our license recommendations guide Posted May 27, 2011 8:55 UTC (Fri) by njwhite (subscriber, #51848) [Link]
I release some very small scripts and other simple things which may be not copyrightable. In situations where I'm not sure, I just give them a small license (generally ISC) and accept that if it isn't copyrightable, then the license is irrelevant.
For things which copyright may not apply to, it's better to apply a permissive license, if it turns out to apply that's great, and if not nevermind.
FSF: Announcing our license recommendations guide Posted May 27, 2011 10:43 UTC (Fri) by HenrikH (guest, #31152) [Link]
If copyright does not apply to the work, how do you intend to enforce the license? If it's not copyrightable then it's public domain and needs no license what so ever.
GPL'ing works of dubious copyrightability Posted May 27, 2011 12:07 UTC (Fri) by coriordan (guest, #7544) [Link]
Well, you can stick a GPL on your work, and if some court (now or 50 years in the future when the copyright landscape is very different) thinks your work is copyrightable, then the user has the permissions of the GPL, and if it's not copyrightable, then it's public domain (and so is loads of other stuff, yay).
win-win, no?
GPL'ing works of dubious copyrightability Posted May 27, 2011 12:58 UTC (Fri) by yarikoptic (subscriber, #36795) [Link]
As I was told, blunt assignment of copyright+license to uncopyrightable works, could also be treated by some as a "CopyFraud": http://en.wikipedia.org/wiki/Copyfraud , which would "illegally" try to limit the use of the material.
And copyright is not the only way to protect the ownership/rights, e.g. there are also "intellectual property" regulations. E.g. in Europe for data there is the sui generis database right under the national law implementing the European Database Directive: http://en.wikipedia.org/wiki/Database_right
A related email correspondence: http://lists.ibiblio.org/pipermail/cc-community/2011-Janu...
GPL'ing works of dubious copyrightability Posted May 27, 2011 13:09 UTC (Fri) by yarikoptic (subscriber, #36795) [Link]
and forgotten.... please correct me if I am wrong (AINAL and all that):
public domain deposition is not trivial either because it varies across jurisdictions. E.g. in the USA there is a handful of ways how things could appear in "public domain", e.g. expired copyright (thus work was copyrighted initially) or work of USA government, etc. But at the end public domain in USA might be not public domain world-wide. That is yet another reason for those "flexible" CC0s etc.
GPL'ing works of dubious copyrightability Posted May 27, 2011 20:38 UTC (Fri) by Wol (guest, #4433) [Link]
The work of the US government is NOT public domain.
Look at the law carefully. The US Government cannot use the US courts to enforce copyright! That is NOT the same as public domain.
In other words, if I take US government material, the US government could quite conceivably sue me for breach of copyright in the High Court. Unlikely, but definitely possible ...
Cheers,
GPL'ing works of dubious copyrightability Posted May 29, 2011 19:33 UTC (Sun) by bfields (subscriber, #19510) [Link] I didn't know that, weird; another reference: http://www.cendi.gov/publications/04-8copyright.html#317
Data usaualy *is* copyrightable Posted May 27, 2011 14:20 UTC (Fri) by dps (subscriber, #5725) [Link]
IANAL but known that just about anything can be subject to copyright, including some bits of German landscape---which, to be fair, were being misrepresented as lots of other places.
If data really were not subject to copyright CC licences would be irrelevant: everybody would have the rights the CC licence grants them anyway. At least in the EU you get exclusive rights to copy, authorise the making of copies, perform, etc automatically. There are wrinkles, not limited to but including fair use, but just coping somebody else's data is not allowed.
Forms of data which are frequently copied include music, although in this case the companies need to realise that suing your customers is a sure way of losing in the longer term.
Data usaualy *is* copyrightable Posted May 27, 2011 14:30 UTC (Fri) by yarikoptic (subscriber, #36795) [Link]
;-) contra-example brought up by Philippe Bradley on http://lists.ibiblio.org/pipermail/cc-community/2011-Janu... :
to quote IP + tech specialist barrister, Francis Davey:
So, not quite everything is copyrightable... moreover from http://en.wikipedia.org/wiki/Database_right
United States
Uncreative collections of facts are outside of Congressional authority under Article I, § 8, cl. 8, i.e. the Copyright Clause, of the United States Constitution, therefore no database right exists in the United States. The sine qua non of copyright, in the United States, is originality. (see Feist Publications v. Rural Telephone Service). This has not stopped database owners lobbying for the introduction of such a right, but so far bills to introduce it in the U.S. have been prevented by the successful lobbying of research libraries, consumer groups and firms who benefit from the free use of factual information.
FSF: Announcing our license recommendations guide Posted May 27, 2011 11:06 UTC (Fri) by alfille (subscriber, #1631) [Link]
Not much meat in these recommendations. Not surprisingly, the FSF suggests using GPL first and foremost.
So who is the target of this guide? If I were naive about licenses, this guide wouldn't have enough explanation to be at all compelling. And experienced open-source will find nothing new.
I know I could follow the links, but that misses the point. Add a BRIEF rationale. something like:
"We recommend you use the GPL because it allows use of your work while encouraging a community to build around it and contribute back."
|
|||||||||||||