RE: meta-tag page

[Manbeck, Jack]

Wolfgang,

" I wonder if we should turn the comment as we have it now into actual code, i. 
e. into a macro that compiles the license ID into the generated object file.  
We could easily make the linker combine identical tags into a single entry, to 
the total memory overhead would be minimal - but then it would be possible to 
easily find out which components have actually been built into the final 
product, so which licenses apply tho that.  You don;t have to bother about 
license terms for code that you don;t actually use in your product, right?"

Ed (can't remember his last name) from Cisco actually prototyped this and did 
some real examples. He was also capturing the copyrights I believe which did 
make the memory requirements somewhat higher. If we only captured license 
information it would be doable but we would have to decide that the copyright 
info in there was something we could do without or get a different way. Maybe 
we can get Ed to re-post his work. I agree it was nice and solved some thorny 
issues.

Should we also add similar tags to list known patents etc.?  for example, the 
FAT code could be augmented like that:

Interesting tag. I know Yocto does something similar with packages and warning 
that there might be patents in an area. I don't recall the exact language  and 
Im pretty sure they don't list  a specific patent but use an mp3 codec and you 
will see it :). It's useful.

I agree there could be more tags as you suggest. This is one reason why I left 
the door open on the wiki page for that. As an example I would like to see one 
to capture license exceptions. As an example consider FreeRTOS. It could say as 
an example:

SPDX-License-Identifier: GPL-2.0  
SPDX-License-Exception:  " The modification to the GPL is included to allow you 
to distribute a combined work that includes FreeRTOS without being obliged to 
provide the source code for proprietary components outside of the FreeRTOS 
kernel."

 It seems as though we are reaching some consensus on the Identifier and that 
we should be considering other tags as well? I will try and summarize so I can 
update wiki page.


Jack

-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de] 
Sent: Thursday, October 10, 2013 6:43 AM
To: Lamons, Scott (Open Source Program Office)
Cc: Manbeck, Jack; Jilayne Lovejoy; spdx-tech@lists.spdx.org; Meier, Roger; 
SPDX-biz; SPDX-legal
Subject: Re: meta-tag page

Dear Scott,

In message 
<36b44e6fbcd79f48b50fd2e0122f7dce3bab2...@g9w0766.americas.hpqcorp.net> you 
wrote:
> 
> I applaud the your efforts in the u-boot project to clean up the 
> licensing and make a clear choice using the spdx license tag;

Thanks!

>   however 
> I'm not convinced that all projects would be willing or even able to 
> do that and therefore I stand pretty firm in my opinion that it 
> shouldn't be a requirement to do so -- perhaps a recommendation or 
> best practice. IMO, there's still a lot of value in adding the tags 
> because they will enable automated production of SPDX and required 
> notices.

I agree.  Especially for smaller projects with a more homogenous code base 
there is probably not so much benefit to switch.  On the other hand, in complex 
projects (like U-Boot, which borrows code from a lot of other projects, 
including for example the Linux kernel, BusyBox, libfdt, YAFFS, ...) we may be 
faced with a mix of different license terms.  If such code is used in 
commercial projects (where things like license clearing reports become an 
issue), the change can greatly reduce the effort for any such license audits.


Actually I wonder if we should not take the idea even a step further.
So far we only focus on the license terms of the source code.
However, U-Boot is very flexible to configure, and as is it is not trvial to 
tell if a specific piece of code actually gets linked into the final product.  
I wonder if we should turn the comment as we have it now into actual code, i. 
e. into a macro that compiles the license ID into the generated object file.  
We could easily make the linker combine identical tags into a single entry, to 
the total memory overhead would be minimal - but then it would be possible to 
easily find out which components have actually been built into the final 
product, so which licenses apply tho that.  You don;t have to bother about 
license terms for code that you don;t actually use in your product, right?


And there is another topic that's on my mind.  License terms for the source 
code are one thing, but there are is additional information that may be 
relevant when releasing a product, for example (known) patents or other 
intellectual property rights that may apply.  For example, despite the fact 
that all code to implement FAT/VFAT file system support is licensed under 
GPL-2.0+ in U-Boot, we know that Mic

Re: meta-tag page

[Wolfgang Denk]

Dear Scott,

In message 
<36b44e6fbcd79f48b50fd2e0122f7dce3bab2...@g9w0766.americas.hpqcorp.net> you 
wrote:
> 
> I applaud the your efforts in the u-boot project to clean up the
> licensing and make a clear choice using the spdx license tag;

Thanks!

>   however
> I'm not convinced that all projects would be willing or even able to
> do that and therefore I stand pretty firm in my opinion that it
> shouldn't be a requirement to do so -- perhaps a recommendation or
> best practice. IMO, there's still a lot of value in adding the tags
> because they will enable automated production of SPDX and required
> notices.

I agree.  Especially for smaller projects with a more homogenous code
base there is probably not so much benefit to switch.  On the other
hand, in complex projects (like U-Boot, which borrows code from a lot
of other projects, including for example the Linux kernel, BusyBox,
libfdt, YAFFS, ...) we may be faced with a mix of different license
terms.  If such code is used in commercial projects (where things like
license clearing reports become an issue), the change can greatly
reduce the effort for any such license audits.


Actually I wonder if we should not take the idea even a step further.
So far we only focus on the license terms of the source code.
However, U-Boot is very flexible to configure, and as is it is not
trvial to tell if a specific piece of code actually gets linked into
the final product.  I wonder if we should turn the comment as we have
it now into actual code, i. e. into a macro that compiles the license
ID into the generated object file.  We could easily make the linker
combine identical tags into a single entry, to the total memory
overhead would be minimal - but then it would be possible to easily
find out which components have actually been built into the final
product, so which licenses apply tho that.  You don;t have to bother
about license terms for code that you don;t actually use in your
product, right?


And there is another topic that's on my mind.  License terms for the
source code are one thing, but there are is additional information
that may be relevant when releasing a product, for example (known)
patents or other intellectual property rights that may apply.  For
example, despite the fact that all code to implement FAT/VFAT file
system support is licensed under GPL-2.0+ in U-Boot, we know that
Microsoft holds patents on parts of that technology, which may become
an issue if you include VFAT support in your product.

Should we also add similar tags to list known patents etc.?  for
example, the FAT code could be augmented like that:

SPDX-Patent-Notice: US5,579,517 US5,758,352 US5,745,902 US6,286,013 EP0618550

[Of course I'm not sure if SPDX would cover such an entry; I'm just
interested in feedback for the general idea.]


>  I do wonder however if the tag should contain some link or
> reference to the actual license text as discussed in some of the
> other replies to this post. I actually don't like the idea of a link
> because there's really no guarantee it survives the lifespan of the
> code. This suggests to me that centralizing the license text (e.g in
> the root directory or license subdirectory) and some sort of
> reference to the file level tagging needs to be part of our
> recommendation or best practice.

I fully agree that just providing an URL to the (current) location of
a license is not sufficient, as we have zero control of the location
or content of such documents - they may disappear or be modified any
time, which would leave the license terms of our project undefined.
I think iti is mandatory to include a verbatim copy of the applicable
license texts as part of the source code of the project.

> Thanks for your feedback and helping us "blaze the trail" on this initiative.

Thanks for picking it up - I'm glad to see things get rolling!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"An organization dries up if you don't challenge it with growth."
   - Mark Shepherd, former President and CEO of Texas Instruments
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page

[Lamons, Scott (Open Source Program Office)]

Hi Wolfgang,

I applaud the your efforts in the u-boot project to clean up the licensing and 
make a clear choice using the spdx license tag; however I'm not convinced that 
all projects would be willing or even able to do that and therefore I stand 
pretty firm in my opinion that it shouldn't be a requirement to do so -- 
perhaps a recommendation or best practice.   IMO, there's still a lot of value 
in adding the tags because they will enable automated production of SPDX and 
required notices. I do wonder however if the tag should contain some link 
or reference to the actual license text as discussed in some of the other 
replies to this post.   I actually don't like the idea of a link because 
there's really no guarantee it survives the lifespan of the code.This 
suggests to me that centralizing the license text (e.g in the root directory or 
license subdirectory) and some sort of reference to the file level tagging 
needs to be part of our recommendation or best practice.

Thanks for your feedback and helping us "blaze the trail" on this initiative.

Regards,
Scott


-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de] 
Sent: Sunday, October 06, 2013 12:23 PM
To: Lamons, Scott (Open Source Program Office)
Cc: Manbeck, Jack; Jilayne Lovejoy; spdx-tech@lists.spdx.org; SPDX-biz; 
SPDX-legal
Subject: Re: meta-tag page

Dear Scott,

On Oct 3, 2013, at 12:33 PM, "Lamons, Scott (Open Source Program Office)" 
mailto:scott.lam...@hp.com> wrote:
> 
> Thanks for updating this page. In particular for adding the rationale 
> for why tagging is important in the Introduction section. For me, the 
> main impetus of adding the license tag is to automate the production 
> of accurate SPDX data. To the extent that licensing headers are 
> already included in the file I'm not a fan of replacing that with the 
> tag - rather, I think our (the SPDX workgroup that is) recommendation 
> or best practice should be that the tag should supplement the other 
> licensing information. But, in the end, it is the ultimate choice of 
> the copyright holder of the software because they will be the party 
> implementing this should they choose to adopt.

First of all I would like to point out that I am not an expert in this field, 
and even more so, I am not a lawyer...

The base of my comment is the practical experience I gathered when introducing 
license tags to the U-Boot project; as far as I understand this is one of the 
first (the first?) where this has been doene in a real software project of some 
size.

I disagree with keeping the full license header text when adding license tags; 
this means duplicating information, which means the risk of divergence.  For us 
in the U-Boot project it has been one of the major goals when introducing 
license tags to clean up with redundant and all too often inconsistent 
information, and I think the same should be attempted by other projects, too.

Switching from license headers to license tags requires some careful work, but 
this effrot should be invested only once, and then everybody should be able to 
rely on the recorded (and easily parsable) information of the license tags.  If 
you keep the full license tags duplicated in the source files, you in each 
review have to make sure that this is still what it (probably) was then the 
license tag was added.  In the end, you add to the efforts instead of reducing 
it.


I also disagree on the part that such a modification is "ultimate choice of the 
copyright holder".  Actually it is only a formal change, not different from 
other modifications of the code.  We are in no way changing the actual license 
terms that apply to that code.  As far as I understand, such per-file license 
headers or license tags are not even legally needed at all (see statement of 
Daniel B. Ravicher, Legal Director of SLFC as referenced here [1]) if "the 
project as a whole is licensed under clear terms".

In the interest of reducing the efforts for any kind of license clearing audits 
I strongly vote to drop the then redundant license header text when switching 
to license tags.

Thanks.

[1] 
git.denx.de/?p=u-boot.git;a=commit;h=eca3aeb352c964bdb28b8e191d6326370245e03f


Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de 
Computers are not intelligent.  They only think they are.
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page - part II

[Bradley M. Kuhn]

Wolfgang Denk wrote at 04:42 (EDT):
> the files are now licensed under GPL-2.0, i. e. the "or later" option
> had to be dropped for the file as a whole, because it was not
> available for the parts imported from Linux.

Files aren't copyright-magical-single-units.  Nothing in the copyright
statute talks about how licenses go with "files".  Licenses go with
works, and works can be merged, combined together, derived from, etc. to
form new works which incorporate both its antecedents.  Technologically,
if you can "get back" to the original work and be sure that other works
aren't mingled with it, then you are back to the original license.  The
"easy way" to do this is keep separately licensable works in different
files, but that's not the only way.

Thus, while splitting a file back up into parts that are GPLv2-only and
GPLv2-or-later is difficult, it's not impossible, and you definitely
"change the outcome by observing it" if you declare the license of a
whole file to be GPLv2-only simply because some copyrightable material
that was GPLv2-only was brought in.


That said, I'm not a fan of this obsession to try to get "perfect
information" about the license of a work, or its files, or anything
else.  It doesn't actually help compliance in ways that matter.
-- 
   -- bkuhn
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[dmg]

On Mon, Oct 7, 2013 at 3:03 PM, Wolfgang Denk  wrote:
>
>> Note also that the license is not exactly spdx-BSD3 (it will not match
>> the guideliness of SPDX because of the extra clause). So in a way, the
>> SPDX license in this file is incorrect.
>
> I don't see what you mean here.  If we remove the "ALTERNATIVELY"
> part, the remainder of the license header matches exactly the BSD
> 3-clause "New" or "Revised" License as listed at
> http://spdx.org/licenses/BSD-3-Clause#licenseText
>
> Or am I missing something?

That is exactly what I mean. You make the decision (based on your
interpretation) to remove the extra clause.
With that extra clause, the license is NOT spdx BSD-3 as defined today.

If you modify the license statement, you are making an interpretation.
So you have interpreted that LICENSE
(with the embedded optional GPL clause) as an OR of BSD3 and GPLv2+.

In my view the license in file is the one stated inside it
(unmodified). The effective license is a BSD3 or GPLv2+.

--daniel

-- 
--dmg

---
Daniel M. German
http://turingmachine.org
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page - part II

[Wheeler, David A]

Wolfgang Denk [mailto:w...@denx.de] 
> But there there is no actual choice.  Yes, you take the parts of the project 
> that do not include the GPL code - and you can use this code under the MIT 
> license for other purposes.  But as soon as we talk about the thing as a 
> whole (say, the linked binary), then you do not have any choice, then it's 
> GPL.  GPL without any ORs or ANDs.

Ah, but these are not linked binaries.  These are scripts, and it's trivial to 
remove one of the scripts & the rest of the software is straight-up MIT.  Even 
for the MIT+GPLv2 script, it's trivial to remove a certain set of lines to make 
it MIT-only.

Also: We agree that the effect of "MIT AND GPLv2", legally, is just "GPLv2"... 
but some other license combinations do not simplify so easily.

Anyway, I think it's important to be able to express more complex situations 
than "this file has license X".  In many cases, a file has multiple licenses, 
not one license; being able to express that situation is very helpful.

-- David A. Wheeler

___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page - part II

[Wolfgang Denk]

Dear David,

In message <9f8e44bc27e22046b84ec1b9364c66a1a8054ab...@exch07-4850.ida.org> you 
wrote:
>
> Note this comment:
> # Except as otherwise marked, this code is licensed under the "MIT license".
> # However, the "override" code that patches clisp is derived
> # from clisp, which is GPLv2.
> # Thus consider the work as a whole as "MIT and GPLv2".

IANAL, but from t strictly legal point of view "the work as a whole"
is definitly GPLv2.  You cannot release it under MIT terms (i. e.
without offering the source code).

> I agree with you that, from a *legal* standpoint, if you accept the
> WHOLE file you end up with just the GPLv2 requirements. But knowing

ACK.

> that there's a variance matters; it's quite possible to extract a
> part and end up with just the MIT portions.

As a developer I think you should avoid to mix such code in a single
source file.  Instead, you should split it into files with clear
license terms for each of them.   Otherwise you will end up with an
inextricable mess.

> This one file is part of a larger system that is mostly MIT, but
> has this one GPLv2 file. Claiming it's just "GPLv2" would be very
> misleading. Being able to report the options, collected with AND and
> OR, is very helpful.

But there there is no actual choice.  Yes, you take the parts of the
project that do not include the GPL code - and you can use this code
under the MIT license for other purposes.  But as soon as we talk
about the thing as a whole (say, the linked binary), then you do not
have any choice, then it's GPL.  GPL without any ORs or ANDs.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Though a program be but three lines long,
someday it will have to be maintained."
- The Tao of Programming
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[Wolfgang Denk]

Dear Daniel,

In message  
you wrote:
>
> Correct me if I am wrong, but u-boot is not licensed under the GPLv2+,
> but under the GPLv2+ with a special exception:

Actually if you look at U-Boot as a whole, it is GPL-2.0 only.  There
are large parts that are GPL-2.0+, and we try to have newly added code
licensed under GPL-2.0+ as well, but there are large parts of code
that were imported from other projects (mainly the Linux kernel) which
are GPL-2.0 only.  I dare to say that you cannot easily build a
reasonably powerful configuration of U-Boot that does not include
GPL-2.0 only code, so the resulting licese for U-Boot as a whole is
GPL-2.0 only, plus the exception you mention.

> so the SPDX license identifier is incomplete for your particular intentions.

We never tried to assign a license ID to the project as a whole; the
README attempts to describe the status quo.  If somebode asks for a
precise statement we have to tell him what I explained above: GPL-2.0
only plus the exception for standalone programs.

> Interestingly, if I take a single file from u-boot and reuse it, the
> exception will probably not be relevant.

Correct.

> Now, with regard to complex licensing, take for example the file:
> 
> ./drivers/usb/gadget/f_mass_storage.c in U-boot.
...
> the file in u-boot replaces this notice with:
...
>  * SPDX-License-Identifier: GPL-2.0+BSD-3-Clause
...
> now, it is not clear the the license of the file is. For your purposes
> (as a consumer of f_mass_storage.c) is probably enough.
> But now it is not clear that the file can be used under either the
> BSD-3 or the GPLv2+ if somebody cherry picks the file (as you did).

You are right in so far, as the current version of our Licenses/README
does not contain a definition yet how such a line with multiple
license IDs shall be interpreted.  This is one of the things we still
have to fix.  Sorry, but this is still work in progress, and we're
trying to figure out how to deal with such things efficiently as we go.

Assume we add a phrase like: "If a "SPDX-License-Identifier:" line
references more than one Unique License Identifier, then this means
that the respective file canbe used under the terms of either of these
licenses."

Do you think this would be sufficient to solve the problem you have
spottet?

[Thanks for pointing out.  I remember I had this on my list some time
ago, but obviously I forgot about it.]


> Note also that the license is not exactly spdx-BSD3 (it will not match
> the guideliness of SPDX because of the extra clause). So in a way, the
> SPDX license in this file is incorrect.

I don't see what you mean here.  If we remove the "ALTERNATIVELY"
part, the remainder of the license header matches exactly the BSD
3-clause "New" or "Revised" License as listed at
http://spdx.org/licenses/BSD-3-Clause#licenseText

Or am I missing something?

> For the ones that are not author by you, you are making a licensing
> analysis and conclusion before you can use
> an SPDX identifier.

Yes, that's true.  Actually this is the whole purpose of the action;
we try to perform this work once and record the results in an easily
parable way, instead of having everybody who has to get some license
clearing to do this over and over again.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A verbal contract isn't worth the paper it's written on.
-- Samuel Goldwyn
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page - part II

[Wheeler, David A]

Wolfgang Denk [mailto:w...@denx.de]:
> But this example doesn't work either.  If you mix a license that allows 
> "modify and keep the modified code closed" with GPL, the only legally 
> possible result is GPLed code.
> I see little value in constructing such more or less artificial examples.

This is not artificial.  Here's code that I wrote:
http://sourceforge.net/p/readable/code/ci/master/tree/src/sweet-clisp

Note this comment:
# Except as otherwise marked, this code is licensed under the "MIT license".
# However, the "override" code that patches clisp is derived
# from clisp, which is GPLv2.
# Thus consider the work as a whole as "MIT and GPLv2".

I agree with you that, from a *legal* standpoint, if you accept the WHOLE file 
you end up with just the GPLv2 requirements.  But knowing that there's a 
variance matters; it's quite possible to extract a part and end up with just 
the MIT portions.

This one file is part of a larger system that is mostly MIT, but has this one 
GPLv2 file.  Claiming it's just "GPLv2" would be very misleading.  Being able 
to report the options, collected with AND and OR, is very helpful.

--- David A. Wheeler

___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page

[Wheeler, David A]

I said:
David> From a programmer's perspective I think the "cryptic" approach is FAR 
superior.  There are lots of tools that can quickly examine files and return 
text with the pattern "SPDX-License-Identifier: ", and other tools that can 
trivially process the stuff after it.  The above  alternative is more work to 
process, and humans don't like unnecessary work :-).

D M German:
>When you say "programmer" who do you mean? The author of the software, the one 
>who is thinking about using the file, or a large organization who wants to 
>scan massive amounts of code?

I was focusing on the first two, and I agree with Wolfgang Denk:
"For a software developer, there is no sharp line here.  While creating new 
software, we frequently borrow from existing code, so we are creators and 
consumers at the same time.

However, the "large organization" case is also plausible.  Large organizations 
in practice will depend on technical people to get the information; it helps to 
make a common task easy for the technical people.

--- David A. Wheeler


___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page - part II

[Wolfgang Denk]

Dear Gary,

In message <002f01cec378$2f2a3470$8d7e9d50$@com> you wrote:
> 
> If there is no conflict in license terms, however, I do not see an issue
> in using this approach. I run across a large volume of MIT style and BSD
> style licenses mixed in with GPL code, for example.  Using "AND'd"
> licenses is a compact way of stating all of the terms from license A and
> all of the terms for license B apply.

But this example doesn't work either.  If you mix a license that
allows "modify and keep the modified code closed" with GPL, the only
legally possible result is GPLed code.

I see little value in constructing such more or less artificial
examples.  All code that I've seen so far in real life was either
simple, i. e. covered by a single license, or it came under two (I'd
have to think hard if I had to quote an example with more than two)
licenses, which would implement a choice - either you use the code
under GPL, or under a BSD license; either you use the commercial
license, or GPL.  It has always been  or .

Things become more difficult when importing such code into another
project - then you usually have to decide which of the available
choices you chose, and go with that.  At this point, the other option
becomes void.

> I don't think it is critical to use the same syntax in the tagging as we
> do in the SPDX documents.  I do, however, think it is important that we
> don't lose any embedded licensing information.  For example, if there is
> an MIT notice stuck in the middle of a GPL licensed file, we should
> retain that information and not just call it a "GPL" licensed file.

True.  The clause "The above copyright notice and this permission
notice shall be included in all copies or substantial portions of the
Software." explicitly requires that.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Beware of programmers carrying screwdrivers."  - Chip Salzenberg
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page - part II

[Wolfgang Denk]

Dear Daniel,

In message <87ob71qey8@mn.cs.uvic.ca> you wrote:
> 
>  Wolfgang> Also, in the interest of easy processing of the license tags, I 
> wouls
>  Wolfgang> like to propse that multiple licenses in a list are separated by 
> white
>  Wolfgang> space only - no "OR", no commas, nor any other artificial 
> delimiters
>  Wolfgang> that will only make parsing the information more difficult.
> 
> 
> I feel that the main challenge with adoption is that our discussions are
> centered around those that "consume" open source, and no those that
> create it. The main discussions so far have been about making it easy to
> parse (for downstream tools) in order to simplify compliance.

For a softeare developer, there is no sharp line here.  While creating
new software, we frequently borrow from existing code, so we are
creators and consumers at the same time.

> I think that, if SPDX is to succeed, the ones who need to be involved in
> this discussion are the developers. Since we can't involve them "all" we
> can use their representatives, the big foundations: Apache, FSF,
> Mozilla, GNOME, KDE, and Linux.

Full agreement here.  No matter how nice the theory and the
specifications are, the implementation must fit nicely into the
regular work flow of the developers.  We all are more than busy, so
additional efforts will always be frowned upon, while anything that
makes our life easier is highly appreciated.  Short, self-explanatory
"macro definitions" like the SPDX license IDs instead of voluminous
license headers is something that I like very much, as it condenses
the legally necessary information to a level where the unavoidable
bureaucratic overhead is really minimized.  I am pretty much sure that
other developpers feel the same.

> Now, with respect to guidelines, it seems that there are several
> approaches, each providing a different level of precision in the
> information:
> 
> 0. Status quo. Project does nothing and everything states the same.
> 
> 1. Label the license statement in file (where it is located). Inside
>indicate the licenses under which the file is licensed. This has to
>be consistent with the current rules of the project/Foundation.
> 
> 2. Label the license under which the file is licensed using SPDX
>identifiers 
> 
> 3. Label the license under which the file is licensed using an SPDX such
>   that it is easy to use automatic tools for its analysis.
> 
> Perhaps each of these can be called a level of "maturity" in license
> compliance for the upstream package at the file level. Most are at label
> 0 now. Some projects (most Apache's) are in level 1.  In fact, they are
> easy to automatically analyze because of that.
> 
> Levels 2 and 3 would be towards SPDX-ing their license statements in
> file.

What I'm trying to do (unfortunaltely with less bandwith that I'd like
to) is pushing the U-Boot project toward level 3.  Before I started, I
talked to a number of the most active developers.  Judging from their
initial response, and from the feedback on my patches on the U-Boot
mailing list, I think this is the way to go.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
All he had was nothing, but that was something, and now it  had  been
taken away. - Terry Pratchett, _Sourcery_
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[dmg]

On Sun, Oct 6, 2013 at 2:48 PM, Wolfgang Denk  wrote:
>
> The approach the U-Boot project has taken here attempts to support
> Strong Compliance while at the same time getting rid of redundant
> information to the extend possible:
>
> - The file "Licenses/README" contains the project-global license
>   statement plus explanations how license tags are used in the
>   individual files.
>
> - A file "Licenses/Exceptions" deals with special exceptions from the
>   rule.

hi Wolfgang,

Correct me if I am wrong, but u-boot is not licensed under the GPLv2+,
but under the GPLv2+ with a special exception:


GPL License Exception:

Even though U-Boot in general is covered by the GPL-2.0/GPL-2.0+,
this does *not* cover the so-called "standalone" applications that
use U-Boot services by means of the jump table provided by U-Boot
exactly for this purpose - this is merely considered normal use of
U-Boot, and does *not* fall under the heading of "derived work".

  The header files "include/image.h" and "arch/*/include/asm/u-boot.h"
define interfaces to U-Boot.  Including these (unmodified) header
files in another file is considered normal use of U-Boot, and does
*not* fall under the heading of "derived work".
-- Wolfgang Denk


so the SPDX license identifier is incomplete for your particular intentions.

Interestingly, if I take a single file from u-boot and reuse it, the
exception will probably not be relevant.

Now, with regard to complex licensing, take for example the file:

./drivers/usb/gadget/f_mass_storage.c in U-boot.

If I understand correctly, this file is the same as
drivers/usb/gadget/f_mass_storage.c in the kernel (a typical case of
reuse).
This is its original license statement:

/*
  2  * f_mass_storage.c -- Mass Storage USB Composite Function
  3  *
  4  * Copyright (C) 2003-2008 Alan Stern
  5  * Copyright (C) 2009 Samsung Electronics
  6  *Author: Michal Nazarewicz 
  7  * All rights reserved.
  8  *
  9  * Redistribution and use in source and binary forms, with or without
 10  * modification, are permitted provided that the following conditions
 11  * are met:
 12  * 1. Redistributions of source code must retain the above copyright
 13  *notice, this list of conditions, and the following disclaimer,
 14  *without modification.
 15  * 2. Redistributions in binary form must reproduce the above copyright
 16  *notice, this list of conditions and the following disclaimer in the
 17  *documentation and/or other materials provided with the distribution.
 18  * 3. The names of the above-listed copyright holders may not be used
 19  *to endorse or promote products derived from this software without
 20  *specific prior written permission.
 21  *
 22  * ALTERNATIVELY, this software may be distributed under the terms of the
 23  * GNU General Public License ("GPL") as published by the Free Software
 24  * Foundation, either version 2 of that License or (at your option) any
 25  * later version.
 26  *
 27  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
 28  * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 29  * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 30  * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 31  * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 32  * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 33  * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
 34  * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
 35  * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
 36  * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 37  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 38  */
 39


the file in u-boot replaces this notice with:


/*
 * f_mass_storage.c -- Mass Storage USB Composite Function
 *
 * Copyright (C) 2003-2008 Alan Stern
 * Copyright (C) 2009 Samsung Electronics
 *Author: Michal Nazarewicz 
 * All rights reserved.
 *
 * SPDX-License-Identifier: GPL-2.0+BSD-3-Clause
 */

now, it is not clear the the license of the file is. For your purposes
(as a consumer of f_mass_storage.c) is probably enough.
But now it is not clear that the file can be used under either the
BSD-3 or the GPLv2+ if somebody cherry picks the file (as you did).

Note also that the license is not exactly spdx-BSD3 (it will not match
the guideliness of SPDX because of the extra clause). So in a way, the
SPDX license in this file is incorrect.

that is fundamentally the problem of trying to be too aggressive with
decoding and translating the license statements of files.
For the ones that you have created (lots in U-boot) you can easily
state your license statement.
For the ones that are not author by you, you are making a licensing
analysis and conclusion before you can use
an SPDX identifier.



--dmg


-- 
--dmg

---
Dani

RE: meta-tag page - part II

[Gary O'Neall]

Hi Wolfgang,

I agree that if a conflict in licenses exist (as in your example) you cannot 
just "AND" the licenses together since that leads to conflicting terms.  IMO 
you are taking the right approach in resolving the conflict and recording a 
non-conflicting license in the file.

If there is no conflict in license terms, however, I do not see an issue in 
using this approach. I run across a large volume of MIT style and BSD style 
licenses mixed in with GPL code, for example.  Using "AND'd" licenses is a 
compact way of stating all of the terms from license A and all of the terms for 
license B apply.

I don't think it is critical to use the same syntax in the tagging as we do in 
the SPDX documents.  I do, however, think it is important that we don't lose 
any embedded licensing information.  For example, if there is an MIT notice 
stuck in the middle of a GPL licensed file, we should retain that information 
and not just call it a "GPL" licensed file.

BTW - the issue of conflicting licenses is still an open issue as to whether we 
use the "AND'd" licenses to record the any conflicting licenses found within 
the same SPDX package or file.

Gary

-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de] 
Sent: Monday, October 07, 2013 1:42 AM
To: Gary O'Neall
Cc: 'Wheeler, David A'; 'SPDX-legal'; spdx-tech@lists.spdx.org; 'SPDX-biz'; 
d...@uvic.ca
Subject: Re: meta-tag page - part II

Dear Gary,

In message <001f01cec2e5$9f1d9b20$dd58d160$@com> you wrote:
> 
> The "AND" situation would occur if you have a file which contains code 
> from two or more different sources using two or more different 
> licenses.  In that case, I believe you would need to satisfy the 
> obligations of all licenses
> (note: I'm not a lawyer so I am not proposing or providing a legal 
> interpretation).  Hopefully there is no conflict between the license 
> obligations.

I don't think this could work.

We encountered such cases when we analyzed the U-Boot code while introducing 
license tags.  There were some files that came with a the full GPL-2.0+ license 
header, but further down in the code that had a short comment that some parts 
(a few functions) have been copied from the Linux kernel.  The analysis shows 
that the original Linux kernel files were covered by GPL-2.0 only.

If I follow your argument, this code would now be covered by a "GPL-2.0+ AND 
GPL-2.0" license construct.  This is obviously absurd: I cannot both include 
and exclude the "or later" option simultaneously.


Our understanding of the legal situation left two solutions:  either we remove 
the GPL-2.0 code (and replace it by a clean-room implementation of similar 
functionality), or we change the file's license terms to GPL-2.0.  We did the 
latter:  the files are now licensed under GPL-2.0, i. e. the "or later" option 
had to be dropped for the file as a whole, because it was not available for the 
parts imported from Linux.

There was no way to "AND" both licenses here.


> ---
> For a license set, when there is a choice between licenses 
> ("disjunctive license"), they should be separated with "or" and enclosed in 
> parentheses.
> When multiple licenses apply ("conjunctive license"), they should be 
> separated with an "and" and enclosed in parentheses.  Example: 
> (LGPL-2.1 or MPL-1.1).
> ---

Do you have an example, where such a "conjunctive license" construct actually 
works?

> We were also concerned about the difficulty in parsing the strings.  
> We came up with enclosing them in parenthesis to aid in accurate and 
> unambiguous parsing.  For example, (LGPL-2.1 and (MPL-1.1 or 
> BSD-3-Clause)) would describe the licensing for a file which contains 
> code from an LGPL 2.1 package and code from a package licensed under a 
> choice of MPL-1.1 or BSD-3-Clause.

Understood.  However, I think these are only very few pathological cases, and 
it would be nice to keep the syntax simple for the overwhelming majority of 
practical use cases.  My vote goes for a simple white speace separated list of 
license IDs which should be interpreted as "OR".  Do you think it would be 
possible to extend the spec to allow for the (much easier to parse)

  [...]

as synonym for

( OR  [OR ...])

?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Steal 
five dollars and you were a petty  thief.  Steal  thousands  of dollars and you 
are either a government or a hero.
   - Terry Pratchett, _Going_Postal_

___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[D M German]

 David> Dmg:
 >> Following this rational, would it be possible to recommend something in the 
 >> line of:
 >> BEGIN_LICENSE
 >> This file is licensed under the 
 >> For more information see URL-TO-SPDX-WEB-SITE-WITH-iNFO
 >> END_LICENSE
 >> that makes three things explicit:
 >> 
 >> * It says where the license info in -file is (BEGIN, END_LICENSE)
 >> * It explicitly states the file is licensed under the given licence
 >> * It says where to get more information to understand what it means.

 >> Jack's way of doing it, by just naming the license feels too cryptic
 >> to me if I am reading the header, and does not explicitly state it
 >> is the license under which the file is made available to others

 David> From a programmer's perspective I think the "cryptic" approach is FAR
 David> superior.  There are lots of tools that can quickly examine files and
 David> return text with the pattern "SPDX-License-Identifier: ", and other
 David> tools that can trivially process the stuff after it.  The above
 David> alternative is more work to process, and humans don't like unnecessary
 David> work :-).

When you say "programmer" who do you mean? The author of the software,
the one who is thinking about using the file, or a large organization
who wants to scan massive amounts of code?



--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

 
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page - part II

[D M German]

e for meta-tagging. We use it internally and we 
evangelized it at the Linux Collab Summit back in April. My main concern is: if 
we don't choose a sufficiently expressive syntax, and end up losing 
information, then we will have done more damage to SPDX than good. It needs to 
represent NOTICES and not just a single license. Mega-tagging should NOT be a 
replacement for traditional file license NOTICES. It should augment their 
existence in support of greater automation.

 Mark> We might want to consider a syntax that could support moderately complex 
NOTICE expressions. For example, we might consider a syntax similar to html:
   

 Mark> Note that the choice of key word here is not SPDX-License-"Identifier" 
but one that would suggest a license *expression*. Again, to my point above, we 
want to represent the file license NOTICE terms and therefore be less license 
"identifier" centric. We also may want to consider a syntax that is extensible 
via *optional* parameters. For example, having the ability to include the 
license list version would important.

   
 Mark> Or
   http://wiki.spdx.org />

 Mark> While simple things are still relatively simple:

   

 Mark> I attached one of the file examples we used at the Linux Collab Summit 
2013 (see attachment 4). We still see flaws in this approach but it does 
address the issues highlighted above. We are not wedded to a particular syntax. 
We are wedded to obtaining better information to generate the required 
artifacts needed for achieving strong compliance (see attachment 5). One of our 
guiding principles is: how can we support strong compliance in a cost effective 
manner. SPDX 1.x has taken us to the next level. With the right tagging syntax 
we can go much higher.

 Mark> - Mark


 Mark> Mark Gisi | Wind River | Senior Intellectual Property Manager
 Mark> Tel (510) 749-2016 | Fax (510) 749-4552


 Mark> -Original Message-
 Mark> From: spdx-biz-boun...@lists.spdx.org 
[mailto:spdx-biz-boun...@lists.spdx.org] On Behalf Of D M German
 Mark> Sent: Thursday, October 03, 2013 7:50 PM
 Mark> To: Wheeler, David A
 Mark> Cc: spdx-tech@lists.spdx.org; SPDX-biz; SPDX-legal
 Mark> Subject: Re: meta-tag page


 Wheeler, David A twisted the bytes to say:


 David> From a programmer's perspective I think the "cryptic" approach
 David> is FAR David> superior.  There are lots of tools that can
 David> quickly examine files and David> return text with the pattern
 David> "SPDX-License-Identifier: ", and other David> tools that can
 David> trivially process the stuff after it.  The above David>
 David> alternative is more work to process, and humans don't like
 David> unnecessary David> work :-).

 David> If you want more boilerplate with the goal of enforceability, you  
David> might try a format that's trivial to process, e.g.:

 David> SPDX-License-Notice:  This file is licensed under the following 
license(s):
 David> SPDX-License-Identifier:  MIT
 David> SPDX-License-More-Information:  http://wiki.spdx.org/

 Mark> I like this idea.

 Mark> My point is not about being cryptic or not, but being able to convey 
what the intention is to people who don't know anything about SPDX. There needs 
to be a way that if somebody opens the file, they know that that 
SPDX-License-Identifier means, and that it is an intention to license the file 
under that license. 

 Mark> Now regarding the immutability of the SPDX license list, one way to deal 
with it is to version the list, but then the version of the list would have to 
be included in the file that is referring to the license.

 Mark> --dmg



 Mark> --
 Mark> Daniel M. German  "A coin symbolizes our free will"
   El Zahír, Jorge Luis Borges 
http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca 
replace (at) with @ and (dot) with .

 
 Mark> ___
 Mark> Spdx-biz mailing list
 Mark> spdx-...@lists.spdx.org
 Mark> https://lists.spdx.org/mailman/listinfo/spdx-biz






--
Daniel M. German  "If Microsoft ever does applications
   Linus Torvalds ->   for Linux it means I've won."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

 
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page - part II

[Manbeck, Jack]

>> If I follow your argument, this code would now be covered by a "GPL-2.0+ AND 
>> GPL-2.0" license construct.  This is obviously absurd: I cannot both include 
>> and exclude the "or later" option simultaneously.


Why not? I'm thinking you can under GPLv2 as it applies to this entire file. As 
to whether it would make sense in some larger context that could certainly be 
discussed.

Jack


-Original Message-
From: spdx-biz-boun...@lists.spdx.org [mailto:spdx-biz-boun...@lists.spdx.org] 
On Behalf Of Wolfgang Denk
Sent: Monday, October 07, 2013 4:42 AM
To: Gary O'Neall
Cc: spdx-tech@lists.spdx.org; 'SPDX-legal'; 'SPDX-biz'; 'Wheeler, David A'; 
d...@uvic.ca
Subject: Re: meta-tag page - part II

Dear Gary,

In message <001f01cec2e5$9f1d9b20$dd58d160$@com> you wrote:
> 
> The "AND" situation would occur if you have a file which contains code 
> from two or more different sources using two or more different 
> licenses.  In that case, I believe you would need to satisfy the 
> obligations of all licenses
> (note: I'm not a lawyer so I am not proposing or providing a legal 
> interpretation).  Hopefully there is no conflict between the license 
> obligations.

I don't think this could work.

We encountered such cases when we analyzed the U-Boot code while introducing 
license tags.  There were some files that came with a the full GPL-2.0+ license 
header, but further down in the code that had a short comment that some parts 
(a few functions) have been copied from the Linux kernel.  The analysis shows 
that the original Linux kernel files were covered by GPL-2.0 only.

If I follow your argument, this code would now be covered by a "GPL-2.0+ AND 
GPL-2.0" license construct.  This is obviously absurd: I cannot both include 
and exclude the "or later" option simultaneously.


Our understanding of the legal situation left two solutions:  either we remove 
the GPL-2.0 code (and replace it by a clean-room implementation of similar 
functionality), or we change the file's license terms to GPL-2.0.  We did the 
latter:  the files are now licensed under GPL-2.0, i. e. the "or later" option 
had to be dropped for the file as a whole, because it was not available for the 
parts imported from Linux.

There was no way to "AND" both licenses here.


> ---
> For a license set, when there is a choice between licenses 
> ("disjunctive license"), they should be separated with "or" and enclosed in 
> parentheses.
> When multiple licenses apply ("conjunctive license"), they should be 
> separated with an "and" and enclosed in parentheses.  Example: 
> (LGPL-2.1 or MPL-1.1).
> ---

Do you have an example, where such a "conjunctive license" construct actually 
works?

> We were also concerned about the difficulty in parsing the strings.  
> We came up with enclosing them in parenthesis to aid in accurate and 
> unambiguous parsing.  For example, (LGPL-2.1 and (MPL-1.1 or 
> BSD-3-Clause)) would describe the licensing for a file which contains 
> code from an LGPL 2.1 package and code from a package licensed under a 
> choice of MPL-1.1 or BSD-3-Clause.

Understood.  However, I think these are only very few pathological cases, and 
it would be nice to keep the syntax simple for the overwhelming majority of 
practical use cases.  My vote goes for a simple white speace separated list of 
license IDs which should be interpreted as "OR".  Do you think it would be 
possible to extend the spec to allow for the (much easier to parse)

  [...]

as synonym for

( OR  [OR ...])

?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Steal 
five dollars and you were a petty  thief.  Steal  thousands  of dollars and you 
are either a government or a hero.
   - Terry Pratchett, _Going_Postal_ 
___
Spdx-biz mailing list
spdx-...@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-biz
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page - part II

[D M German]

 Wolfgang> Dear David,
 Wolfgang> In message 
<9f8e44bc27e22046b84ec1b9364c66a1a8054aa...@exch07-4850.ida.org> you wrote:
 >> 
 >> SPDX-License-Identifier:  LGPL-2.1 OR MPL-1.1
 Wolfgang> ...
 >> In general, we all want both simplicity (so people will USE it) and
 >> expressiveness (so it can be USEFUL). The trick is getting there...

 Wolfgang> I dislike this idea.  Combining alternative liceses (where the user
 Wolfgang> can chose any of them) by anyhting alse but an "OR" does not make
 Wolfgang> sense.  I cannot imagine how you woudl apply two licesnese (like, 
say,
 Wolfgang> GPL and BSD) simultaneously.

 Wolfgang> Also, in the interest of easy processing of the license tags, I wouls
 Wolfgang> like to propse that multiple licenses in a list are separated by 
white
 Wolfgang> space only - no "OR", no commas, nor any other artificial delimiters
 Wolfgang> that will only make parsing the information more difficult.


I feel that the main challenge with adoption is that our discussions are
centered around those that "consume" open source, and no those that
create it. The main discussions so far have been about making it easy to
parse (for downstream tools) in order to simplify compliance.

I think that, if SPDX is to succeed, the ones who need to be involved in
this discussion are the developers. Since we can't involve them "all" we
can use their representatives, the big foundations: Apache, FSF,
Mozilla, GNOME, KDE, and Linux.

They are the ones that have the cloud to convince developers to use a
standard format (in fact, most of them do, to a certain extent). 

I think we need to ask them for feedback, and try to get a consensus
WITH THE upstream developers of what a good guideline should
be. Otherwise the guidelines will fall in deaf ears.

Now, with respect to guidelines, it seems that there are several
approaches, each providing a different level of precision in the
information:

0. Status quo. Project does nothing and everything states the same.

1. Label the license statement in file (where it is located). Inside
   indicate the licenses under which the file is licensed. This has to
   be consistent with the current rules of the project/Foundation.

2. Label the license under which the file is licensed using SPDX
   identifiers 

3. Label the license under which the file is licensed using an SPDX such
  that it is easy to use automatic tools for its analysis.

Perhaps each of these can be called a level of "maturity" in license
compliance for the upstream package at the file level. Most are at label
0 now. Some projects (most Apache's) are in level 1.  In fact, they are
easy to automatically analyze because of that.

Levels 2 and 3 would be towards SPDX-ing their license statements in
file.

--dmg




--
Daniel M. German  "Give a man a password,
   he'll log in for a day.
   Teach him to code,
   Anonymous ->and he will hack his way in..."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

 
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[Philip Odence]

Wolfgang,
I liked Bradley's suggestion for syntax of the one-liner because it was
also short, but slightly more explicit about the intention. I agree that
an explanation in a readme could make this clear, but I think we are
trying to handle the case when the file might turn up in another project
without the readme file. In this case there is some benefit to something
equally compact, but slightly clearer to a human.
Phil

On 10/6/13 2:37 PM, "Wolfgang Denk"  wrote:

>Dear Philip Odence,
>
>In message  you wrote:
>> LICENSE ID
>> I think I'm on the same page as Daniel. From "SPDX-License-Identifier:
>> MIT" someone ignorant of SPDX can infer/guess at the meaning, but you
>>can
>> imagine one liners (like Bradley's suggestion "License:
>> spdx-license=IDENTIFIER") that would be more explicit from a human
>> perspective and equally easy for a machine to recognize.
>
>Is this really so?
>
>The (one-line_ license tag in a file that is part of a bigger
>software project is actually already redundant information, just
>condensed to the minimally needed information and presented in a
>format that is easy to process automatically.
>
>It has never been my understanding or intention that this should be
>the _only_ information about license terms for the project - as is,
>you will always need some README that explains how hte project as a
>whole is licensed, and how individual files (which may come, for
>example, dual-licensed, or liensed under a different, but compatible
>license) are marked as such.
>
>But this is global information that should be presented just once, and
>it should be not necessary to repeat any of that in the per-file
>license tags.
>
>Best regards,
>
>Wolfgang Denk
>
>-- 
>DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
>HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
>We see things not as they are, but as we are.   - H. M. Tomlinson

___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page - part II

[Wolfgang Denk]

Dear Gary,

In message <001f01cec2e5$9f1d9b20$dd58d160$@com> you wrote:
> 
> The "AND" situation would occur if you have a file which contains code from
> two or more different sources using two or more different licenses.  In that
> case, I believe you would need to satisfy the obligations of all licenses
> (note: I'm not a lawyer so I am not proposing or providing a legal
> interpretation).  Hopefully there is no conflict between the license
> obligations.

I don't think this could work.

We encountered such cases when we analyzed the U-Boot code while
introducing license tags.  There were some files that came with a the
full GPL-2.0+ license header, but further down in the code that had a
short comment that some parts (a few functions) have been copied from
the Linux kernel.  The analysis shows that the original Linux kernel
files were covered by GPL-2.0 only.

If I follow your argument, this code would now be covered by a
"GPL-2.0+ AND GPL-2.0" license construct.  This is obviously absurd: I
cannot both include and exclude the "or later" option simultaneously.


Our understanding of the legal situation left two solutions:  either
we remove the GPL-2.0 code (and replace it by a clean-room
implementation of similar functionality), or we change the file's
license terms to GPL-2.0.  We did the latter:  the files are now
licensed under GPL-2.0, i. e. the "or later" option had to be dropped
for the file as a whole, because it was not available for the parts
imported from Linux.

There was no way to "AND" both licenses here.


> ---
> For a license set, when there is a choice between licenses ("disjunctive
> license"), they should be separated with "or" and enclosed in parentheses.
> When multiple licenses apply ("conjunctive license"), they should be
> separated with an "and" and enclosed in parentheses.  Example: (LGPL-2.1 or
> MPL-1.1).
> ---

Do you have an example, where such a "conjunctive license" construct
actually works?

> We were also concerned about the difficulty in parsing the strings.  We came
> up with enclosing them in parenthesis to aid in accurate and unambiguous
> parsing.  For example, (LGPL-2.1 and (MPL-1.1 or BSD-3-Clause)) would
> describe the licensing for a file which contains code from an LGPL 2.1
> package and code from a package licensed under a choice of MPL-1.1 or
> BSD-3-Clause.

Understood.  However, I think these are only very few pathological
cases, and it would be nice to keep the syntax simple for the
overwhelming majority of practical use cases.  My vote goes for a
simple white speace separated list of license IDs which should be
interpreted as "OR".  Do you think it would be possible to extend the
spec to allow for the (much easier to parse)

  [...]

as synonym for

( OR  [OR ...])

?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Steal five dollars and you were a petty  thief.  Steal  thousands  of
dollars and you are either a government or a hero.
   - Terry Pratchett, _Going_Postal_
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page - part II

[Gary O'Neall]

Hi Wolfgang,

The "AND" situation would occur if you have a file which contains code from
two or more different sources using two or more different licenses.  In that
case, I believe you would need to satisfy the obligations of all licenses
(note: I'm not a lawyer so I am not proposing or providing a legal
interpretation).  Hopefully there is no conflict between the license
obligations.

The "OR" would imply a choice as you mentioned below.

When we were working on the 1.0 SPDX specification, we discussed various
licensing situations and came up with a syntax that could capture both
conjunctive license sets (AND's) and disjunctive license sets (OR's) as well
as arbitrarily complex combinations of conjunctive and disjunctive license
sets.  I suggest we leverage the same spec for the license ids tagged in
source fields.

Below is an excerpt from the spec:
---
For a license set, when there is a choice between licenses ("disjunctive
license"), they should be separated with "or" and enclosed in parentheses.
When multiple licenses apply ("conjunctive license"), they should be
separated with an "and" and enclosed in parentheses.  Example: (LGPL-2.1 or
MPL-1.1).
---

We were also concerned about the difficulty in parsing the strings.  We came
up with enclosing them in parenthesis to aid in accurate and unambiguous
parsing.  For example, (LGPL-2.1 and (MPL-1.1 or BSD-3-Clause)) would
describe the licensing for a file which contains code from an LGPL 2.1
package and code from a package licensed under a choice of MPL-1.1 or
BSD-3-Clause.

Gary

-Original Message-
From: spdx-biz-boun...@lists.spdx.org
[mailto:spdx-biz-boun...@lists.spdx.org] On Behalf Of Wolfgang Denk
Sent: Sunday, October 06, 2013 11:58 AM
To: Wheeler, David A
Cc: SPDX-legal; spdx-tech@lists.spdx.org; SPDX-biz; d...@uvic.ca
Subject: Re: meta-tag page - part II

Dear David,

In message <9f8e44bc27e22046b84ec1b9364c66a1a8054aa...@exch07-4850.ida.org>
you wrote:
>
> SPDX-License-Identifier:  LGPL-2.1 OR MPL-1.1
...
> In general, we all want both simplicity (so people will USE it) and 
> expressiveness (so it can be USEFUL). The trick is getting there...

I dislike this idea.  Combining alternative liceses (where the user can
chose any of them) by anyhting alse but an "OR" does not make sense.  I
cannot imagine how you woudl apply two licesnese (like, say, GPL and BSD)
simultaneously.

Also, in the interest of easy processing of the license tags, I wouls like
to propse that multiple licenses in a list are separated by white space only
- no "OR", no commas, nor any other artificial delimiters that will only
make parsing the information more difficult.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Every
revolutionary idea - in science, politics, art, or  whatever  - evokes three
stages of reaction in a hearer:
  1. It is completely impossible - don't waste my time.
  2. It is possible, but it is not worth doing.
  3. I said it was a good idea all along.
___
Spdx-biz mailing list
spdx-...@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-biz

___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page - part II

[Wolfgang Denk]

Dear David,

In message <9f8e44bc27e22046b84ec1b9364c66a1a8054aa...@exch07-4850.ida.org> you 
wrote:
>
> SPDX-License-Identifier:  LGPL-2.1 OR MPL-1.1
...
> In general, we all want both simplicity (so people will USE it) and
> expressiveness (so it can be USEFUL). The trick is getting there...

I dislike this idea.  Combining alternative liceses (where the user
can chose any of them) by anyhting alse but an "OR" does not make
sense.  I cannot imagine how you woudl apply two licesnese (like, say,
GPL and BSD) simultaneously.

Also, in the interest of easy processing of the license tags, I wouls
like to propse that multiple licenses in a list are separated by white
space only - no "OR", no commas, nor any other artificial delimiters
that will only make parsing the information more difficult.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Every revolutionary idea - in science, politics, art, or  whatever  -
evokes three stages of reaction in a hearer:
  1. It is completely impossible - don't waste my time.
  2. It is possible, but it is not worth doing.
  3. I said it was a good idea all along.
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page - part II

[Wolfgang Denk]

Dear Mark,

In message <01813e194c768044a6486db30b5338ccb711e...@ala-mba.corp.ad.wrs.com> 
you wrote:
> 
> Example 1:
> --
> File: ./cairo-1.10.2.tar.gz.txt/cairo-array.c (see attachment 1)
> NOTICE (simplified): "The file is licensed to you under either the LGPL-2.1 
> or MPL-1.1 at your option." 
> LICENSE EXPRESSION = (LGPL-2.1 OR MPL-1.1)
> 
> Example 2:
> --
> FILE: busybox-1.20.2/shell/math.c (see attachment 2)
> NOTICE (simplified):
>   "You can redistribute the file and/or modify it under the terms of 
> BSD-3-Clause and the MIT license and GPL-2.0 or (at your option) any later 
> version of the GPL"
> LICENSE EXPRESSION = (BSD-3-Clause AND MIT AND GPL-2.0+)

Sorry but I think you get this wrong.  The "and" in the text here does
not translate into a logical "AND" operator.  Instead, it is an "OR"
just as in example 1.

We have a list of liceses here, where the user can freely chose any
one that fits, so it must be an "OR".

An "expression" as "BSD-3-Clause AND MIT AND GPL-2.0+" makes zero
sense; I can't even figure out how this should be interpreted from a
legal point of view.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Boykottiert Microsoft - Kauft Eure Fenster bei OBI!
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[Wolfgang Denk]

Dear Mark,

In message <01813e194c768044a6486db30b5338ccb711e...@ala-mba.corp.ad.wrs.com> 
you wrote:
> 
> I understand the need to keep it simple for the sake of adoption.
> However, if it is too simple we run the risk of mega-tagging doing
> more damage than good. If one is concerned about pursuing Strong
> Compliance (where one tries, within reason, to honor the license
> wishes of all applicable copyright holders of a distributed program)
> then:
> 
>  1. A simple SPDX License Identifier is not sufficient.
> 
>  2. License text is required for a variety of licenses (including but
> not limited to BSD, MIT, Apache, and many custom licenses)

Full agreement here.  But then, this is not an issue that influnces
license tags at all.  If we only had to deal with the easy cases (all
files of a prject are covered by the very same license terms) then we
would not need any per-file license information at all; instead a
project-global license statement would be sufficient.

But the nature especially of open source projects is to borrow code
from here and there, and to support using code in different
environment,s so any project of non-trivial size will quickly have to
deal with things like dual-licensed files etc.

The approach the U-Boot project has taken here attempts to support
Strong Compliance while at the same time getting rid of redundant
information to the extend possible:

- The file "Licenses/README" contains the project-global license
  statement plus explanations how license tags are used in the
  individual files.

- A file "Licenses/Exceptions" deals with special exceptions from the
  rule.

- Files like

Licenses/bsd-2-clause.txt
Licenses/bsd-3-clause.txt
Licenses/eCos-2.0.txt
Licenses/gpl-2.0.txt
Licenses/ibm-pibs.txt
...

  contain copies of the origianl license texts referred to within the
  project.

- The individual project files include only the license tags.


We believe this is a useful compromise between providing all the
legally necessary or useful information, making sure this information
is consistent, and making sure that the actual license terms of a file
level can easily be verified with automatic tools.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It is better to be silent and thought a fool then to speak and remove
all doubt.
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[Wolfgang Denk]

Dear Philip Odence,

In message  you wrote:
> LICENSE ID
> I think I'm on the same page as Daniel. From "SPDX-License-Identifier:
> MIT" someone ignorant of SPDX can infer/guess at the meaning, but you can
> imagine one liners (like Bradley's suggestion "License:
> spdx-license=IDENTIFIER") that would be more explicit from a human
> perspective and equally easy for a machine to recognize.

Is this really so?

The (one-line_ license tag in a file that is part of a bigger
software project is actually already redundant information, just
condensed to the minimally needed information and presented in a
format that is easy to process automatically.

It has never been my understanding or intention that this should be
the _only_ information about license terms for the project - as is,
you will always need some README that explains how hte project as a
whole is licensed, and how individual files (which may come, for
example, dual-licensed, or liensed under a different, but compatible
license) are marked as such.

But this is global information that should be presented just once, and
it should be not necessary to repeat any of that in the per-file
license tags.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
We see things not as they are, but as we are.   - H. M. Tomlinson
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[Wolfgang Denk]

Dear D M German,

In message <524e2cda.c22de00a.39d5.8...@mx.google.com> you wrote:
> 
>  David> From a programmer's perspective I think the "cryptic" approach is FAR
>  David> superior.  There are lots of tools that can quickly examine files and
>  David> return text with the pattern "SPDX-License-Identifier: ", and other
>  David> tools that can trivially process the stuff after it.  The above
>  David> alternative is more work to process, and humans don't like unnecessary
>  David> work :-).
> 
>  David> If you want more boilerplate with the goal of enforceability, you
>  David> might try a format that's trivial to process, e.g.:
> 
>  David> SPDX-License-Notice:  This file is licensed under the following 
> license(s):
>  David> SPDX-License-Identifier:  MIT
>  David> SPDX-License-More-Information:  http://wiki.spdx.org/
> 
> I like this idea.

I dislike this.  It just blows up the actual information we need by
adding unneeded, redundant stuff.

The meaning of a "SPDX-License-Identifier" tag can (and probably
should) be explained in a separate text file (in the U-Boot project we
use "Licenses/README").

There is no need to duplicate this information across all files of a
project; I cannot see any benefit in doing so.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
To understand a program you must become  both  the  machine  and  the
program.
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[Wolfgang Denk]

Dear David,

In message <9f8e44bc27e22046b84ec1b9364c66a1a8054aa...@exch07-4850.ida.org> you 
wrote:
>
> If there can be agreement on a very short license "meta-tag" - and I
> have a strong preference for a version that lets me do it in 1-line-
> then I'll start using it. I suspect others would do so too. After
> all, it's easy to add this kind of line to a source code file:
> 
>   SPDX-License-Identifier: MIT

Full agreement.  Actually I would be happy if a formal requirement
could be installed that the license tag should always be represented by
a single text line (assuming we're referring to "text files"), so it
is trival to extract and process using standard text processing tools
(say, "grep" etc.).

For the same reason, I would also prefer it multiple licenses are just
separated by white space.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Time is a drug. Too much of it kills you.
  - Terry Pratchett, _Small Gods_
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[Wolfgang Denk]

Dear Scott,

On Oct 3, 2013, at 12:33 PM, "Lamons, Scott (Open Source Program
Office)" mailto:scott.lam...@hp.com> wrote:
> 
> Thanks for updating this page. In particular for adding the rationale
> for why tagging is important in the Introduction section. For me, the
> main impetus of adding the license tag is to automate the production
> of accurate SPDX data. To the extent that licensing headers are
> already included in the file I'm not a fan of replacing that with the
> tag - rather, I think our (the SPDX workgroup that is) recommendation
> or best practice should be that the tag should supplement the other
> licensing information. But, in the end, it is the ultimate choice of
> the copyright holder of the software because they will be the party
> implementing this should they choose to adopt.

First of all I would like to point out that I am not an expert in this
field, and even more so, I am not a lawyer...

The base of my comment is the practical experience I gathered when
introducing license tags to the U-Boot project; as far as I understand
this is one of the first (the first?) where this has been doene in a
real software project of some size.

I disagree with keeping the full license header text when adding
license tags; this means duplicating information, which means the risk
of divergence.  For us in the U-Boot project it has been one of the
major goals when introducing license tags to clean up with redundant
and all too often inconsistent information, and I think the same
should be attempted by other projects, too.

Switching from license headers to license tags requires some careful
work, but this effrot should be invested only once, and then everybody
should be able to rely on the recorded (and easily parsable)
information of the license tags.  If you keep the full license tags
duplicated in the source files, you in each review have to make sure
that this is still what it (probably) was then the license tag was
added.  In the end, you add to the efforts instead of reducing it.


I also disagree on the part that such a modification is "ultimate
choice of the copyright holder".  Actually it is only a formal change,
not different from other modifications of the code.  We are in no way
changing the actual license terms that apply to that code.  As far as
I understand, such per-file license headers or license tags are not
even legally needed at all (see statement of Daniel B. Ravicher, Legal
Director of SLFC as referenced here [1]) if "the project as a whole is
licensed under clear terms".

In the interest of reducing the efforts for any kind of license
clearing audits I strongly vote to drop the then redundant license
header text when switching to license tags.

Thanks.

[1] 
git.denx.de/?p=u-boot.git;a=commit;h=eca3aeb352c964bdb28b8e191d6326370245e03f


Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Computers are not intelligent.  They only think they are.
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page - part II

[Wheeler, David A]

Gisi, Mark [mailto:mark.g...@windriver.com]:
> My main concern is: if we don't choose a sufficiently expressive syntax, and 
> end up losing information, then we will have done more damage to SPDX than 
> good. It needs to represent NOTICES and not just a single license.

Fair enough.

I very much like the idea of permitting a license *expression*, instead of one 
license.  Fedora and Debian already do this, so this is a well-understood area. 
 But that's not too difficult, just permit expressions with parentheses, "AND", 
and "OR".  In many cases this would still be simple; here's an example of what 
I have in mind:

SPDX-License-Notice:  This file is licensed under the following terms:
SPDX-License-Identifier:  LGPL-2.1 OR MPL-1.1
SPDX-License-More-Information:  http://wiki.spdx.org/licenselist/spdx-1.1

In general, we all want both simplicity (so people will USE it) and 
expressiveness (so it can be USEFUL).  The trick is getting there...


--- David A. Wheeler

___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page

[Gisi, Mark]

I understand the need to keep it simple for the sake of adoption. However, if 
it is too simple we run the risk of mega-tagging doing more damage than good. 
If one is concerned about pursuing Strong Compliance (where one tries, within 
reason, to honor the license wishes of all applicable copyright holders of a 
distributed program) then:
 1. A simple SPDX License Identifier is not sufficient.
 2. License text is required for a variety of licenses (including but not 
limited to BSD, MIT, Apache, and many custom licenses)

I understand many organizations today still pursue Weak Compliance (selectively 
honoring only certain copyright holders and/or licenses that cover a program) 
but this trend is changing. Just five years ago very few companies produced 
third party notice files (an artifact of strong compliance). Today the requests 
I receive from our customers with respect to supporting strong compliance has 
quadrupled in 2013 compared to three years ago. Many of us are well aware of 
the comprehensive legal notices found on our iphones and Android devices today. 

SPDX needs to support both weak and strong compliance therefore meta-tagging 
should encourage the capture of as much compliance relevant information as 
possible. I will present a number of examples in my next email to better 
illustrate the point.

- Mark


Mark Gisi | Wind River | Senior Intellectual Property Manager
Tel (510) 749-2016 | Fax (510) 749-4552



-Original Message-
From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Philip Odence
Sent: Friday, October 04, 2013 6:08 AM
To: d...@uvic.ca; Wheeler, David A
Cc: spdx-tech@lists.spdx.org; SPDX-biz; SPDX-legal
Subject: Re: meta-tag page

LICENSE ID
I think I'm on the same page as Daniel. From "SPDX-License-Identifier:
MIT" someone ignorant of SPDX can infer/guess at the meaning, but you can 
imagine one liners (like Bradley's suggestion "License:
spdx-license=IDENTIFIER") that would be more explicit from a human perspective 
and equally easy for a machine to recognize.

On the GENIVI Alliance License Review list, there's been some discussion about 
the SPDX license tag (at my prompting). It led to a comparison with the DEP5 
format which is different, in addition to a slight difference in the short 
names. (for the most part they are compatible but they don't like decimal 
places in short names (eg they go with GPL-2 rather than GPL-2.0). Thoughts on 
if/how to resolve with DEP5? It seems like a legit concern from GENIVI...what 
are they to do, faced with two ways of expressing the same thing?

LICENSE TEXT IN FILE
SPDX-License-Identifier: It seems to me we should be somewhere between agnostic 
and encouraging, although our main focus is on getting the meta-tag in there 
whether or no the copyright holder chooses to include license text.

CHANGING THE LICENSE LIST
It should, like amending the constitution be rare, but possible. To me the most 
important thing (even with list versioning) that identifier A0 only point to a 
unique page B0. It would be OK to change A0 to A1 and and have
A1 also point to B0, but it would not be OK for A0 to point to B0 and B1.
I hope this makes sense.

PROCESS
Lastly...everyone OK with this being on all 3 team lists. It does cut across, 
but I don't want people to feel spammed. (I would not be in favor of doing this 
on the GENERAL MEETING list; as we have always positioned that list as having 
light traffic and suitable for folks with only casual
interest)



On 10/3/13 10:49 PM, "D M German"  wrote:

>
> Wheeler, David A twisted the bytes to say:
>
>
> David> From a programmer's perspective I think the "cryptic" approach 
> David> is
>FAR
> David> superior.  There are lots of tools that can quickly examine 
> David> files
>and
> David> return text with the pattern "SPDX-License-Identifier: ", and
>other
> David> tools that can trivially process the stuff after it.  The above 
> David> alternative is more work to process, and humans don't like
>unnecessary
> David> work :-).
>
> David> If you want more boilerplate with the goal of enforceability, 
> David> you might try a format that's trivial to process, e.g.:
>
> David> SPDX-License-Notice:  This file is licensed under the following
>license(s):
> David> SPDX-License-Identifier:  MIT
> David> SPDX-License-More-Information:  http://wiki.spdx.org/
>
>I like this idea.
>
>My point is not about being cryptic or not, but being able to convey 
>what the intention is to people who don't know anything about SPDX. 
>There needs to be a way that if somebody opens the file, they know that 
>that SPDX-License-Identifier means, and that it is an intention to 
>license the file under that license.
>
>Now regarding 

Re: meta-tag page

[Philip Odence]

LICENSE ID
I think I'm on the same page as Daniel. From "SPDX-License-Identifier:
MIT" someone ignorant of SPDX can infer/guess at the meaning, but you can
imagine one liners (like Bradley's suggestion "License:
spdx-license=IDENTIFIER") that would be more explicit from a human
perspective and equally easy for a machine to recognize.

On the GENIVI Alliance License Review list, there's been some discussion
about the SPDX license tag (at my prompting). It led to a comparison with
the DEP5 format which is different, in addition to a slight difference in
the short names. (for the most part they are compatible but they don't
like decimal places in short names (eg they go with GPL-2 rather than
GPL-2.0). Thoughts on if/how to resolve with DEP5? It seems like a legit
concern from GENIVI...what are they to do, faced with two ways of
expressing the same thing?

LICENSE TEXT IN FILE
We probably need to agree on the group's position as it should probably be
addressed in the best practices doc. I don't think we would ever say,
don't include license text. It seems to me we should be somewhere between
agnostic and encouraging, although our main focus is on getting the
meta-tag in there whether or no the copyright holder chooses to include
license text.

CHANGING THE LICENSE LIST
It should, like amending the constitution be rare, but possible. To me the
most important thing (even with list versioning) that identifier A0 only
point to a unique page B0. It would be OK to change A0 to A1 and and have
A1 also point to B0, but it would not be OK for A0 to point to B0 and B1.
I hope this makes sense.

PROCESS
Lastly...everyone OK with this being on all 3 team lists. It does cut
across, but I don't want people to feel spammed. (I would not be in favor
of doing this on the GENERAL MEETING list; as we have always positioned
that list as having light traffic and suitable for folks with only casual
interest)



On 10/3/13 10:49 PM, "D M German"  wrote:

>
> Wheeler, David A twisted the bytes to say:
>
>
> David> From a programmer's perspective I think the "cryptic" approach is
>FAR
> David> superior.  There are lots of tools that can quickly examine files
>and
> David> return text with the pattern "SPDX-License-Identifier: ", and
>other
> David> tools that can trivially process the stuff after it.  The above
> David> alternative is more work to process, and humans don't like
>unnecessary
> David> work :-).
>
> David> If you want more boilerplate with the goal of enforceability, you
> David> might try a format that's trivial to process, e.g.:
>
> David> SPDX-License-Notice:  This file is licensed under the following
>license(s):
> David> SPDX-License-Identifier:  MIT
> David> SPDX-License-More-Information:  http://wiki.spdx.org/
>
>I like this idea.
>
>My point is not about being cryptic or not, but being able to convey
>what the intention is to people who don't know anything about
>SPDX. There needs to be a way that if somebody opens the file, they know
>that that SPDX-License-Identifier means, and that it is an intention to
>license the file under that license.
>
>Now regarding the immutability of the SPDX license list, one way to deal
>with it is to version the list, but then the version of the list would
>have to be included in the file that is referring to the license.
>
>--dmg
>
>
>
>--
>Daniel M. German  "A coin symbolizes our free will"
>   El Zahír, Jorge Luis Borges
>http://turingmachine.org/
>http://silvernegative.com/
>dmg (at) uvic (dot) ca
>replace (at) with @ and (dot) with .
>
> 
>___
>Spdx-biz mailing list
>spdx-...@lists.spdx.org
>https://lists.spdx.org/mailman/listinfo/spdx-biz

___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[D M German]

 Wheeler, David A twisted the bytes to say:


 David> From a programmer's perspective I think the "cryptic" approach is FAR
 David> superior.  There are lots of tools that can quickly examine files and
 David> return text with the pattern "SPDX-License-Identifier: ", and other
 David> tools that can trivially process the stuff after it.  The above
 David> alternative is more work to process, and humans don't like unnecessary
 David> work :-).

 David> If you want more boilerplate with the goal of enforceability, you
 David> might try a format that's trivial to process, e.g.:

 David> SPDX-License-Notice:  This file is licensed under the following 
license(s):
 David> SPDX-License-Identifier:  MIT
 David> SPDX-License-More-Information:  http://wiki.spdx.org/

I like this idea.

My point is not about being cryptic or not, but being able to convey
what the intention is to people who don't know anything about
SPDX. There needs to be a way that if somebody opens the file, they know
that that SPDX-License-Identifier means, and that it is an intention to
license the file under that license. 

Now regarding the immutability of the SPDX license list, one way to deal
with it is to version the list, but then the version of the list would
have to be included in the file that is referring to the license.

--dmg



--
Daniel M. German  "A coin symbolizes our free will"
   El Zahír, Jorge Luis Borges
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

 
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page

[Wheeler, David A]

If there can be agreement on a very short license "meta-tag" - and I have a 
strong preference for a version that lets me do it in 1-line- then I'll start 
using it.  I suspect others would do so too.  After all, it's easy to add this 
kind of line to a source code file:
  SPDX-License-Identifier: MIT

--- David A. Wheeler

___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page

[Lamons, Scott (Open Source Program Office)]

Jack,

First, thanks for pulling together this wiki page!You deserve most of the 
credit for getting this good discussion going.

I actually like the fact that we're having this (and other) discussion(s) "on 
list" because we're getting good inputs from folks that normally don't (and 
perhaps can't) join our weekly/bi-weekly calls (e.g. David, Bradley, Daniel, 
and hopefully more to come)

And, I wouldn't apologize for it being rough either as this is the point of our 
wiki - it's a place for work in progress.   Once we get this into a more 
refined state and have a general consensus in the SPDX working group then I 
would like to see us start to socialize it more broadly and perhaps put 
something a bit more formal (e.g. SPDX best practice or coding standard) on our 
parent (spdx.org) site.

-Scott



From: Manbeck, Jack [mailto:j-manbe...@ti.com]
Sent: Thursday, October 03, 2013 3:14 PM
To: Jilayne Lovejoy; Lamons, Scott (Open Source Program Office)
Cc: spdx-tech@lists.spdx.org; SPDX-biz; SPDX-legal
Subject: RE: meta-tag page

Coming back to a higher level...   What is the purpose of this page?   We need 
to be very clear on this.   In my mind it is to propose a best practice or a 
coding standard. Assuming folks agree with that, then why are we asking for 
people to propose new tags at the bottom of the page - that seems to defeat the 
purpose.

The page was very draft and I wasn't expecting it to go out to the list yet 
(which is why it was hidden on the wiki :)). That said, no big deal. I was a 
little confused in drafting it, since I threw it together right after LinuxCon. 
I thought should this be just about this one field or should we wrap this up 
and say right now it's just one field but could be more in the future? 
Unfortunately the intro makes it appear to be about one field but the body 
makes it appear to be potentially more. Hence, very draft. As to the propose a 
tag. I was just thinking that we had not covered everything (thinking of what 
windriver had done as an example)  that we could do with tags , and who knows 
what the future might bring,  so leave the door open so someone can say hey 
this tag would be useful so here was the way to propose a new one  or even a 
change to the current one if for some reason we needed it. All standards or 
even best practices have a way to make changes and vet new contributions.

Jack


From: 
spdx-legal-boun...@lists.spdx.org<mailto:spdx-legal-boun...@lists.spdx.org> 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Jilayne Lovejoy
Sent: Thursday, October 03, 2013 3:26 PM
To: Lamons, Scott (Open Source Program Office)
Cc: spdx-tech@lists.spdx.org<mailto:spdx-tech@lists.spdx.org>; SPDX-biz; 
SPDX-legal
Subject: Re: meta-tag page

good thoughts, Scott!  Perhaps we don't need to prioritized the rationales, as 
there are several very strong ones, but rather, start with focusing on the easy 
applicability of the short identifiers to this purpose (i.e. tagging).  Then 
discuss why (rationale) tagging is helpful.  I like the bulleted list format 
Jack came up with, but it might be better to have a couple sentences for each 
bullet fleshing out those advantages.

I also meant to add something about how this is not a "replacement" to 
compliance, but that the main goal is to make it easier to identify the license 
of a particular file (and by easier, that would mean more automatable) which, 
in turn, makes compliance easier.  After all, you can only begin compliance 
once you know what you have (via an SPDX document in this case) and, in my 
experience, far too much time is spent trying to figure out the former than 
should be.


David's point about the short identifiers not being completely immutable is a 
good one as well.  As much as we aim to make them so, extreme statements like 
that are usually an invite for contradiction later :)


Jilayne Lovejoy
SPDX Legal Team lead
lovejoyl...@gmail.com<mailto:lovejoyl...@gmail.com>



On Oct 3, 2013, at 12:33 PM, "Lamons, Scott (Open Source Program Office)" 
mailto:scott.lam...@hp.com>> wrote:

Hi Jilayne,

Thanks for updating this page.   In particular for adding the rationale for why 
tagging is important in the Introduction section.   For me, the main impetus of 
adding the license tag is to automate the production of accurate SPDX data.   
To the extent that licensing headers are already included in the file I'm not a 
fan of replacing that with the tag - rather, I think our (the SPDX workgroup 
that is) recommendation or best practice should be that the tag should 
supplement the other licensing information.   But, in the end, it is the 
ultimate choice of the copyright holder of the software because they will  be 
the party implementing this should they choose to adopt.

Coming back to a higher level...   What is the purpose of this page?   We need 
to be very clear on this.   In my 

RE: meta-tag page

[Manbeck, Jack]

Coming back to a higher level...   What is the purpose of this page?   We need 
to be very clear on this.   In my mind it is to propose a best practice or a 
coding standard. Assuming folks agree with that, then why are we asking for 
people to propose new tags at the bottom of the page - that seems to defeat the 
purpose.

The page was very draft and I wasn't expecting it to go out to the list yet 
(which is why it was hidden on the wiki :)). That said, no big deal. I was a 
little confused in drafting it, since I threw it together right after LinuxCon. 
I thought should this be just about this one field or should we wrap this up 
and say right now it's just one field but could be more in the future? 
Unfortunately the intro makes it appear to be about one field but the body 
makes it appear to be potentially more. Hence, very draft. As to the propose a 
tag. I was just thinking that we had not covered everything (thinking of what 
windriver had done as an example)  that we could do with tags , and who knows 
what the future might bring,  so leave the door open so someone can say hey 
this tag would be useful so here was the way to propose a new one  or even a 
change to the current one if for some reason we needed it. All standards or 
even best practices have a way to make changes and vet new contributions.

Jack


From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Jilayne Lovejoy
Sent: Thursday, October 03, 2013 3:26 PM
To: Lamons, Scott (Open Source Program Office)
Cc: spdx-tech@lists.spdx.org; SPDX-biz; SPDX-legal
Subject: Re: meta-tag page

good thoughts, Scott!  Perhaps we don't need to prioritized the rationales, as 
there are several very strong ones, but rather, start with focusing on the easy 
applicability of the short identifiers to this purpose (i.e. tagging).  Then 
discuss why (rationale) tagging is helpful.  I like the bulleted list format 
Jack came up with, but it might be better to have a couple sentences for each 
bullet fleshing out those advantages.

I also meant to add something about how this is not a "replacement" to 
compliance, but that the main goal is to make it easier to identify the license 
of a particular file (and by easier, that would mean more automatable) which, 
in turn, makes compliance easier.  After all, you can only begin compliance 
once you know what you have (via an SPDX document in this case) and, in my 
experience, far too much time is spent trying to figure out the former than 
should be.


David's point about the short identifiers not being completely immutable is a 
good one as well.  As much as we aim to make them so, extreme statements like 
that are usually an invite for contradiction later :)


Jilayne Lovejoy
SPDX Legal Team lead
lovejoyl...@gmail.com<mailto:lovejoyl...@gmail.com>



On Oct 3, 2013, at 12:33 PM, "Lamons, Scott (Open Source Program Office)" 
mailto:scott.lam...@hp.com>> wrote:


Hi Jilayne,

Thanks for updating this page.   In particular for adding the rationale for why 
tagging is important in the Introduction section.   For me, the main impetus of 
adding the license tag is to automate the production of accurate SPDX data.   
To the extent that licensing headers are already included in the file I'm not a 
fan of replacing that with the tag - rather, I think our (the SPDX workgroup 
that is) recommendation or best practice should be that the tag should 
supplement the other licensing information.   But, in the end, it is the 
ultimate choice of the copyright holder of the software because they will  be 
the party implementing this should they choose to adopt.

Coming back to a higher level...   What is the purpose of this page?   We need 
to be very clear on this.   In my mind it is to propose a best practice or a 
coding standard. Assuming folks agree with that, then why are we asking for 
people to propose new tags at the bottom of the page - that seems to defeat the 
purpose.

-Scott




From: spdx-biz-boun...@lists.spdx.org<mailto:spdx-biz-boun...@lists.spdx.org> 
[mailto:spdx-biz-boun...@lists.spdx.org<mailto:biz-boun...@lists.spdx.org>] On 
Behalf Of Jilayne Lovejoy
Sent: Thursday, October 03, 2013 11:09 AM
To: SPDX-legal; SPDX-biz; 
spdx-tech@lists.spdx.org<mailto:spdx-tech@lists.spdx.org>
Subject: meta-tag page

I just updated the meta-tag proposal page on the Wiki in the introduction 
section.  We had discussed on the general meeting this morning, that this was 
needed.  Have a look and see what you think.

http://wiki.spdx.org/view/Technical_Team/SPDX_Meta_Tags


Jilayne Lovejoy
SPDX Legal Team lead
lovejoyl...@gmail.com<mailto:lovejoyl...@gmail.com>




___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page

[Manbeck, Jack]

I think you need a bold statement like that so there is a firm foundation. I 
mean we could deprecate an identifier so it's not to be used anymore but if we 
start putting them in code they can't just disappear.

Jack




From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Jilayne Lovejoy
Sent: Thursday, October 03, 2013 3:26 PM
To: Lamons, Scott (Open Source Program Office)
Cc: spdx-tech@lists.spdx.org; SPDX-biz; SPDX-legal
Subject: Re: meta-tag page

good thoughts, Scott!  Perhaps we don't need to prioritized the rationales, as 
there are several very strong ones, but rather, start with focusing on the easy 
applicability of the short identifiers to this purpose (i.e. tagging).  Then 
discuss why (rationale) tagging is helpful.  I like the bulleted list format 
Jack came up with, but it might be better to have a couple sentences for each 
bullet fleshing out those advantages.

I also meant to add something about how this is not a "replacement" to 
compliance, but that the main goal is to make it easier to identify the license 
of a particular file (and by easier, that would mean more automatable) which, 
in turn, makes compliance easier.  After all, you can only begin compliance 
once you know what you have (via an SPDX document in this case) and, in my 
experience, far too much time is spent trying to figure out the former than 
should be.


David's point about the short identifiers not being completely immutable is a 
good one as well.  As much as we aim to make them so, extreme statements like 
that are usually an invite for contradiction later :)


Jilayne Lovejoy
SPDX Legal Team lead
lovejoyl...@gmail.com<mailto:lovejoyl...@gmail.com>



On Oct 3, 2013, at 12:33 PM, "Lamons, Scott (Open Source Program Office)" 
mailto:scott.lam...@hp.com>> wrote:


Hi Jilayne,

Thanks for updating this page.   In particular for adding the rationale for why 
tagging is important in the Introduction section.   For me, the main impetus of 
adding the license tag is to automate the production of accurate SPDX data.   
To the extent that licensing headers are already included in the file I'm not a 
fan of replacing that with the tag - rather, I think our (the SPDX workgroup 
that is) recommendation or best practice should be that the tag should 
supplement the other licensing information.   But, in the end, it is the 
ultimate choice of the copyright holder of the software because they will  be 
the party implementing this should they choose to adopt.

Coming back to a higher level...   What is the purpose of this page?   We need 
to be very clear on this.   In my mind it is to propose a best practice or a 
coding standard. Assuming folks agree with that, then why are we asking for 
people to propose new tags at the bottom of the page - that seems to defeat the 
purpose.

-Scott




From: spdx-biz-boun...@lists.spdx.org<mailto:spdx-biz-boun...@lists.spdx.org> 
[mailto:spdx-biz-boun...@lists.spdx.org<mailto:biz-boun...@lists.spdx.org>] On 
Behalf Of Jilayne Lovejoy
Sent: Thursday, October 03, 2013 11:09 AM
To: SPDX-legal; SPDX-biz; 
spdx-tech@lists.spdx.org<mailto:spdx-tech@lists.spdx.org>
Subject: meta-tag page

I just updated the meta-tag proposal page on the Wiki in the introduction 
section.  We had discussed on the general meeting this morning, that this was 
needed.  Have a look and see what you think.

http://wiki.spdx.org/view/Technical_Team/SPDX_Meta_Tags


Jilayne Lovejoy
SPDX Legal Team lead
lovejoyl...@gmail.com<mailto:lovejoyl...@gmail.com>




___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page

[Manbeck, Jack]

I agree that cryptic is best. 

If we all we recognize that using 'SPDX-License-Identifier'  means this is what 
the  file is licensed under do we really need to be any more explicit? Do we 
really still require a license header?  If we did need to be more explicit I 
would think along the lines of  'SPDX-File-LicensedAs'  to try and keep it 
simple. The more information link that David suggest sis interesting. Would 
that field and the license identifier be equivalent to a license header (since 
people seem to be nervous about losing the headers)?

There are some limitations to the current approach.

1. You can only use this for licenses that are on the SPDX license list. It 
might be interesting to have further meta tags like BEGIN and END license in 
those cases where someone has created their own (or conversely we add 
everything to the list.. Jilayne groans :)).

2. We can't capture license exceptions written into the source. Might be nice 
to add delimiters for that as well. I know for the well formed stuff like that 
from the FSF we are probably okay but here are lots of other examples in the 
wild and we still use that software.

3.  Likely lots more we could capture. Windriver did an example markup of 
busybox to try and capture license information. Would be good to study that as 
well. Lots of things that could be added going forward.

My thinking was to start small with this and then see it grow. We likely can't 
call this a standard but we could be thinking of that in the future if it gets 
wide adoption.

Jack


-Original Message-
From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Wheeler, David A
Sent: Thursday, October 03, 2013 2:54 PM
To: dmg; Lamons, Scott (Open Source Program Office)
Cc: spdx-tech@lists.spdx.org; SPDX-biz; SPDX-legal
Subject: RE: meta-tag page

Dmg:
> Following this rational, would it be possible to recommend something in the 
> line of:
> BEGIN_LICENSE
> This file is licensed under the  For more 
> information see URL-TO-SPDX-WEB-SITE-WITH-iNFO END_LICENSE that makes 
> three things explicit:
>
> * It says where the license info in -file is (BEGIN, END_LICENSE)
> * It explicitly states the file is licensed under the given licence
> * It says where to get more information to understand what it means.

> Jack's way of doing it, by just naming the license feels too cryptic 
> to me if I am reading the header, and does not explicitly state it is 
> the license under which the file is made available to others

>From a programmer's perspective I think the "cryptic" approach is FAR 
>superior.  There are lots of tools that can quickly examine files and return 
>text with the pattern "SPDX-License-Identifier:  ", and other tools that can 
>trivially process the stuff after it.  The above alternative is more work to 
>process, and humans don't like unnecessary work :-).

If you want more boilerplate with the goal of enforceability, you might try a 
format that's trivial to process, e.g.:

SPDX-License-Notice:  This file is licensed under the following license(s):
SPDX-License-Identifier:  MIT
SPDX-License-More-Information:  http://wiki.spdx.org/

--- David A. Wheeler


___
Spdx-legal mailing list
spdx-le...@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page

[Manbeck, Jack]

Agreed. That's much closer to the truth.

Jack


From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Wheeler, David A
Sent: Thursday, October 03, 2013 2:43 PM
To: Jilayne Lovejoy; SPDX-legal; SPDX-biz; spdx-tech@lists.spdx.org
Subject: RE: meta-tag page

I really like this idea of one special line I can quickly search for.  It makes 
the SPDX list a lot easier to use.

I have a comment on the justification: "The license list for SPDX is immutable 
and will never change."
Well, that's not true, hopefully it'll keep getting larger.  How about:
"The meaning of a given SPDX license identifier is immutable and will never 
change".

--- David A. Wheeler


From: 
spdx-legal-boun...@lists.spdx.org<mailto:spdx-legal-boun...@lists.spdx.org> 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Jilayne Lovejoy
Sent: Thursday, October 03, 2013 1:09 PM
To: SPDX-legal; SPDX-biz; 
spdx-tech@lists.spdx.org<mailto:spdx-tech@lists.spdx.org>
Subject: meta-tag page

I just updated the meta-tag proposal page on the Wiki in the introduction 
section.  We had discussed on the general meeting this morning, that this was 
needed.  Have a look and see what you think.

http://wiki.spdx.org/view/Technical_Team/SPDX_Meta_Tags


Jilayne Lovejoy
SPDX Legal Team lead
lovejoyl...@gmail.com<mailto:lovejoyl...@gmail.com>



___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[Jilayne Lovejoy]

good thoughts, Scott!  Perhaps we don't need to prioritized the rationales, as 
there are several very strong ones, but rather, start with focusing on the easy 
applicability of the short identifiers to this purpose (i.e. tagging).  Then 
discuss why (rationale) tagging is helpful.  I like the bulleted list format 
Jack came up with, but it might be better to have a couple sentences for each 
bullet fleshing out those advantages.

I also meant to add something about how this is not a "replacement" to 
compliance, but that the main goal is to make it easier to identify the license 
of a particular file (and by easier, that would mean more automatable) which, 
in turn, makes compliance easier.  After all, you can only begin compliance 
once you know what you have (via an SPDX document in this case) and, in my 
experience, far too much time is spent trying to figure out the former than 
should be.


David's point about the short identifiers not being completely immutable is a 
good one as well.  As much as we aim to make them so, extreme statements like 
that are usually an invite for contradiction later :)


Jilayne Lovejoy
SPDX Legal Team lead
lovejoyl...@gmail.com



On Oct 3, 2013, at 12:33 PM, "Lamons, Scott (Open Source Program Office)" 
 wrote:

> Hi Jilayne,
>  
> Thanks for updating this page.   In particular for adding the rationale for 
> why tagging is important in the Introduction section.   For me, the main 
> impetus of adding the license tag is to automate the production of accurate 
> SPDX data.   To the extent that licensing headers are already included in the 
> file I’m not a fan of replacing that with the tag – rather, I think our (the 
> SPDX workgroup that is) recommendation or best practice should be that the 
> tag should supplement the other licensing information.   But, in the end, it 
> is the ultimate choice of the copyright holder of the software because they 
> will  be the party implementing this should they choose to adopt.
>  
> Coming back to a higher level...   What is the purpose of this page?   We 
> need to be very clear on this.   In my mind it is to propose a best practice 
> or a coding standard. Assuming folks agree with that, then why are we 
> asking for people to propose new tags at the bottom of the page – that seems 
> to defeat the purpose.
>  
> -Scott
>  
>  
>  
>  
> From: spdx-biz-boun...@lists.spdx.org 
> [mailto:spdx-biz-boun...@lists.spdx.org] On Behalf Of Jilayne Lovejoy
> Sent: Thursday, October 03, 2013 11:09 AM
> To: SPDX-legal; SPDX-biz; spdx-tech@lists.spdx.org
> Subject: meta-tag page
>  
> I just updated the meta-tag proposal page on the Wiki in the introduction 
> section.  We had discussed on the general meeting this morning, that this was 
> needed.  Have a look and see what you think.
>  
> http://wiki.spdx.org/view/Technical_Team/SPDX_Meta_Tags
>  
>  
> Jilayne Lovejoy
> SPDX Legal Team lead
> lovejoyl...@gmail.com
>  
>  
>  

___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page

[Wheeler, David A]

Dmg:
> Following this rational, would it be possible to recommend something in the 
> line of:
> BEGIN_LICENSE
> This file is licensed under the 
> For more information see URL-TO-SPDX-WEB-SITE-WITH-iNFO
> END_LICENSE
> that makes three things explicit:
>
> * It says where the license info in -file is (BEGIN, END_LICENSE)
> * It explicitly states the file is licensed under the given licence
> * It says where to get more information to understand what it means.

> Jack's way of doing it, by just naming the license feels too cryptic to me if 
> I am reading the header, and does not explicitly state it is the license 
> under which the file is made available to others

>From a programmer's perspective I think the "cryptic" approach is FAR 
>superior.  There are lots of tools that can quickly examine files and return 
>text with the pattern "SPDX-License-Identifier:  ", and other tools that can 
>trivially process the stuff after it.  The above alternative is more work to 
>process, and humans don't like unnecessary work :-).

If you want more boilerplate with the goal of enforceability, you might try a 
format that's trivial to process, e.g.:

SPDX-License-Notice:  This file is licensed under the following license(s):
SPDX-License-Identifier:  MIT
SPDX-License-More-Information:  http://wiki.spdx.org/

--- David A. Wheeler


___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page

[Wheeler, David A]

I really like this idea of one special line I can quickly search for.  It makes 
the SPDX list a lot easier to use.

I have a comment on the justification: "The license list for SPDX is immutable 
and will never change."
Well, that's not true, hopefully it'll keep getting larger.  How about:
"The meaning of a given SPDX license identifier is immutable and will never 
change".

--- David A. Wheeler


From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Jilayne Lovejoy
Sent: Thursday, October 03, 2013 1:09 PM
To: SPDX-legal; SPDX-biz; spdx-tech@lists.spdx.org
Subject: meta-tag page

I just updated the meta-tag proposal page on the Wiki in the introduction 
section.  We had discussed on the general meeting this morning, that this was 
needed.  Have a look and see what you think.

http://wiki.spdx.org/view/Technical_Team/SPDX_Meta_Tags


Jilayne Lovejoy
SPDX Legal Team lead
lovejoyl...@gmail.com



___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: meta-tag page

[dmg]

On Thu, Oct 3, 2013 at 2:33 PM, Lamons, Scott (Open Source Program
Office)  wrote:
> Thanks for updating this page.   In particular for adding the rationale for
> why tagging is important in the Introduction section.   For me, the main
> impetus of adding the license tag is to automate the production of accurate
> SPDX data.   To the extent that licensing headers are already included in
> the file I’m not a fan of replacing that with the tag – rather, I think our
> (the SPDX workgroup that is) recommendation or best practice should be that
> the tag should supplement the other licensing information.   But, in the
> end, it is the ultimate choice of the copyright holder of the software
> because they will  be the party implementing this should they choose to
> adopt.


Following this rational, would it be possible to recommend something
in the line of:

BEGIN_LICENSE

This file is licensed under the 

For more information see URL-TO-SPDX-WEB-SITE-WITH-iNFO

END_LICENSE

that makes three things explicit:

* It says where the license info in -file is (BEGIN, END_LICENSE)
* It explicitly states the file is licensed under the given licence
* It says where to get more information to understand what it means.

Jack's way of doing it, by just naming the license feels too cryptic
to me if I am reading the header, and does not
explicitly state it is the license under which the file is made
available to others

--dmg

-- 
--dmg

---
Daniel M. German
http://turingmachine.org
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: meta-tag page

[Lamons, Scott (Open Source Program Office)]

Hi Jilayne,

Thanks for updating this page.   In particular for adding the rationale for why 
tagging is important in the Introduction section.   For me, the main impetus of 
adding the license tag is to automate the production of accurate SPDX data.   
To the extent that licensing headers are already included in the file I'm not a 
fan of replacing that with the tag - rather, I think our (the SPDX workgroup 
that is) recommendation or best practice should be that the tag should 
supplement the other licensing information.   But, in the end, it is the 
ultimate choice of the copyright holder of the software because they will  be 
the party implementing this should they choose to adopt.

Coming back to a higher level...   What is the purpose of this page?   We need 
to be very clear on this.   In my mind it is to propose a best practice or a 
coding standard. Assuming folks agree with that, then why are we asking for 
people to propose new tags at the bottom of the page - that seems to defeat the 
purpose.

-Scott




From: spdx-biz-boun...@lists.spdx.org [mailto:spdx-biz-boun...@lists.spdx.org] 
On Behalf Of Jilayne Lovejoy
Sent: Thursday, October 03, 2013 11:09 AM
To: SPDX-legal; SPDX-biz; spdx-tech@lists.spdx.org
Subject: meta-tag page

I just updated the meta-tag proposal page on the Wiki in the introduction 
section.  We had discussed on the general meeting this morning, that this was 
needed.  Have a look and see what you think.

http://wiki.spdx.org/view/Technical_Team/SPDX_Meta_Tags


Jilayne Lovejoy
SPDX Legal Team lead
lovejoyl...@gmail.com



___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech