Licensing Workshop at LinuxTag 2011
Ciaran Farrell
Hi, before LinuxTag 2011 I sent around invitations to this workshop "Cross Distribution Licensing Summit": http://is.gd/7GF9Ar (linuxtag.org) Some of you indicated that you would not be able to make it. As it turned out there was not a huge variety of distributions present there, but I think that the discussion that we had was nonetheless quite enlightening. We saw that there is a variety of ways in which distributions describe the license of a package (or a component of a package) - where the distributions actually mean the same license but have different designations (short names) for their package metadata. Whereas we didn't actually conclusively decide on anything, we did agree that it would be beneficial if the distributions would adopt a common scheme of designating license names. Currently, one example of an online collaborative effort (under the auspices of the Linux Foundation) is SPDX (spdx.org) (which has been adopted by Debian in DEP5). The workgroup at SPDX.org has come up with a list of commonly used licenses (see http://www.spdx.org/licenses). The list has many licenses but not all licenses that distributions will likely need to track and reference. There should not be a problem with submitting more licenses to SPDX so be included in that list. Therefore, I'd like to propose that we evaluate as a group the possibility of standardising how we refer to licenses based on SPDX. I know that there has been considerable criticism of the absence of numerous licenses from the SPDX list, but I believe that if we inform the SPDX working group of the licenses we would like to see included and if they are in fact included, the benefits will be quite substantial. I'm more than interested in hearing your comments, feedback and opinions. Also, I've included as many people on the mail thread as I could and I believe I have reached a large number of distributions. However, if anybody is aware of a person/company who could be interested, please do forward this mail. Ciaran -- Ciaran Farrell __o cfarrell@... _`\<,_ Phone: +49 (0)911 74053 262 (_)/ (_) SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany /ˈkiː.ræn/ |
|
Amanda Brock <amanda.brock@...>
Ciaran
toggle quoted message
Show quoted text
Kate Stewart is the Chair of SPDX and represents Canonical on this. I have asked her to respond to this and would be pleased if you could please keep both of us on the thread. All the best Amanda Amanda Brock, General Counsel Canonical 27 Floor, Millbank Tower London SW1P 4QP +44 2076302446 +44 7809389878 Ubuntu - Linux for Human Beings www.canonical.com On 25/05/11 12:35, Ciaran Farrell wrote:
|
|
Joerg Schilling <Joerg.Schilling@...>
Ciaran Farrell <cfarrell@...> wrote:
before LinuxTag 2011 I sent around invitations to this workshop "Cross... Currently, one example of an online collaborative effort (under the auspicesI am not sure who manages this page, but http://spdx.org/licenses/ISC and some others cannot be displayed on my firefox as they give a xml parsing error. I'm more than interested in hearing your comments, feedback and opinions. I just had a small discussion with Thomas Gordon who wrote Carneades: http://carneades.berlios.de/ His software currently uses an interactive questionaire but it could be enhanced to read specs that contain a list of licenses and code relations as well as general rules on how to interpret licenses (e.g. whether the GPL is to be interpreted as being in conflict with US Copyright law title 17 paragraph 106 or not) and then could output a license compatibility report. Doing this automatically on a large number of software projects could be used to find out whether a specific license intepretation would affect a large number of OSS projects that are typicallally shipped on distros. Carneades currently contains basic rules for a few licenses. There would be a need to refine the rules and to add more licenses but the engine is ready.... Jörg -- EMail:joerg@... (home) Jörg Schilling D-13353 Berlin js@... (uni) joerg.schilling@... (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily |
|
Bruno Cornec <Bruno.Cornec@...>
Hello,
Ciaran Farrell said on Wed, May 25, 2011 at 01:35:01PM +0200: Currently, one example of an online collaborative effort (under the auspicesJust for completion (and maybe discussion with them), I attended a session at the latest Solutions Linux in Paris, where a project called Open Source Cartouche was described, which is near from SPDX. Cf: http://www.opensourcecartouche.org/ (Shameless plug for the source: http://brunocornec.wordpress.com/2011/05/12/second-day-at-solutions-linux-2011/) "Open Source Cartouche by Philippe-Arnaud Haranger (Atos Origin – Team Pascal Pujo) Study made around an Aerospatial customer. 9 years of devs, and strong willingness to use FLOSS components. Study showed incompatible licenses. Copy/Paste of code in 2000+ bricks. Quote: “My God ! What have been done ?” Licensing wasn’t a priority (they already didn’t document) Code contamination is made on purpose, because they need it, and is due to local teams, outsourcing, and external application maintenance. Consequences: licenses not respected, proprietary code tainted (PI loss) Open Source was favoured, but in reality they created risks. Solutons: Strong governance (creates too many constraints in general) or Tooling (cost, but efficient) or Manual Audit (cost, complex, impact) or take risk (costs and impact) or open source the SW (anyway conformity required, but impact as irreversible). The earlier it’s done the less it costs. Solution is Open Source Cartouche (what is around the Pharaon) – derived from QSOS. Identify licenses and the recursivity of components integrated It’s a structural approach beforehands, instead of scan afterwards (even if this is also required) Put more trust in the FLOSS, Avoid contamination and protect community works. Presenter asked the possibility of using this formalism in FOSSology ? Some Remarks on my side: I asked the question: What is the position vs SPDX ? I think they are probably in competition, and that they forget to consider it before launching something on their side. What is important is to have a standard adopted. The answer was that there is a fear of Blackduck that may create problems for communities. Their standard proposal is simpler than SPDX so more pragmatic, and thus propably easier to adopt by FLOSS projects. And the team is open to make required adaptations. However, it won’t work as a franco-french stuff !! I think we need an SPDX lite if we aim at being adopted by FLOSS projects, as the current status of the project is just only understandable by lawyers. I’ll try to generate some discussions around that on the SPDX ML. Thinking about all this I think it would be valuable as well to lauch a new initiative to create the CERT/CVE base of licenses violations, working on the same model (disclosure after problem is solved)." HTH, Bruno. -- Open Source & Linux Profession Lead EMEA / http://opensource.hp.com HP/Intel/Red Hat Open Source Solutions Initiative / http://www.hpintelco.net http://www.HyPer-Linux.org http://mondorescue.org http://project-builder.org La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|