| |||||||||||||
It'll be the other wayIt'll be the other wayPosted Apr 21, 2009 7:38 UTC (Tue) by khim (subscriber, #9252)In reply to: GPLv3 by shieldsd Parent article: Oracle: SELECT * FROM Sun
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...
(Log in to post comments)
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.
|
|||||||||||||