| |||||||||||||
GPLv3GPLv3Posted Apr 20, 2009 22:49 UTC (Mon) by pboddie (subscriber, #50784)Parent article: Oracle: SELECT * FROM Sun
If Oracle wants to put the cat among the pigeons it could license OpenSolaris under the GPLv3. That might turn heads and shake up the allegedly relatively stagnant OpenSolaris scene.
(Log in to post comments)
GPLv3 Posted Apr 21, 2009 2:00 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
Why do you think so? Switching to GPLv3 wouldn't really do anything about the primary issue people have with OpenSolaris's licencing, ie the fact that it's incompatible with the Linux kernel's. It might be enough to cause some GPLv3 advocates to change focus, but I don't really see it causing any major shift in the market. Switching to GPLv2 would be more interesting, but even then I suspect that the most likely outcome would be rapid asset stripping of anything useful from Solaris into Linux. Much as it may irk me that Sun deliberately chose a Linux-incompatible licence for OpenSolaris, it still seems that it was the only way to maintain any sort of relevance.
GPLv3 Posted Apr 21, 2009 3:26 UTC (Tue) by shieldsd (subscriber, #20198) [Link]
If Oracle relicenses Solaris under GPLv3 then within a matter of months every part of Solaris that could strengthen Linux will be incorporated into Linux.
GPLv3 Posted Apr 21, 2009 3:33 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
Except for the bits in the kernel - the Linux kernel is GPLv2 only, not GPLv2 or later. You can't combine GPLv2 and GPLv3 code. And, really, who'd want the Solaris userspace?
GPLv3 Posted Apr 21, 2009 8:07 UTC (Tue) by nix (subscriber, #2304) [Link]
You mean you don't want a grep that dumps core if you use too many
alternations? Whyever not?
;)
GPLv3 Posted Apr 21, 2009 14:00 UTC (Tue) by jordanb (guest, #45668) [Link]
And still.. in the 21st century, can't operate recursively.
GPLv3 Posted Apr 21, 2009 13:31 UTC (Tue) by jengelh (subscriber, #33263) [Link]
Linus has left open the decision to (try to) move to a later GPL version. (It will still be a legal tough job to find all people, tho.)
GPLv3 Posted Apr 21, 2009 21:22 UTC (Tue) by csamuel (✭ supporter ✭, #2624) [Link]
[Sigh - ENOCOFFEE.. meant to be following on from the comment on finding
all contributors and say]
..especially the dead ones.. :-(
GPLv3 Posted Apr 23, 2009 3:02 UTC (Thu) by jamesh (guest, #1159) [Link]
If a developer dies, then the copyrights would be passed on to their heirs. It'd still be possible to change the license, but the new copyright holder might not be as interested.
GPLv3 Posted Apr 23, 2009 8:39 UTC (Thu) by paulj (subscriber, #341) [Link]
So has anyone ever asked an actual lawyer about this? If a large project with very widely distributed ownership, makes every reasonable effort to locate its current owners as well as to widely publicise a pending licence change, and if years later a very small percentage of copyright holders crawl out of the wood-work and object, would a judge really rule in favour of those few, against the thousands?
I don't know the answer, but the implied answer assumed all the time by Linux kernel folk seems to take it as given that the courts would be surprisingly unpragmatic.
GPLv3 Posted Apr 30, 2009 9:08 UTC (Thu) by forthy (guest, #1525) [Link] It is only necessary to find those copyright owners who explicitely said they were only supporting GPLv2. The "GPLv2 only" tag in the COPYING file from Linus is only telling you that "the whole work is GPLv2 only by least common denominator". AFAIK, all GPLv2-only proponents are vocal and easy to track down. Large parts of the kernel are GPLv2 or later, and so can be changed to GPLv3 without asking the copyright holders of those parts (e.g. the ALSA team). Of course it is a lot easier to switch to GPLv3 or later if you were GPLv2 or later before. Been there, done that. Simply changing the COPYING file is sufficient.
GPLv3 Posted Apr 30, 2009 10:40 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
No - given that the default assumption in the kernel is that it's GPLv2, it's the ones who explicitly say GPLv2 or later who are the exception. Patches to any files that are v2 only are also v2 only. Large parts of the kernel may be v2 or later, but the majority is v2 only. It follows that you have a large number of copyright holders to find.
It'll be the other way Posted Apr 21, 2009 7:38 UTC (Tue) by khim (subscriber, #9252) [Link] You can not incorporate bits from GPLv3 Solaris in Linux. You CAN incorporate bits of Linux in GPLv3: if you'll actually bother to check you'll find out that surprisingly high number of files in Linux is licensed "under GPLv2 or later". Some core files are licensed under "GPLv2 only", but these are not really suitable for Solaris: architecture is too different, so this switch is logical - I don't know why Sun decided against it...
It'll be the other way Posted Apr 21, 2009 8:45 UTC (Tue) by job (guest, #670) [Link]
I agree. Opensolaris could really use some hardware support from Linux. Not so much the other way around.
It'll be the other way Posted Apr 21, 2009 11:34 UTC (Tue) by pboddie (subscriber, #50784) [Link]
It's nice to see that somebody gets my point, here. There would have been a number of advantages, both pragmatic and ideological had Sun adopted GPLv3 for OpenSolaris upon the finalisation of that licence, notably the strengthened patent language in the licence compared to GPLv2 (which recent events show to be moderately useful, even if Sun arguably wanted to sit on the fence with regard to their own patents), and as already noted, the ability to adopt GPLv2-or-later-licensed code from Linux, thus addressing one of the largest and longest running complaints about Solaris on x86 when compared to the Free UNIX variants: hardware and driver support.
It'll be the other way Posted Apr 21, 2009 14:01 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
Something like a third of the files under drivers/ are under an "or later" license, but ignoring the irrelevant (things like MCA drivers, other code mostly aimed at dead hardware, embedded drivers for platforms Solaris doesn't support, drivers for hardware Solaris already supports and so on) you basically end up with some sata and scsi drivers, a bunch of v4l code and some wireless drivers. And, in a lot of the more useful and relevant of these cases, there's already support in the BSDs that could be used without having to change the license.
The rest of the code is under pure GPLv2, and in many cases that includes infrastructure code that's relied upon by some of the "or later" drivers. You'd need to implement chunks of Linux's driver API while demonstrating that you hadn't copied any code from Linux, so that would immediately require a clean room reengineering effort. The alternative would be to port every one of the drivers you're interested in, and if you're making the argument that there's a sufficiently large body of drivers for Solaris to benefit from a license change then that would also be a lot of work.
So no, I don't see Solaris gaining any significant benefit by changing the license to GPLv3. It'd just end up looking like a petty "We're happy to take your code, but you don't get any of ours" move.
It'll be the other way Posted Apr 23, 2009 11:23 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
Why would you need a cleanroom approach? Linux isn't proprietary. It doesn't implement trade secrets. You only have to worry about accusations of plagiarism, effectively.
The reason BIOSes and such needed cleanroom reimplementations was due to the fact they were covered by copyright *and* trade secret laws. You need independent reinvention to prove you didn't steal trade secrets, and to argue against copyright infringement in cases where the resulting code ended up being the same.
But, since you have the GPL code right there, you can ensure your reimplementation isn't the same as the original except for the most trivial subsets of code. And you don't have to worry about trade secrets. There are none in publicly available code by definition.
It'll be the other way Posted Apr 23, 2009 13:35 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
Clean-room reengineering has nothing to do with trade secrets. Trade secrets are protected by NDAs or by agreements that disallow reverse-engineering (where this is valid). The purpose of clean-room reengineering is to ensure that the authors of the new implementation cannot plausibly be accused of copying the original (since they have not seen it). The risk of being wrongly accused of copying applies regardless of whether the original was distributed in binary or source form; in fact distribution of the source increases the risk to a reimplementer since it would be so much easier for them to copy it.
It'll be the other way Posted Apr 23, 2009 14:50 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] Copyright applies to the expression of an idea, not the idea itself. If I reimplement an idea, it doesn't matter if I have access to someone else's expression of an idea. For example, if I see one movie about an asteroid hitting the Earth, that doesn't stop me from making my own movie about an asteroid hitting the Earth. Copyright doesn't protect the idea. The same applies to the ideas embodied in source code. That means the algorithms, the APIs, etc. I can use the source code as a definitive reference to how it works. But, there may be specific ideas embedded in that code. For example, there may be some whizzy algorithms that allow it to operate efficiently, or cute optimizations that make for a compact implementation. Or, there may be behavioral quirks that are exposed in the API that are artifacts of the implementation. How something implemented is a secret if you choose to keep it a secret. (This is why AT&T header files in SVR4 say that the code is unpublished proprietary source that is property of AT&T. See also Data General vs. Digital Controls Corporation.) The Phoenix BIOS vs. IBM BIOS clean room reimplementation was trying to avoid copyright infringement claims in addition to trade secret claims. For such a small piece of performance critical code, it's likely that the implementations will look very similar with only superficial differences. IBM could plausibly claim the code was copied and modified lightly rather than reimplemented unless Phoenix could point to an airtight process that prevents that. We're talking 8K bytes of object code here, so the odds of this happening are high. For something much larger and higher level than x86 assembly code, there is much more room for unique expression of the ideas embodied in the code. As long as it isn't directly plagiarized (ie. copied with only trivial changes), I don't see how any court could argue that a reimplementation (distinct re-expression of the ideas) would be a copyright violation. So, I'll go back to my original point: You don't need a clean room to reimplement GPL code. You just need to reimplement it. You won't hit trade secret issues, nor will you hit copyright issues if you re-express the ideas in the original code in your own way.
It'll be the other way Posted Apr 24, 2009 1:08 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
You assume that there are always multiple sensible ways of representing the code. If you hit a case where this isn't true, you either end up writing obfuscated code in order to avoid direct copying or you potentially end up with an awkward lawsuit. Safer to just clean room it.
It'll be the other way Posted Apr 21, 2009 15:05 UTC (Tue) by southey (subscriber, #9466) [Link]
Unfortunately the usage of "GPLv2 or later" is very misleading because you can NOT change the license of code unless you are the copyright owner of it. Thus, when distributing everything (since that is really when the terms kick in), that "GPLv2 or later" code would most likely remain under the original license. This creates problems if the terms of GPLv2 conflict with the terms of the licenses of other code like GPLv3 defeating the purpose of mixing GPLv2 and GPLv3 code.
It'll be the other way Posted Apr 21, 2009 16:16 UTC (Tue) by salimma (subscriber, #34460) [Link] You may not change the license stipulated by the copyright holder of the file, but the effective license that applies when GPLv2+ and GPLv3 code is shipped together is GPLv3. The file itself would still be GPLv2+.
This is FUD - plain and simple Posted Apr 21, 2009 20:25 UTC (Tue) by khim (subscriber, #9252) [Link] Take a look on OpenSSL. There are some files under 2-3 compatible licenses. No problems whatsoever - except bloat: now every file must carry few headers. The same with GPLv3: you can not remove original permission header with "GPLv2 or later", but you can safely attach new header before or after that'll say "all changes can only be distributed under GPLv3 or later". The effective result is GPLv3: to use GPLv2 you need to split the hair and remove "GPLv3 or later" code from the file. If introduced change is not trivial (and for trivial change there are no need to touch header at all - old "GPLv2 or later" copy is still around somewhere, right?) it's very hard.
|
|||||||||||||