On Aug 28, 2014, at 1:39 AM, Jeremiah Foster <firstname.lastname@example.org> wrote:
Hello,Echoing the thanks to the LF for kindly hosting the WG.
Secondly, I have some concern around cadence. Telephone meetings once every week require momentum, otherwise its just a bit of conversation and while that is always good, it doesn't show much progress. I'd recommend once every other week unless its demonstrated that more is needed. If we stick to once a week, the project will likely have to have some project management -- milestones, deliverables, deadlines. There are already a lot of resources for people to discuss compliance, FSF compliance lists, FSFE legal, Debian-legal, etc. We don't need another list, we need codified methodology that's widely accepted both de facto and de jure.Could not agree more. BTW in addition to Mike’s support on hosting the discussion, we already have a PM on this list. Kelly Williams is not an open source expert but here for the PM aspect. We must not allow this to devolve into another list.
Lastly, I'd strongly urge all of us to kill our darlings. We need to not try and chose technology winners. For example, while SPDX looks great, its not widely adopted. Debian has its own format and Yocto is using SPDX version 1.1. Its hard to use, has numerous supported versions (1.1, 1.2 and 2.0 in development) and feels a bit like a solution looking for a problem. Being Java based (there is Go code and python code now) its better suited for those working in a Windows environment and while I'm certain that is a highly lucrative market, for Free Software developers it tends to be anathema. If SPDX is the right and only ISO certifiable solution, we ought to be able to demonstrate that in detail and with strong technical and legal support.Agreed re no sacred cows. SPDX has a lot of thought built into it already by folks who understand the way software moves through software companies, hence the initial comments.
Towards offering some initial thoughts re attribution formats, would think we’d want a format that (1) allows easy reuse, (2) automation potential via metadata-tagged fields, (3) essential data types defined, (4) a data schema that allows file-level tracking, and (5) integratability with the most popular version control systems. Probably more comes to mind by others.
Would you be willing to work with Jilayne and others on the Workstream-still-to-be-formed on the appropriate options?
To be successful, you'll have to be widely adopted. This is the exact same measure of success FOSS software projects have to meet. The recent migration of systemd into Debian forcing Ubuntu to migrate away from Upstart ought to be a cautionary tale: forks often fail.Again, could not agree more. As a separate note re Workstreams — a possible way for us to approach that is to first have a top level discussion on the desired characteristics of the needed elements before breaking that discussion off, into its Workstream. This discussion is an example.