Topics

Decouple license list from the spec


Michael J Herzog <mjherzog@...>
 

+2 for decoupling the spec from the licenses. We need to be able to update the spec and the license list on different cycles. We should also anticipate that many orgs may want to keep a local copy of the SPDX license list.

Regards, Michael

Michael J. Herzog
+1 650 380 0680 | mjherzog_at_nexB.com
nexB [Open by Design] http://www.nexb.com

CONFIDENTIALITY NOTICE: This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 380-0680.

On 9/8/2010 4:05 PM, Kim Weins wrote:
I also agree that we should decouple spec from licenses. We need a way to
add licenses without having to rev the spec. Otherwise we will get lots of
spec revisions or very few license updates.

I know there has been some concern that if the list of licenses is not
"fixed" with the spec version, you won't know what list of licenses you need
to be able to "understand" when you get an SPDX file based on a particular
version of the spec. I'd like to dig into this use case more, since it seems
to me that any tooling or even manual review processes can be designed to
just pull the latest and greatest version of licenses from the website.

The only issue is that you may get an SPDX file that has something marked as
an "Other" license that is now in the standard license repo. That
shouldn't really be a problem, since all the "Other" licenses will have full
license text in the SPDX file.

Here's an example:

Company A creates SPDX on 1/1/2011 using latest set of standard licenses at
that point. They identify:
File A has Standard License A
File B has Standard License B
File C has Other License C
File D has Other License D

On 2/1/2011, License C is added to standard license repo

Company B reviews SPDX on 3/1/2011
All of the info is still valid -- since License C and D are in the SPDX
file. Company B could choose to update the SPDX file as:
File A has Standard License A
File B has Standard License B
File C now has STANDARD License C
File D has Other License D


Am I missing something here?

Kim


On Wed 9/8/10 12:48 PM, "dmg"<dmg@...> wrote:
From the minutes:

Our implicit path had tied a fixed license list of licenses to the
spec rev, but JohnE put forth an impassioned argument as to why they
should be decouples...

I throw my support behind JohnE proposal. It addresses many of the
issues I have discussed before.

--dmg

(hopefully I can make wake up in time for the meeting, but it is tough
to only have 5 hrs of sleep :)


Soeren_Rabenstein@...
 

Dear all

I perfectly understand the concerns. But I would like to emphasize that
imho one of the benefits of spdx for the industry is to have unequivocal
names/indicator for licenses.
Now if there are let's say five new licenses, the names of which are
Amazing Public License,
American Public License,
Amateur Public License,
Amoral Public License, and
Amusing Public License.

...and all of them get tagged "AmPL" in the name tag by someone, then I
will certainly end up with misunderstandings and confusion,
notwithstanding the fact that the text of the different AmPLs are
embedded in the file.

For me the idea of unequivocal "declared license" tags has a lot of
beauty, as this way compliance can be streamlined and partly
automatized, as I can trigger a certain process for a given license tag
appearing in the spdx. If I still need to legally review each spdx,
because many of the applicable license texts are embedded there, I lose
some of the benefits that spdx can have in daily industrial application.

Best regards
Soeren

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...]
On Behalf Of Michael J Herzog
Sent: Thursday, September 09, 2010 7:22 AM
To: Kim Weins
Cc: spdx@...
Subject: Re: Decouple license list from the spec

+2 for decoupling the spec from the licenses. We need to be able to
update
the spec and the license list on different cycles. We should also
anticipate
that many orgs may want to keep a local copy of the SPDX license list.

Regards, Michael

Michael J. Herzog
+1 650 380 0680 | mjherzog_at_nexB.com
nexB [Open by Design] http://www.nexb.com

CONFIDENTIALITY NOTICE: This e-mail (including attachments) may
contain information that is proprietary or confidential. If you are
not
the intended recipient or a person responsible for its delivery to the
intended recipient, do not copy or distribute it. Please permanently
delete the e-mail and any attachments, and notify us immediately at
(650) 380-0680.


On 9/8/2010 4:05 PM, Kim Weins wrote:
I also agree that we should decouple spec from licenses. We need a
way to
add licenses without having to rev the spec. Otherwise we will get
lots of
spec revisions or very few license updates.

I know there has been some concern that if the list of licenses is
not
"fixed" with the spec version, you won't know what list of licenses
you need
to be able to "understand" when you get an SPDX file based on a
particular
version of the spec. I'd like to dig into this use case more, since
it seems
to me that any tooling or even manual review processes can be
designed to
just pull the latest and greatest version of licenses from the
website.

The only issue is that you may get an SPDX file that has something
marked as
an "Other" license that is now in the standard license repo. That
shouldn't really be a problem, since all the "Other" licenses will
have full
license text in the SPDX file.

Here's an example:

Company A creates SPDX on 1/1/2011 using latest set of standard
licenses at
that point. They identify:
File A has Standard License A
File B has Standard License B
File C has Other License C
File D has Other License D

On 2/1/2011, License C is added to standard license repo

Company B reviews SPDX on 3/1/2011
All of the info is still valid -- since License C and D are in the
SPDX
file. Company B could choose to update the SPDX file as:
File A has Standard License A
File B has Standard License B
File C now has STANDARD License C
File D has Other License D


Am I missing something here?

Kim


On Wed 9/8/10 12:48 PM, "dmg"<dmg@...> wrote:
From the minutes:

Our implicit path had tied a fixed license list of licenses to the
spec rev, but JohnE put forth an impassioned argument as to why
they
should be decouples...

I throw my support behind JohnE proposal. It addresses many of the
issues I have discussed before.

--dmg

(hopefully I can make wake up in time for the meeting, but it is
tough
to only have 5 hrs of sleep :)
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
=====================================================================================================================================
This email and any attachments to it contain confidential information and are intended solely for the use of the individual to whom it
is addressed.If you are not the intended recipient or receive it accidentally, please immediately notify the sender by e-mail and delete
the message and any attachments from your computer system, and destroy all hard copies. If any, please be advised that any unauthorized
disclosure, copying, distribution or any action taken or omitted in reliance on this, is illegal and prohibited. Furthermore, any views
or opinions expressed are solely those of the author and do not represent those of ASUSTeK. Thank you for your cooperation.
=====================================================================================================================================