Weekly Edition
Return to the Development page
| ||||||||||||||||
Samba Adopts GPLv3 for Future Releases
Samba adopts GPLv3 for future releases. --------------------------------------- After internal consideration in the Samba Team we have decided to adopt the GPLv3 and LGPLv3 licences for all future releases of Samba. The GPLv3 is the updated version of the GPLv2 license under which Samba is currently distributed. It has been updated to improve compatibility with other licenses and to make it easier to adopt internationally, and is an improved version of the license to better suit the needs of Free Software in the 21st Century. To allow people to distinguish which Samba version is released with the new GPLv3 license, we are updating our next version release number. The next planned version release was to be 3.0.26, this will now be renumbered so the GPLv3 version release will be 3.2.0. To be clear, all versions of Samba numbered 3.2 and later will be under the GPLv3, all versions of Samba numbered 3.0.x and before remain under the GPLv2. The Samba Team would like to thank Richard Stallman, Eben Moglen and the Free Software Foundation for updating the GPL license, and also all the individuals and corporations involved in helping to create the GPLv3. We feel this is an important change to help promote the interests of Samba and other Free Software. The Samba Team. http://samba.org http://www.gnu.org/licenses/gpl.html http://news.samba.org/announcements/samba_gplv3 FAQ: What about code submissions ? Does anything change ? ---------------------------------------------------- New code contributions will be accepted in exactly the same way as before. As Samba has always accepted code with the "or (at your option) any later version" of the GPL, contributors do not need to change anything about their submissions. I need to ship 3.0.x for several years as part of a service contract. What about old versions ? --------------------------------------------------- As with previous major version changes, the Team will continue to provide security fixes for 3.0.25b releases for as long as this code base is widely used. All new features will only be developed for the new 3.2.x or later GPLv3 versions however. Help ! I've read scary things about the anti-DRM, language in GPLv3 ? What does this mean for my Samba-based products ? ---------------------------------------------------------- We're not aware of any vendor distributing Samba in such a way that would cause them to fall foul of the new DRM language in the GPLv3, but as always, consult legal advice if you have doubts. I am the author of a GPLv2 licensed program, can I still use the samba libraries? --------------------------------------------------------------------- The Samba Team releases libraries under two licenses: the GPLv3 and the LGPLv3. If your code is released under a "GPLv2 or later" license, it is compatible with both the GPLv3 and the LGPLv3 licensed Samba code. If your code is released under a "GPLv2 only" license, it is not compatible with the Samba libraries released under the GPLv3 or LGPLv3 as the wording of the "GPLv2 only" license prevents mixing with other licenses. If you wish to use libraries released under the LGPLv3 with your "GPLv2 only" code then you will need to modify the license on your code. What about patent covenant agreements ? How do they affect the distribution of Samba ? --------------------------------------------------- Patent covenant deals done after 28 March 2007 are explicitly incompatible with the license if they are "discriminatory" under section 11 of the GPLv3. Samba distributors who have made such patent covenant agreements after that date will not have the right to distribute any version of Samba covered by the GPLv3 (Samba 3.2 or later). The rights of vendors to ship 3.0.25b and previous versions is unchanged and remains as it was under the GPLv2. Consult legal advice if you are in doubt. (Log in to post comments)
Samba team, thank you! Posted Jul 9, 2007 20:24 UTC (Mon) by atai (subscriber, #10977) [Link] Samba, go!
Can't use with GPLv2 under LGPLv3? Posted Jul 9, 2007 21:37 UTC (Mon) by sepreece (subscriber, #19270) [Link] "If your code is released under a "GPLv2 only" license, it is not compatible with the Samba libraries released under the GPLv3 or LGPLv3 as the wording of the "GPLv2 only" license prevents mixing with other licenses."
Umm - doesn't the GPLv2's system-library exception allow such use, if the LGPLv3 library is provided by the OS?
Can't use with GPLv2 under LGPLv3? Posted Jul 9, 2007 22:22 UTC (Mon) by Los__D (guest, #15263) [Link] Do you mean this part? However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
I really can't see how that is related. That just exempts you from having to distribute the source of the components, it doesn't free you from it's terms. You would still not be allowed to link to LGPLv3 libs from a GPLv2 program.
Can't use with GPLv2 under LGPLv3? Posted Jul 9, 2007 22:41 UTC (Mon) by sepreece (subscriber, #19270) [Link] Can you explain why you wouldn't be allowed to? The quoted exception allows you to link with libraries provided by the platform, regardless of their license and the LGPLv3 allows linking with material under any license (under certain conditions), so where's the blockage?
Read the last sentence of that paragraph Posted Jul 10, 2007 0:07 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] The GPLv2 text says:However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable (emphasis mine). That means that a distro cannot include both the GPLv2-only app and the LGPLv3-or-later library, packaged so that the former uses the latter: you can't ship them together. The exception was for GPLv2 programs using proprietary C libraries, so it's written narrowly; it's caused problems for "GNU/Solaris" distributions. As it turns out, GPLv3 is more permissive in this regard.
Can't use with GPLv2 under LGPLv3? Posted Jul 10, 2007 13:45 UTC (Tue) by jamesh (guest, #1159) [Link] The system library exception essentially says that it is okay to distribute binaries of a GPL'd programs even if they link against system libraries that would not themselves be distributable under the GPL.
However, this would not really help you if the system library had a license that did not give permission to link against GPL'd programs.
So this would be a problem if you had a GPLv2-only application linking against the GPLv3 libsmbclient, as the application code is incompatible with libsmbclient's license.
Can't use with GPLv2 under LGPLv3? Posted Jul 9, 2007 23:34 UTC (Mon) by tbrownaw (guest, #45457) [Link] Perhaps they don't think that Samba is (part of) a "major component" of the OS (which OS?)?
Can't use with GPLv2 under LGPLv3? Posted Jul 10, 2007 5:18 UTC (Tue) by khim (subscriber, #9252) [Link] You are talking about this, right: "As a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable" ? You can not distribute GPLv2 program and LGPLv3 library on the same CD (exception only works if they are distributed separately - read the "special exception" carefully)...
Can't use with GPLv2 under LGPLv3? Posted Jul 10, 2007 13:37 UTC (Tue) by sepreece (subscriber, #19270) [Link] Actually, the exception is for things that are normally distributed *with* a major component and the "unless" is about the component itself. Examples would be a library that normally accompanies a compiler versus the compiler itself. So, you presumably could distribute a GPLv2 program with a GPLv3 version of a library that normally accompanies the compiler, so long as you didn't also include the compiler itself.
Also, the "mere aggregation" clause provides another exception, so long as the library is not "a work based on the program" and is not combined (linked) into the program to form a work based on the program.
[Also, I suppose the copyright holder for a program could ship a GPLv2 program with a GPLv3 library, because such conveying does not rely on the terms of the license. However, a downstream recipient would not have the same freedom, making the use of a free license somewhat meaningless...]
Can't use with GPLv2 under LGPLv3? Posted Jul 10, 2007 8:21 UTC (Tue) by Jel (guest, #22988) [Link] Didn't RMS say that GPLv3 is merely a clarification of GPLv2, and the samemeaning was intended all along? So, they should be compatible. Does the license literally prohibit use with ANY other license, including other versions of the GPL?
I mean, don't get me wrong: I think it's GOOD that GPLv2-licensed projects
Can't use with GPLv2 under LGPLv3? Posted Jul 10, 2007 8:57 UTC (Tue) by Los__D (guest, #15263) [Link] The same meaning is intended ("Don't take away people's rights to this software"), but since there has been found more ways to do so, more restrictions has been added, so they can't be compatible, unless you kept the "or later" part to GPLv2.
Can't use with GPLv2 under LGPLv3? Posted Jul 10, 2007 15:57 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] RMS and the FSF have long recommended that people license their software "GPLv2 or later". Those who did this have no problem. But people who said "GPLv2 only" explicitly rejected GPLv3. This means that they cannot link their code to GPLv3 or LGPLv3 code, unless they drop their rejection first by changing the license.
Samba Adopts GPLv3 for Future Releases Posted Jul 9, 2007 23:15 UTC (Mon) by NightMonkey (subscriber, #23051) [Link] Is this the first major F/OSS project to switch?
If it is, then congratulations, Samba and FSF, on licensing where no one has licensed before. ;)
A number of small projects have switched Posted Jul 10, 2007 0:09 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] Many of the GNU utilies have switched to GPLv3 (programs like GNU tar and such).
Fork ahead...? Posted Jul 10, 2007 0:50 UTC (Tue) by dfsmith (guest, #20302) [Link] IANAL but....
Samba ships with more than a handful of commercial products. These products were developed by companies that probably own a patent or two to protect those products. And they're also the companies that will do extensive testing of Samba. (I don't have any first-hand data on the proportion of bug/feature-updates to Samba from commercial vs free developers.)
So we may see a fork in Samba's development track, as companies using Samba-GPLv2 pump dollars into that, while the Samba-GPLv3 version is stuck in academia.
It will be interesting to see which version develops faster! (I know which one I'll be forced to hack on.)
Fork ahead...? Posted Jul 10, 2007 1:27 UTC (Tue) by proski (subscriber, #104) [Link] Ever heard of Rewind? It was a fork of Wine under MIT license started after Wine switched to LGPL. Rewind is pretty much dead now.The problem with companies is that they have a short attention span and don't cooperate with each other. On the other hand, there are always some independent developers full of ideas and energy for every project worth its bytes. Generally, they tend to contribute to the code that is better protected against misappropriation.
Fork ahead...? Posted Jul 10, 2007 7:35 UTC (Tue) by dwalters (subscriber, #4207) [Link] "So we may see a fork in Samba's development track, as companies using Samba-GPLv2 pump dollars into that, while the Samba-GPLv3 version is stuck in academia." Nah. Any fork of Samba is doomed to fail in my opinion. Ultimately only the Samba team has the right combination of experience, talent and motivation to move the product continuously forward.
Fork ahead...? Posted Jul 10, 2007 13:20 UTC (Tue) by mbottrell (guest, #43008) [Link] It will be forked, and will fail.
I love the idea of companies taking other peoples code, the add little chunks and expect they don't need to put them back into the collective.
Same appears with that of Joomla... all these 'professional developers' crying foul...
Unfortunately you business model is flawed... and thus the pain you feel.
Either develop commercially from scratch, or setup an OSS company. No-one is stopping these commercial entities selling Samba services/support. Try making ya money there, then 'stealing' from the OSS community and adding some fluff on top.
Fork ahead...? Posted Jul 10, 2007 15:19 UTC (Tue) by sepreece (subscriber, #19270) [Link] I agree that there are few examples of projects that have forked and succeeded. However, subcommunities do exist and there is nothing inherently wrong with a group of developers (or companies) deciding to form a new community with slightly-but-significantly different principles. The viability of that community would depend on whether enough people were interested and whether they were the right people.
The current situation is interesting from that perspective. It's quite possible to be willing to share openly within an open community, but NOT to feel the need for the GPLv3's additional restrictions. I think there is the potential for certain key projects to end up with two lively communities around them, based on different licenses. Or, it could be that communities with enough internal disagreement about licensing will simply elect to remain "GPLv2 or any later" and avoid the fight.
We'll see...
Fork ahead...? Posted Jul 10, 2007 15:59 UTC (Tue) by amikins (guest, #451) [Link] Yeah, the discussion so far seems to assume a fork would be for the purposes of avoiding freedom or avoiding responsibility to contribute back to the community. Why is it so implausible that a community might not like the GPLv3, but still wants to collaborate?After all, the Linux kernel is just such a community.
Fork ahead...? Posted Jul 10, 2007 16:30 UTC (Tue) by khim (subscriber, #9252) [Link] Linux (BusyBox and few other projects) are special cases. GPLv3 was rejected way in advance. Because it's always possible to switch from "GPL v2 or later" to "GPL v3 or later" but it's not possible to switch back patches will have the tendency of flowing one way. The situation is somewhat similar to "GNU Emacs" vs "X Emacs" (different reasons, the same outcome). It's hard to support "v2" project in this state, it's even harder to support "v2 or later" project and it's especially hard to support project when you are forking it without support of core developers. In the end few "GPLv2 only" forks will succeed (if backed by significant percentage of core developers), but most will fail. "v2 only" projects are more robust but there are also quite real possibility that someone will create GPLv3 replacement (yes, even with Linux kernel - it depends on aggressiveness with which MS & Co will use GPLv2 loopholes).
Fork ahead...? Posted Jul 10, 2007 17:57 UTC (Tue) by amikins (guest, #451) [Link] I think it also depends on the viability of those loopholes. Aggressive attempts to exploit that fail only strengthen the license.
I do see your point about the one-way nature of code flow, though.
Fork ahead...? Posted Jul 10, 2007 20:35 UTC (Tue) by sepreece (subscriber, #19270) [Link] Which side of the fork flourishes, and where the patches are developed, will depend on the specifics of which existing developers follow which side of the fork and which side is favored by new developers. You can't just assume that the v3 side would be the one that "wins" the competition for developer minds.
Fork ahead...? Posted Jul 10, 2007 16:48 UTC (Tue) by proski (subscriber, #104) [Link] The community will likely to stay with the developers, whether they prefer GPLv2 or GPLv3. GPLv3 would have to be quite obnoxious for the community to embrace a fork. We'll see, but my feeling is that GPLv3 is not so bad as e.g. the license that caused a fork in XFree86 a couple of years ago.
Fork ahead...? Posted Jul 10, 2007 15:56 UTC (Tue) by vmole (guest, #111) [Link] Well, those companies have been working with a GPL2 Samba, not a BSD Samba. So if their current usage and distribution is legal, then it's unlikely that GPL3 Samba will be a problem. Most of the commercial products that ship Samba use it as a component, and provide nifty (or not) proprietary frontends for configuration and monitoring. GPL3 doesn't prevent that.
Fork ahead...? Posted Jul 10, 2007 23:49 UTC (Tue) by dfsmith (guest, #20302) [Link] Read GPLv3 section 11 para. 2--3.
By the wording, the following (hypothetical situation) is arguable.
I make a box with some whizzy patented feature (that I invested many $ into), that I can turn on by adding a line to the Samba code. I have to distribute the modified Samba---no problem. But para. 3 says I now have to grant "non-exclusive, worldwide, royalty-free patent license" for that patent.
Now any other company is licensed to our (hardware) patent. This greatly reduces the value of it. (And the Chinese can surely undercut our hardware and development costs.) This is not very attractive (except to those industrious Chinese, of course).
One can fairly argue that we wouldn't have a product at all without Samba. But I would also argue that GPLv3 Samba would lose valuable developer testing in this situation, possibly to its detriment. The question is, just how valuable is that developer time?*
* The comments above would indicate "not very". In which case v3 may flourish.
Fork ahead...? Posted Jul 12, 2007 14:54 UTC (Thu) by emk (subscriber, #1128) [Link] Well, the scenario you describe would almost certainly run afoul of the GPLv2, because your patent would restrict the rights of downstream users of the software. There has been quite a bit of discussion on this topic, and there's also explicit patent-related language in GPLv2 that covers other cases. Really, the only change in GPLv3 is that a couple of tricky loopholes dreamt up by Microsoft have been fixed, and that everything is much more explicit.
Fork ahead...? Posted Jul 12, 2007 14:55 UTC (Thu) by drag (subscriber, #31333) [Link] You snipped some pretty important things out of your quotes there.
When you cliped "non-exclusive, worldwide, royalty-free patent license" you realy ment "Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.", right?
Because there is a huge difference.
Anyways your mythical hardware patent has nothing to do with the software. Hardware is hardware and software is software; seperate things. Your granting license to use that software, not to anything else. The hardware your providing is unaffected by the software license, so your patent is safe.
That's also assuming that the Chinese give a crap about patents, which they don't.
What they will do is take your patented ideas, violate your patents. They will sell the hardware in countries that do not honor U.S. patents, and thus are completely isolated from any U.S. patent law. Because of the lack of need to pay for patents and such they will undercut competing hardware coming out of the USA.
Then they will use the profits from these sales to then turn around and hire lawyers in the U.S. to setup a legal entities (aka patent trolls) to buy new patents from the government, which you would have to pay for, since your based out of the U.S.
This, combined with the legal overhead you have to deal with on a day to day basis related to all this crap, will have considurably higher expenses then your chinese friends, who are happily putting you out of business.
Good luck trying to get the government to risk billions in dollars worth of agricultural exports with China, and the livelihoods of hundreds of thousands of (very politically active) midwest farmers, as well as other billions of dollars in trade in order to get in a trade dispute with China to help defend your little NAS business from that evil (mostly state-owned, mind you) chinese corporation (who probably already makes the majority of the parts you use in your product anyways).
Not likely or well advised. Posted Jul 10, 2007 16:30 UTC (Tue) by leoc (subscriber, #39773) [Link] Many core samba developers, testers and users work for corporations that benefit immensely by its mere existence (IBM, Novell, Red Hat, Google, etc). So it is far more likely that any forks of the core code would be largely ignored by mainstream users.
Not likely or well advised. Posted Jul 10, 2007 18:32 UTC (Tue) by drag (subscriber, #31333) [Link] If you look at the makup of the main Samba developer's you'll see that although the code is used by EVERYBODY the contributions back are actually kinda small.
There is very very little chance of Samba forking and about nill chance of anything succeeding. The few core Samba developers pretty much do all the work and they all are in agreement in this case.
|
||||||||||||||||