RE: Change in the FreeBSD license

[Zavras, Alexios]

Thank you for this info.

If the last line is not part of the license, do you see any difference between 
your license and the pure BSD-2-Clause one 
(https://spdx.org/licenses/BSD-2-Clause.html)?

Please note that the wording appearing in red on the page is placeholders and 
can be substituted in actual instances of the license text.
I see your license uses double single quotes around “AS IS”, but this is 
allowed by the SPDX Matching Guidelines.


-- zvr –

From: spdx-legal-boun...@lists.spdx.org  On 
Behalf Of Pedro Giffuni
Sent: Thursday, 24 May, 2018 19:33
To: spdx-legal@lists.spdx.org
Subject: Change in the FreeBSD license


Hello guys;

After internal discussion FreeBSD has decided to further simplify the license 
by dropping the "All Rights Reserved." line from the license used in FreeBSD. 
IANAL but it appears from the Berne Covention onwards, the line was deemed 
unnecessary.

Some authors have already done the change unilaterally and the FreeBSD 
documentation has been updated so in the future the change will be included in 
new files. I am unsure how you want to handle the change in SPDX; at the time 
we are considering the "new" license equivalent and we shall continue tag it as 
"BSD-2-Clause-FreeBSD".

Can you kindly update this page:

https://spdx.org/licenses/BSD-2-Clause-FreeBSD.html

Also, while here, let me note that the last line is not part of the license:
The views and conclusions contained in the software and documentation are those 
of the authors and should not be interpreted as representing official policies, 
either expressed or implied, of the FreeBSD Project.
It is just a footer used by the FreeBSD documentation project.

Best regards,

Pedro.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

RE: meeting minutes

[Zavras, Alexios]

I couldn’t join that meeting, but on the subject of FSF “free” field: let’s 
make sure that FSF’s own licenses (GPL*, LGPL*, GFDL*, etc.) are marked as 
“free”. I think their site lists only licenses by others, but our table seems… 
strange having an empty field for GPL’s free bit.


-- zvr –

From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of J Lovejoy
Sent: Tuesday, 27 February, 2018 16:08
To: SPDX-legal 
Subject: meeting minutes

Hi all,

The meeting last week picked up on further discussion of things to work on and 
discuss at face-to-face. You will have also just seen the email to all re: 
topics. Please let us know if you will be there!

https://wiki.spdx.org/view/Legal_Team/Minutes/2018-02-22

Also, as the next legal call falls the day before the face-to-face on March 
8th, we’ll skip that meeting - please mark your calendars accordingly.

thanks,
Jilayne

SPDX Legal Team co-lead
opensou...@jilayne.com

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

RE: New Exception Request:

[Zavras, Alexios]

Since the authors seem to be in the email thread, may I please ask for a 
version number to the exception(s) ?
Experience has shown that texts change and I’d rather avoid the case of W3C, 
W3C-19980720, W3C-20150513, etc.

In SPDX names, I think we always use the singular “-exception”, even if the 
text contains more than one (FLTK-exception is an example, I think).

-- zvr –

From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of J Lovejoy
Sent: Tuesday, 12 December, 2017 02:59
To: SPDX-legal 
Cc: clatt...@llvm.org; Heather Meeker ; 
arnaud.degrandmai...@arm.com
Subject: New Exception Request:

Hi All,

I’ve been meaning to send this for review, so hopefully I can make it under the 
line for the next release.

LLVM has been working on a re-licensing project for some time now. They have 
decided upon Apache-2.0 with a special exception to avoid obligations when 
redistributing complied code (a la GCC exception) and to avoid the Apache-2.0 - 
GPL-2.0 incompatibility issue.

I don’t think I have to explain what LLVM is here or its importance.

While this is a somewhat pre-emptive request, I think it’s important to provide 
LLVM with the full availability of using SPDX identifiers by adding this 
exception.

URL to text: http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html 
(LLVM website to be updated)

Text of exception:

 LLVM Exceptions to the Apache 2.0 License 



   As an exception, if, as a result of your compiling your source code, portions

   of this Software are embedded into an Object form of such source code, you

   may redistribute such embedded portions in such Object form without complying

   with the conditions of Sections 4(a), 4(b) and 4(d) of the License.



   In addition, if you combine or link compiled forms of this Software with

   software that is licensed under the GPLv2 ("Combined Software") and if a

   court of competent jurisdiction determines that the patent provision (Section

   3), the indemnity provision (Section 9) or other Section of the License

   conflicts with the conditions of the GPLv2, you may retroactively and

   prospectively choose to deem waived or otherwise exclude such Section(s) of

   the License, but only in their entirety and only with respect to the Combined

   Software.



Thanks,

Jilayne


SPDX Legal Team co-lead
opensou...@jilayne.com

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

RE: new GPL identifiers

[Zavras, Alexios]

OK, I have no issue with the longer identifiers.
The suggestion was only for making it more natural to talk about the licenses, 
as to not have to explain "we say '3-clause BSD' but write 'BSD-3-Clause'" (I 
usually don’t pronounce the .0 when I mention the GPL versions).

Proposal withdrawn, all’s well.


-- zvr –

From: J Lovejoy [mailto:opensou...@jilayne.com]
Sent: Thursday, 7 December, 2017 17:02
To: Zavras, Alexios <alexios.zav...@intel.com>
Cc: SPDX-legal <spdx-legal@lists.spdx.org>
Subject: Re: new GPL identifiers

HI Alexios,

I’m not sure why we need to do this, but I am strongly discouraging this 
further change.  We have already been through conversations on this on the 
calls and with the FSF and came to the conclusion for the short identifiers as 
of the last call on Tuesday, Nov 21st.  That was the decision we came to, I 
don’t see any compelling reason to re-open it.

Thanks,
Jilayne

SPDX Legal Team co-lead
opensou...@jilayne.com<mailto:opensou...@jilayne.com>

On Nov 28, 2017, at 11:41 AM, Zavras, Alexios 
<alexios.zav...@intel.com<mailto:alexios.zav...@intel.com>> wrote:

Hi all,

May I humbly suggest that, in our new SPDX identifiers for the different cases 
of GPL, we drop the “.0” ?
I mean, to have them like GPL-2-or-later, GPL-3-only, etc.

Obviously the new identifiers of LGPL-2.1 will keep the exact version.

-- zvr –

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de<http://www.intel.de>
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org<mailto:Spdx-legal@lists.spdx.org>
https://lists.spdx.org/mailman/listinfo/spdx-legal

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

new GPL identifiers

[Zavras, Alexios]

Hi all,

May I humbly suggest that, in our new SPDX identifiers for the different cases 
of GPL, we drop the ".0" ?
I mean, to have them like GPL-2-or-later, GPL-3-only, etc.

Obviously the new identifiers of LGPL-2.1 will keep the exact version.

-- zvr -

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

RE: License identifiers sufficient to avoid loss of information in DeclaredLicense (was: GPLv2 - Github example)

[Zavras, Alexios]

Besides the case of GPL version numbers, isn't the issue similar to when we 
have cases like where you have a package that simply says
"This program is under the BSD license"

The author "declared" something, but the SPDX spec is not really useful, since 
the value of the field is a license (or a license expression) and not a free 
form text. None of the licenses in the SPDX license list can be used as 
"PackageLicenseDeclared". Do we put a list of the 15 or so BSD variants, or 
disregard the declaration by stating "NOASSERTION"?

Taking it further, suppose that by looking at the actual wording of the license 
text in files, you might decide that the author is talking about 
BSD-3-Clause-No-Nuclear-License (in the nice case where all the files use the 
same text). But isn't this a "Concluded" rather than a "Declared" field?

-- zvr -

-Original Message-
From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Gisi, Mark
Sent: Friday, 15 September, 2017 13:19
To: Bradley M. Kuhn ; SPDX-legal 
Subject: RE: License identifiers sufficient to avoid loss of information in 
DeclaredLicense (was: GPLv2 - Github example)


Quick clarification:

>> I admit that I don't know how exactly to express such as Declarations. 
>> What is quite clear from this discussion, though, is that the 
>> Conclusions that people make about such Declarations vary.  Mark Gisi 
>> Concludes most of these examples as NOASSERTION.
>> I Conclude most of them are GPLv1-or-later.

The examples addressed Conclude License (files and package) but not the 
Declared License.
Furthermore, I only made a comment about Example 4. I agreed with the file 
Concluded License designations for Examples 1-3. Including Example 3 = GPL-1.0+.

And yes, for Example 4 I concluded NOASSERTION for each of the four files that 
have zero licensing info in them. There are many scenarios where those files 
could be something other than GPL. For example, one or more source files could 
have been copied from an Apache project or a commercial code based. I have 
encountered two cases in as many years where commercial code was copied  into a 
project with a GPL-2.0 file in the top directory. In one case the commercial 
license notice was retained in the file and in the other the notice was 
removed. Another situation I encountered ~5 years ago: someone admittedly 
removed the BSD license notices from several files he copied into his GPL 
project. He just assumed that they were now under the GPL-2.0 and the BSD 
notices were confusing and unnecessary! I had to explain he was violating the 
BSD license. 

As for Example 4, for me, hope is not a strategy. NOASSERTION.

>>
>> 3.15 Declared License
>>

The problem with this field does not lie with the LEL but with the values the 
"field" will accept. 

"This field lists the licenses  that have been declared by the authors 
of 
The package.  "
It should probably accept a list of LELs. For example if the top level 
directory had the following license files:

COPYING.GPL-2.0
COPYING.LGPL-2.0 

Then the declared license field should accept the "list" of LELs: GPL-2.0, 
LGPL-2.1

This approach is simple and probably handles 95% + cases.

- Mark


-Original Message-
From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Bradley M. Kuhn
Sent: Wednesday, September 13, 2017 11:47 AM
To: SPDX-legal
Subject: License identifiers sufficient to avoid loss of information in 
DeclaredLicense (was: GPLv2 - Github example)

Since the Legal call where we first began discussing what Jilayne has called 
the "Github examples", I've been thinking about this question regularly.

I do agree wholeheartedly with Richard Fontana's point that SPDX both has 
stakeholders who use the license identifiers outside of SPDX (and that SPDX as 
a project lauds such uses).  SPDX should indeed think about those users.
I'm primarily one of those users to the extent I use SPDX.

However, for the purposes of this discussion, I suggest we return to first 
principles in the SPDX specification.  So I asked myself, what job does SPDX 
expect license identifiers to do?  I went to the SPDX spec and looked at
this:
   3.15 Declared License
 3.15.1 Purpose: This field lists the licenses that have been declared by 
the
 authors of the package.  Any license information that
 does not originate from the package authors,
 e.g. license information from a third party repository,
 should not be included in this field.
   (URL: https://spdx.org/spdx-specification-21-web-version#h.1hmsyys ) 

I began to think carefully about this question, what *is* the "Declared 
License" -- by the package authors -- in the examples at 
https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Examples_.2F_Challenges
?

I admit that I don't know how exactly to 

RE: revised wording for top of exceptions page

[Zavras, Alexios]

My engineering, non-legal view is that a license specifies:

  *   What you are allowed to do (permissions); and
  *   What you must do (obligations).
[excuse the non-legal naming]

I assume that a “modification” may add to or remove from both categories.
Is this what we want the texts to be used via WITH to cover?
All the four variants? Or a subset of these (like “only additional permissions” 
or “only removal of obligations”)?

-- zvr –

From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Michael Dolan
Sent: Tuesday, 11 July, 2017 00:12
To: Richard Fontana 
Cc: SPDX-legal 
Subject: Re: revised wording for top of exceptions page


On Mon, Jul 10, 2017 at 3:32 PM, Richard Fontana 
> wrote:
There was one notorious case of the use of GPLv2 with a permissive and 
restrictive additional term that was described at the time as an "exception" -- 
Red Hat's license for Liberation Fonts 1.0. See: 
https://en.wikipedia.org/wiki/Liberation_fonts#Distribution

I wouldn't particularly recommend use of a 'WITH' expression to describe 
Liberation Fonts 1.0, but might not be the only example of a use of "exception" 
by a licensor (and the general public too) in this sense in the real world. 
IOW, there could be multiple cases in the real world of things called 
"exceptions" that are not "additional permissions".

Richard

That's a similar concern I raised on the call last week - though at the time I 
admittedly lacked a real world example as you have provided here. I was 
considering mentioning the "FreeRTOS GPL exception" 
(http://www.freertos.org/license.txt) which I discovered recently.  (I do not 
endorse what they created as an "exception", in fact they also refer to it as a 
"modification to the GPL", - I'm just citing its existence.)

Regardless of the example, the phrase I keep coming back to for describing 
exceptions is "modifier of something". I think of these as modifiers that only 
exist when applied to a license. Admittedly some licenses (though not all), 
prevent explicit "modification" of the license, but they all modify terms of 
what you can or cannot do or the conditions that apply.

The language I've used below may need cleanup, but the high level construct I 
was thinking about was similar to the following statement. Plain text is not 
easy for redlining, so I've used [ADD: ] and [REMOVE: ] in brackets to show 
additions and deletions from the original proposal Jilayne and Bradley took the 
initiative to draft (thank you).

The SPDX License List includes a list of commonly found exceptions to open 
source licenses.  Exceptions [ADD: may exempt, modify or add terms, permissions 
or conditions] [REMOVE: grant additional permissions] beyond those [REMOVE: 
already given] in the license that the exception modifies.  These exceptions 
are not stand-alone licenses; rather, they are designed for use with the 
License Expression Syntax operator, "WITH", to identify a license that includes 
an [REMOVE: additional permission] [ADD: Exception] [REMOVE: beyond those in 
the main license].

A "clean version" would read as:

The SPDX License List includes a list of commonly found exceptions to open 
source licenses.  Exceptions may exempt, modify or add terms, permissions or 
conditions beyond those in the license that the exception modifies.  These 
exceptions are not stand-alone licenses; rather, they are designed for use with 
the License Expression Syntax operator, "WITH", to identify a license that 
includes an exception.

-- Mike
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

RE: Question on semantics for bullet tag

[Zavras, Alexios]

In my understanding, the “bullet” element is a shorthand for “bulleted 
paragraph”.

I would expect your example to be translated to

before


I am a bullet


After

which, rendered with defaults, would result in a blank line before and after 
the list.


-- zvr -

From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of g...@sourceauditor.com
Sent: Thursday, 8 June, 2017 18:42
To: 'SPDX-legal' 
Subject: Question on semantics for bullet tag

I ran into an implementation issue in trying to convert the license XML into 
HTML for the website.

The bullet tag is currently defined as an independent element.

I implemented the bullet to do a newline before each bullet.  For example:
before
I am a bullet
After

Would be rendered as:
Before
● I am a bullet
After

The problem is if I include it in a list, the list item also generates a new 
line, so lists with bullet get an extra blank line.

For example:
before


I am a bullet


After

Would be rendered as:
Before

● I am a bullet
After


In looking at how HTML solves this, there is no bullet tag but rather an 
attribute of the list item.

If we believe that we would only use bullets in a list, I would propose we 
change bullet from an element tag to an attribute of list item.

I could implement some logic to handle this, but it would be somewhat 
convoluted and hard to describe when and how to use bullets.

I realize this will require some rework for the licenses.  I can, however, 
include a conversion from the element tag to the attribute in the xml 
conversion utility.  This would localize the convoluted logic to the conversion 
and not to the standard code.

I’ll be on the legal call for the first 30 minutes or so if you would like to 
discuss this.

Thanks,
Gary


-
Gary O'Neall
Principal Consultant
Source Auditor Inc.
Mobile: 408.805.0586
Email: g...@sourceauditor.com

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

RE: New OSI approved license (BSD+Patent)

[Zavras, Alexios]

I agree with Jilayne, and this is also the reason I’d prefer to avoid the 
“with” even in the long license title.

Of course, McCoy has also written some “pluggable” patent wording that could be 
combined with other licenses in theory. If he wants to submit it to SPDX, maybe 
this could be an “exception” (non-OSI approved, obviously).


-- zvr –

From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of J Lovejoy
Sent: Thursday, 1 June, 2017 19:39
To: W. Trevor King 
Cc: Smith, McCoy ; SPDX-legal 
Subject: Re: New OSI approved license (BSD+Patent)

Hi Trevor,

This would not be treated as an exception because it was drafted (and submitted 
to the OSI) as a complete license, not as an exception or separate, add-able 
text to BSD-2-Clause. While you raise a good point about the potential 
different ways one might express such a situation as this, I think we need to 
generally ‘take them as we find them’ and no re-interpret the intent of the 
(license) author.

That being said, we probably need to actually define what an exception is, as I 
think is understood concept but not actually spelled out anywhere (on the SPDX 
License List or possible elsewhere!)

As for an identifier, there is no reason to use “OSI” in the identifier - we 
have all of the OSI-approved licenses included on the SPDX License List. The 
short identifier should follow the general guidelines we provide for here: 
https://spdx.org/spdx-license-list/license-list-overview (see bottom), which 
are in key part:
• Short identifiers have no spaces in them
• Short identifiers consist of an abbreviation based on a common 
short name or acronym for the license or exception
• Where applicable, the abbreviation will be followed by a dash and 
then the version number, in X.Y format
• Where applicable, and if possible, the short identifier should be 
harmonized with other well-known open source naming sources (i.e., OSI, Fedora, 
etc.)
• Short identifiers should be as short in length as possible while 
staying consistent with all other naming criteria

Specifically, when adding other BSD-x-Clause licenses, we have tried to follow 
the same pattern for the identifiers as it aids in identifying what exactly the 
license is, which I think everyone finds helpful!  Hence the use of 
BSD-x-Clause- was intentional and thus, why I suggested such a pattern 
here. I suppose we could add a more generalized note to that effect in the 
guidelines as well.

thanks,
Jilayne


On Jun 1, 2017, at 11:23 AM, W. Trevor King 
> wrote:

On Wed, May 31, 2017 at 9:57PM -0600, J Lovejoy wrote:

Following our existing pattern for variations on BSD (listed below
for reference), we might want to consider:
Full name: BSD 2-clause plus Patent (could also be BSD 2-Clause with
 Patent - as the use of with in the full name is not problematic,
 although arguably not ideal either)
Short Identifier:  BSD-2-Clause-Patent

Since most of the text is the same as the current BSD-2-Clause [1],
you could put the grant (“Subject to the terms and conditions of this
license… estoppel or otherwise.”) in a license exception (and maybe
generalize “exception”?) and users could use:

 BSD-2-Clause WITH BSD-Patent

or whatever if there's a better identifier for the patent grant (who
wrote it?  Maybe it should be OSI-Patent?).

I'm not sure if there's a clear policy for whether a new license that
only adds text to an existing license should be a new SPDX license or
a new SPDX exception, but it's probably worth documenting some
guidelines if there is such a policy.

Cheers,
Trevor

[1]: https://spdx.org/licenses/BSD-2-Clause.html

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

RE: Joint Call: Tuesday, Oct 25th w/Tech Team

[Zavras, Alexios]

I think there has been a misunderstanding.



The "encoding" item on the agenda simply means that there is a proposal to 
standardize on UTF-8 for the file format in which the XML version of the 
licenses (in the SPDX master license repo) are stored.



As to what you should be looking for, in order to extract copyright notices, 
the list is longer than what you include. For example, when reading an HTML 
file, the copyright symbol might be encoded as the characters "" or 
"" (besides the "" that you have). And strings in C or Python code 
might use ""\u00A9"" or "u"\u00A9"", although these are probably not a 
copyright notice for the file itself.





-- zvr -



-Original Message-
From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Mark D. Baushke
Sent: Friday, 21 October, 2016 18:16
To: J Lovejoy 
Cc: SPDX-legal 
Subject: Re: Joint Call: Tuesday, Oct 25th w/Tech Team



Hi Jilayne & Paul,



- Encoding (propose UTF-8)



I have no problem with this. I do think that some folks may not completely 
understand the implications.



I would like to see a table of all of the representations of various copyright 
signs that we need to consider when we extract from a file.



To date I have observed the following:



  (c) - 0x28 0x63 0x29

   (U+0028 U+0063 U+0029)

  (C)- 0x28 0x43 0x29

   (U+0028 U+0043 U+0029)

 - 0xc2 0xa9 (U+00A9) - 'COPYRIGHT SIGN'

 - U+24B8 'circled latin capital letter c'

   - 0x26 0x63 0x6f 0x70 0x79 0x3b

   (U+0026 U+0063 U+006f U+0070 U+0079 U+003b)



Although I have only seen the graphic for the 'SOUND RECORDING COPYRIGHT' on 
labels, I thought it may also be worth mentioning:



  (P)- 0x28 0x50 0x29 (U+0028 U+0050 U+0029)

   - 0xe2 0x84 0x97 (U+2117) 'SOUND RECORDING COPYRIGHT'

   - 0xe2 0x93 0x85 (U+24C5) 'circled latin captial letter p'



Note that I have also seen a bare 0xa9 in a file without the proceeding

0xc2 byte. Tehnically that is not a valid UTF-8 file representation. So, we may 
need to also consider how to handle those kinds of situations.



There are other interesting multiple representations in licenses such as:



  - ''as is'' (uses U+0027) and

  - "as is"   (uses quotation mark U+0022) and

  - as is and

  - as is

  - as is



there may be a few others as well.



I guess the point I am trying to make is that it may be desirable to transcode 
some UTF-8 into a cannonical and recommended encoding form when doing things 
like license extraction.



--

Mark D. Baushke

m...@juniper.net

___

Spdx-legal mailing list

Spdx-legal@lists.spdx.org

https://lists.spdx.org/mailman/listinfo/spdx-legal
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

wrong encoding in two licenses

[Zavras, Alexios]

Hi Gary and Jilayne,

I can't make it to the SPDX Legal call today, but I just want to report that 
two licenses in the git repo are stored with wrong encoding (i.e., they're not 
in utf-8).
I'm talking about OSL-2.1.txt and RPSL-1.0.txt in git.spdx.org/license-list.git.

Running
recode iso8859-1..utf8 OSL-2.1.txt
recode iso8859-1..utf8 RPSL-1.0.txt
should fix the issue.


-- zvr -

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

RE: SPDX License List v2.4 released

[Zavras, Alexios]

Yes, it is ☺
The copyright symbol in the footer (in “© 2016 SPDX Workgroup”) raises the 
parse error, but it is because without the .html extension the browser thinks 
it gets XML instead of HTML.


-- zvr

From: J Lovejoy [mailto:opensou...@jilayne.com]
Sent: Friday, April 08, 2016 7:09 PM
To: Sam Ellis <sam.el...@arm.com>
Cc: Zavras, Alexios <alexios.zav...@intel.com>; SPDX-legal 
<spdx-legal@lists.spdx.org>; Gary O'Neall <g...@sourceauditor.com>
Subject: Re: SPDX License List v2.4 released

I’m removing the general list from this thread, as we can sort out via legal 
team.

Gary - is this related to the issue you and Philippe noticed the other day due 
to the new template??

Jilayne



On Apr 8, 2016, at 11:05 AM, Sam Ellis 
<sam.el...@arm.com<mailto:sam.el...@arm.com>> wrote:

I see an error reported at the top of this page:

https://spdx.org/licenses/Artistic-2.0

The error is:

error on line 213 at column 22: Entity 'copy' not defined

I obtained this URL by searching for “spdx perl artistic license 2.0” in google.

Interestingly there is no error here:

https://spdx.org/licenses/Artistic-2.0.html

Do we deliberately provide two URLs for each license?

From: 
spdx-legal-boun...@lists.spdx.org<mailto:spdx-legal-boun...@lists.spdx.org> 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of J Lovejoy
Sent: 08 April 2016 17:36
To: Zavras, Alexios
Cc: SPDX-legal; SPDX-general
Subject: Re: SPDX License List v2.4 released

Thanks for catching this Alexios - you are right as to where the error is 
coming from…

I’ll work with Gary to fix this.

Jilayne

SPDX Legal Team co-lead
opensou...@jilayne.com<mailto:opensou...@jilayne.com>

On Apr 8, 2016, at 6:52 AM, Zavras, Alexios 
<alexios.zav...@intel.com<mailto:alexios.zav...@intel.com>> wrote:

This license is empty: http://spdx.org/licenses/NLOD-1.0.html
I assume because the reference (at least in the Excel file) is to “NLOD-1..txt” 
instead of “NLOD-1.0.txt”.

-- zvr

From: 
spdx-legal-boun...@lists.spdx.org<mailto:spdx-legal-boun...@lists.spdx.org> 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of J Lovejoy
Sent: Tuesday, April 05, 2016 12:41 AM
To: SPDX-legal <spdx-legal@lists.spdx.org<mailto:spdx-legal@lists.spdx.org>>; 
SPDX-general <s...@lists.spdx.org<mailto:s...@lists.spdx.org>>
Subject: SPDX License List v2.4 released

Hi All,

Version 2.4 of the SPDX License List is now available in the usual places.  We 
added 9 new licenses for this release, including some international licenses 
and newly-approved by the OSI.http://spdx.org/licenses/

You will also notice a new look to the license list pages - this is part of the 
new website revamp.  You will see the new look on the rest of the pages soon!

Thanks,
Jilayne


SPDX Legal Team co-lead
opensou...@jilayne.com<mailto:opensou...@jilayne.com>

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de<http://www.intel.de/>
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

RE: SPDX License List v2.4 released

[Zavras, Alexios]

This license is empty: http://spdx.org/licenses/NLOD-1.0.html
I assume because the reference (at least in the Excel file) is to "NLOD-1..txt" 
instead of "NLOD-1.0.txt".

-- zvr

From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of J Lovejoy
Sent: Tuesday, April 05, 2016 12:41 AM
To: SPDX-legal ; SPDX-general 
Subject: SPDX License List v2.4 released

Hi All,

Version 2.4 of the SPDX License List is now available in the usual places.  We 
added 9 new licenses for this release, including some international licenses 
and newly-approved by the OSI.http://spdx.org/licenses/

You will also notice a new look to the license list pages - this is part of the 
new website revamp.  You will see the new look on the rest of the pages soon!

Thanks,
Jilayne


SPDX Legal Team co-lead
opensou...@jilayne.com

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal