On 7/13/12 1:32 PM, "Bradley M. Kuhn" <bkuhn@...> wrote:

Philip Odence wrote at 11:52 (EDT) on Thursday:

Suprisingly after all the recent discussion on the General Meerting
list about expanding the list, no one has submitted any more licenses.

FWIW, I looked at this possibility briefly. Upon reading
http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be-
added
I came to the conclusion that I couldn't easily submit any of the
licenses I was thinking of, such as GCC's license, which is effectively
GPLv3-or-later-with-GCC-RTLv3.1-or-later.

Mainly, it's tough to meet submission requirement (3). There's no URL
for that license. GCC RTL 3.1 has one URL, GPLv3 has another, but
what's the URL for the combo with appropriate -or-laters? There is
none.

If there is no url, then there is no url - just state this. However, in
this scenario, I would simply include the two you mention above. The
field need not have only one url (e.g. For licenses that are OSI approved,
I have included both the OSI link as well as the license author's link,
where found).

The SPDX list itself clearly
envisioned this fact, as things like "GPL-2.0-with-autoconf-exception"
already appear. But, those existing listings fail to account for how
the exceptions actually are used in real world programs, as discussed in
the threads over the last month.

As I thought was explained previously, there has already been several
discussions on the legal calls on how to best deal with the various GPL
exceptions. I don't think anyone would claim we have come up with the
best solution, and this has been something that has been recognized as
needing more discussion and work. Alternative proposals and a description
of how to implement are always encouraged (as well as help doing the
actual work...) - from anyone.

Thus, if I were to formally propose GCC's license, it'd have to be part
of a broader proposal I'd have to also propose removal of
GPL-2.0-with-GCC-exception from the list, and I didn't see any
instructions on SPDX's site on how to propose a comprehensive change
like that.

We have endeavored to NOT remove licenses from the list once added. I
don't understand why you'd want to remove this? Isn't it possible to
still come across old versions (of any license) "in the wild?" (I know I
have.) In fact, we have tried to make sure we captured all versions of
licenses on the list (with the exception of more work needing to be done
on capturing at least a majority of the GPL-exceptions, as already stated.)
In any case, any suggestion for which there is not a "formal" process can
simply go through this mailing list, as you have done :)

Finally, the (admittedly more of a pet-peeve) last straw that led me to
give up was I saw that I had to download and open a zip file
(http://spdx.org/system/files/spdx_license_list_v1.16.zip ) just to grab
a text version of the list, and that to make the submission, I had to
fill out a spreadsheet (
http://spdx.org/system/files/spdx_licenselist-new-licenses.ods ) rather
than just use text editor to edit a file. I much appreciate that ODS
format is used, of course, but most of us old-school Free Software
licensing people don't use spreadsheet programs very often, even Free
Software ones, and certainly not merely to submit text and URLs.

I'm not sure why you needed to download the zip file to make the
submission for a new license - you can just create your own. As far as
the spreadsheet is concerned - that was just recently added to provide
another option. Originally, the instructions just said to submit the
information for the license being suggested via email (including the
license text). But it was pointed out that some people may find the
spreadsheet easier as the fields could already be included for prompting
and also if one was submitting multiple licenses.

In any case, thanks for reading through the process and the requirements
for each field so carefully. You may be the first person (that I know of,
anyway) to have done so. Such "testing" is helpful to make the
explanation easier to understand and improve the process.