Hello,

Ciaran Farrell said on Wed, May 25, 2011 at 01:35:01PM +0200:

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.

Just 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