Two of world’s most wanted hackers had committed suicide and no one still knows why. Aaron Swartz and Jonathan James, both hackers by profession and most wanted by the FBI have committed suicide in face of the federal investigation against their hacking crimes.
Interested thing is both hackers were not connected to each other in any way but were being tried for hacking by the same department and the case was being overseen by the same Assistant United States Attorney Stephen Heymann. Could this have any hand in their suicides.
The Linux Foundation has updated its SPDX standard to v2.0, enhancing the ability to track complex open source license dependencies to ensure compliance.
The Linux Foundation (LF) released version 1.0 of the Software Package Data Exchange (SPDX) standard in 2011, promoting it as a common format for sharing data about software licenses and copyrights. Now the LF’s SPDX workgroup has released version 2.0 of the standard, with new features that let you relate SPDX documents to each other to provide a “three-dimensional” relationship view of license dependencies.
While verified copies of our licenses can be useful, this is unfortunately a project that sounds straightforward at first, but all the corner cases found in the wild muck it up.
One relatively frequent request we receive is for the FSF to provide GPG-signed copies of our licenses. GPG is a tool that lets users cryptographically sign or encrypt documents and emails. A GPG-signed document lets anyone who receives it know that they have received the exact same document as the one that was signed. By providing signed documents, users will be able to easily ensure that they have received an unmodified copy of the license along with their software. It's also possible that some system of signing the documents could help projects tracking the use and adoption of various free software licenses. Providing these signed documents is a simple task: run a command and publish the documents. A trivial investment of resources, or at least that is how it appears at first.
After helping to put the dot in .com by building and configuring enterprise class solutions with WorldCom as a Sun hardware and software engineer, Jason Smith went on to AAAS (The American Association for the Advancement of Science, and the publishers of the journal Science) to direct the technical needs of the education directorate.
Jason has built or architected solutions ranging from enterprise to small business class and has found in Drupal a flexible, scalable, rapid development framework for targeting all levels of projects. A long time beneficiary of the open source movement, Jason—now a senior software architect at The Weather Company—is an avid supporter of open source projects and believes strongly in giving back to the community that supported him.
For all its benefits, one aspect of open source software does cause headaches: understanding the legal terms that control its development and use. For starters, scores of licenses have been created that the Open Source Initiative recognizes as meeting the definition of an “open source license.” While the percentage of these licenses that are in wide use is small, there are significant and important differences between many of these popular licenses. Moreover, determining what rights are granted in some cases requires referring to what the community thinks they mean (rather than their actual text), and in others by the context in which the license is used.
The purpose of this parable is to illustrate just how misguided the term “intellectual property” is. When I say that the term “intellectual property” is an incoherent overgeneralization, that it lumps together laws that have very little in common, and that its use is an obstacle to clear thinking about any of those laws, many can't believe I really mean what I say. So sure are they that these laws are related and similar, species of the same genus as it were, that they suppose I am making a big fuss about small differences. Here I aim to show how fundamental the differences are.
Fifty years ago everyone used to recognize the nations of Korea, Mongolia and Pakistan as separate and distinct. In truth, they have no more in common than any three randomly chosen parts of the world, since they have different geographies, different cultures, different languages, different religions, and separate histories. Today, however, their differentness is mostly buried under their joint label of “Komongistan”.
Few today recall the marketing campaign that coined that name: companies trading with South Korea, Mongolia and Pakistan called those three countries “Komongistan” as a simple-sounding description of their “field” of activity. (They didn't trouble themselves about the division of Korea or whether “Pakistan” should include what is now Bangladesh.) This label gave potential investors the feeling that they had a clearer picture of what these companies did, as well as tending to stick in their minds. When the public saw the ads, they took for granted that these countries formed a natural unit, that they had something important in common. First scholarly works, then popular literature, began to talk about Komongistan.
Ask any developer where to turn for access to the latest software code for open source projects, and you’ll likely be directed to GitHub—one of the largest providers of open source code online.
While GitHub has always been a great site for developers to come together, network and share code, up until a few years ago, the website had a problem. Though it was easy for developers to share code, finding the right software license to go along with it was much harder. The majority of downloads on GitHub, therefore, were taking place without the critical software license component.
After this presentation, a specific point was still under investigation: the possibility of an “opt out” clause regarding the updated list of compatible licences. This list is not only extended to the GPLv3 and AGPLv3, but also to other copyleft licences like the MPL or the LGPL that protect the covered files or the derivatives of the covered works against exclusive appropriation (prohibition of re-licensing the covered files or their derivatives under a proprietary licence) without any ambition to extend their coverage to the whole work or application in which the covered file is integrated or linked.