My managing director dictated Libre Office over Open Office because it solves his problems with OO.
My dev team are keen as mustard to replace the remaining MySQL instances with MariaDB. Supporting an opaque platform that in turn is not likely to be supported by the distro's we use is not an appealing proposition.
Oracle respin of Red Hat was never an appealing option. We're a SUSE crowd at heart anyway.
From Oracles offerings (the ones they bought, we'll never use oracle DB) that leaves Java as a language and tool set. Dev time is too costly, the language is too clunky, the memory pressure is too high.
Oracle's association with pretty much any product (free software or otherwise) is enough for me to head in the other direction, and those are the recommendations I pass on to my clients, employers, and/or others asking for recommendations.
Happily, from Oracle's perspective, their legal win in their case against Google will not doubt quickly be leveraged to kill off the MySQL forks for copying MySQL's copyrighted APIs.
Correct me if I'm wrong, but I think if Dalvik were released under a license compatible with the Oracle runtimes, this whole thing between Oracle and Google goes away? I agree allowing copyrighting of APIs is a bit daft, but the point is that if you're trying to draw a parallel between MySQL/MariaDB and Java/Dalvik, it doesn't apply. (Assuming the MariaDB fork has a compatible license, which I believe it does.)
It's worth keeping in mind that the "dev time" is a function of existing libraries, internal and external. At any fairly large company (e.g. Google) that has many existing internal libraries in some language (java), the dev time will be massive to switch. By this logic, the dev time is too costly for absolutely any language you pick other than the one being used. There is little exception to this.
For a programmer or programmers with no legacy cruft, I'd argue that dev time is more a function of the programmer's familiarity with a language than the language itself. Perhaps there are a few exceptions to that, but in general I don't think that a language should be described as "too" anything. Java might be memory inefficient, but does that mean it's usage "too high"? Clearly not for some people as it's still used frequently.
Programming like that must be an absolute nightmare. Not only would have to understand the convoluted API scheme, you'd have to research the origins to see if you can legally use it.
Things have gone too far when you start namespacing by license.
Sure, but all you have to do to avoid this nightmare use the GPL. So since this encourages people to contribute their code back to the community (by releasing it under the GPL or a GPL-compatible license), I think it's a good thing.
Yes, if you use gpl'd code for free, the license forces you to share the improvements you make. That's the whole point of the GPL. No one forces you to use gpl'd code; if you don't like it, go write your own code.
> > The usual and suggested way is to get it included in the mainline kernel. This reduces the pain a lot.
> How does that help exactly?
Here's what GP asked about:
> Programming like that must be an absolute nightmare. Not only would have to understand the convoluted API scheme, you'd have to research the origins to see if you can legally use it.
So, I guess the answer is "because if you take my (and every other kernel developer's) advice, you don't have to program like that." Was the not clear? Sorry.
I guess the follow up question is, what the hell does the Tom Tom case have to do with GP's question?
Can someone explain the point of having EXPORT_SYMBOL_GPL() and EXPORT_SYMBOL()? Is it trying to protect the user from accidentally violating the GPL?
More importantly, why is there no high resolution clock available from EXPORT_SYMBOL()? Is it deliberately gimped, or is there issues with getting such a piece of software into the kernel whilst not being GPL'd?
Yes. It's deliberately gimped because the author of the function decided Freedom™ is more important than functionality and so they hid it behind a license check.
Whether or not it has _GPL is completely irrelevant.
The question is "does my modification to the kernel make a derivative work?" The _GPL defines are there to warn developers "Yes, using this function means you're probably doing something derivative."
In short, Oracle knew what they were doing, knew it was wrong, and are doing it anyways. Now it just comes down to the lawyers arguing whether DTrace becomes a derivative work or not, when and if someone files suit against them for not being able to use DTrace on TheirLinux.
> Yes. It's deliberately gimped because the author of the function decided Freedom™ is more important than functionality and so they hid it behind a license check.
Would have been a good comment without that remark, and almost certainly why you got downvoted. I gave you an upvote anyways, because the link is actually relevant and helpful.
I think that remark makes the comment better. It's ridiculous to claim that a simple timer has relevance to creating a derivative work, and the implication of zealotry in anyone making that claim via EXPORT_SYMBOL_GPL is appropriate.
The whole reason this is even an issue is the ambiguity of the license on the subject of dynamic linking and what precisely constitutes a derived work. Of course, if Linus wanted proprietary kernel extensions, he should have picked LGPL, but the issue arose long after the license was originally picked (and there being any possibility of changing/clarifying it). Also, no "or any higher version" clause, so the only way this is ever going to be resolved one way or another is in court. FWIW, my impression is GPLv3 wouldn't have helped here either.
It's basically a form of DRM, and the first time I saw it I was pretty taken aback too. Although this time, I'm actually on Oracle's side, since their workaround is yet another example that shows how technological measures to enforce copyright are an awfully bad idea.
Maybe when more people realise the distinctly unique aspects of digital data and how, for lack of better words, pliable and copyable it is, we can have a real copyright reform. Of course that requires the population understand this type of thing, but a copyright reform is exactly what companies like Oracle don't want, so the probability is pretty low...
Note that DTrace/Linux exists outside of Oracle. (Search github for dtrace4linux).
As that author of the product, I took a different approach to the GPL symbols - one which may be questionable, but nobody has raised the issue as yet.
Yes, GPL symbols are problematic, and the dtrace4linux is CDDL - the GPL vs CDDL - means its impossible, from a legal perspective to get the balance right. That does not preclude generation of a useful tool - the beauty of all open source - is the ability to learn from it.
The issue isn't whether or not the code is open source / free software, it's specifically compatibility with the GNU GPL v2 under which the Linux kernel is released.
The GPL is picky about what licenses are compatible with it (or more specifically, what licensing terms), and for very good reasons given its intended purpose (to promote the availability of yet more GPLd code).
Which also exists in CDDL code. Viral copyright makes it real difficult to share things if various parties have different ideas as to how to best require others to share files.
The comparison at hand is with DTrace, which has afaik only Oracle as the copyright holder, so they could change the license if they wanted to.
CDDL is a bit weird. It's a free license that has a pointless restriction merely in order to make it GPL incompatible. Why people want to make things deliberately GPL incompatible is beyond me.
I'm looking through the source I have for DTrace, and there is code written by folks other than Oracle, so changing the license is more difficult than just that. Regarding the GPL, one must ask at the same time why the GPL makes itself deliberately incompatible with four-clause BSD code, or other Free licenses that predated the GPL. Viral licensing just leads to petty fiefdoms and precludes the very sharing they claim to protect.
oh boy, another GPL debate! phk was right, seems we never get tired of this stupid shit.
It didn't make itself "deliberately incompatible" with all free licenses before it, for example MIT/X11 is definitely compatible. Why is the original BSD license singled out?
Many people besides you believe proprietary software is harmful enough to enact defense mechanisms when proprietary software vendors harm the user and lock down free software into their products.
I singled out the original BSD license because it was extant and the GPL was not compatible with it. Such clauses are pretty common in the software world and give credit where credit's due; hell, Microsoft has no problem with it, why does it bind the panties of the average GPL supporter so much?
Furthermore, I'd argue that a lot of those defense mechanisms that copyleft supporters claim are necessary cause much more harm to Free Software than they do to proprietary software. The ability to use GCC for static analysis, for example, was muddied for many years by the GCC team's unwillingness to create a suitable API out of fear that it would become easier for proprietary software teams to use GCC without contributing. Meanwhile, proprietary compiler chains, like those Microsoft provided, were easily able to create those same tools because they were not driven by such fears. Additionally, you have statements from people like RMS trying to memory hole software ( http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html ) that doesn't agree with his political views. While the goals may be noble, the route the free software community has chosen to get there has devolved into stubbornness and childishness to the detriment of everyone.
> I'm looking through the source I have for DTrace, and there is code written by folks other than Oracle,
That is irrelevant if DTrace used copyright assignment to ensure that there was always one copyright holder, regardless of the number or affiliations of contributors. I honestly don't know if they did or not, but from what I've heard in this thread it sounds like they did.
I think development has moved away from Oracle now partly, but at one point there was a Sun/Oracle only version. This piece [0] argues that the reason for not dual licensing it was that there might be GPL only contributions and then eventually a GPL fork, which is not that unlikely given the larger size of Linux vs VSD+Solaris. Same with ZFS I guess, even if Oracle mostly sponsored btrfs.
The GPL is the world's most popular license. The CDDL was purposely designed to be incompatible with it. Anyone choosing the CDDL is purposely choosing to exist in an island outside the GPL.
In as much as the metadata is accurate, the information can be interpreted in any meaningful way, and considering selection bias for things that people actually make available via these services (however, if something isn't listed with some index that makes it discoverable, it doesn't matter what the license is):
Sourceforge: of 1236 "OSI Approved" listed via the search refinement interface, 983 GPLv2, 22 BSD, 10 Apache 2.0, 8 MIT.
Unfortunately, neither Github or Oholo provide aggregated license information or it's not easy to find [0]. I did find this two year old post [1] about licenses of the most watched repositories on github, but popularity of the project isn't necessarily an indicator of popularity of the use of the license -- except as much as the type of license indicates which projects people will want to use because the the license lets them contribute. I do vaguely remember some random blog posts that attempted to do license counts in a repeatable and objective way, but my google-fu is failing me right now.
These are hardly conclusive numbers, and it becomes difficult to consider it in aggregate. Is all of OpenBSD considered one "project", as it's effectively distributed as one piece, or are the individual components themselves projects? Is everything in GNU core-utils one project? Maybe each binary counts as the use of the license. However, just going by these services' self-promoted "project" delineation being ~10x in favor of GPL (GPLv3, LGPL may or may not be included in the above numbers), the non-GPL licenses seem to be significantly low enough that "The GPL is the world's most popular license" may be a reasonably safe, even if not entirely accurate, position to take. I suspect that if you pick 10 projects at random, more than half of them will be GPL.
In addition to what thwarted posted, Black Duck is a great resource for analysis of open source software as they have a database drawn from all over the place: http://www.blackducksoftware.com/resources/data
If you summarize for GPL/LGPL and what projects are compatible, it winds up being about 45% of projects GPL/LGPL and up to 87% or more of all open source projects are compatible with the license. I go over it in a handy chart here: http://johnhaller.com/useful-stuff/open-source-license-popul...
As thwarted said, it can be problematic looking at 'projects' as something like bootstrap on github, which is MIT licensed, has over 24,000 forks. Now, most of those are nonsense and have no changes (or at least nothing useful) but do you count that as 24,000 projects?
Outside of CDDL being explicitly crafted to be incompatible with GPL, no action from FSF would have any impact on Linux licencing since Linus chose to use GPLv2 ONLY rather than 'GPLv2 or later' which is the usual case.
Beyond that, given how Linus himself thinks that 'Making Linux GPL'd was definitely the best thing I ever did. ' and him attributing it as being a huge part of why Linux became such a success, I'd say there would zero chance of a Linux license change even if it was all up to Linus, which of course it is not.
i still remember the day in a meeting when someone spoke of my employer having acquired some lic for a product which they designed to modify and i asked if we have a legal team to analyze it , well the director came back shouting another team should take the job!
Seems to me that the appropriate attack might be fraud and misrepresentation, if not copyright abuse. That's an attack which could be levied on Oracle by any party (oh, say, someone who's already upset at them for some reason, perhaps Google), not just a kernel copyright holder or The Linux Foundation.
The misrepresentation is of the module as being validly licensed under the GNU GPL where it clearly isn't. In an earlier case concerning copyright, the question rose whether or not a brief citation for functional reasons was valid or an infringement of copyright. The court's decision was that a literal quoting that served functional purpose was not, in fact, a violation of copyright.
The case with regards Oracle involves the use of one of two largely equivalent mechanisms. As the article discusses:
The kernel actually has two levels of exposed (non-userspace) API - those exported via EXPORT_SYMBOL() and those exported via EXPORT_SYMBOL_GPL(). Symbols exported via EXPORT_SYMBOL_GPL() may only be used by modules that claim to be GPLed, with the kernel refusing to load them otherwise. There is no technical limitation on the use of symbols exported via EXPORT_SYMBOL().
Use of EXPORT_SYMBOL and EXPORT_SYMBOL_GPL are equivalent except for the expressed compatibility with the GPL license. Use of EXPORT_SYMBOL_GPL where it's not justified is making a claim about suitability of use. That is the basis for my fraud claim.
My managing director dictated Libre Office over Open Office because it solves his problems with OO.
My dev team are keen as mustard to replace the remaining MySQL instances with MariaDB. Supporting an opaque platform that in turn is not likely to be supported by the distro's we use is not an appealing proposition.
Oracle respin of Red Hat was never an appealing option. We're a SUSE crowd at heart anyway.
From Oracles offerings (the ones they bought, we'll never use oracle DB) that leaves Java as a language and tool set. Dev time is too costly, the language is too clunky, the memory pressure is too high.