Re: SPDX-License-Identifier for composite-licensed source files

[Matija ?uklje]

Hi Richard,

I think both your possibilities work, and with the current state 
of art, I would agree with Kate, Jilayne and Gary.

On the other hand it seems to me that exactly how to mark source 
code is perhaps a bit out of the scope of SPDX (I might be wrong 
though).

A project that is based on SPDX that is aimed directly at properly 
marking up source code is .

For 4.0 (i.e. next major release) spec, one of the bigger tasks is 
to properly handle snippets. There is already a ticket open, and 
I’d love to hear your (and everyone else’s on this list, of 
course) feedback:



cheers,
Matija Šuklje
-- 
gsm:+386 41 849 552
www:http://matija.suklje.name
xmpp:   matija.suk...@gabbler.org
sip:matija_suk...@ippi.fr




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2710): https://lists.spdx.org/g/Spdx-legal/message/2710
Mute This Topic: https://lists.spdx.org/mt/68280619/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: How to best handle modification notices and notices of origin in SPDX

[Matija ?uklje]

On petek, 06. september 2019 05:35:48 CEST, J Lovejoy wrote:


I really wouldn’t conflate attribution and copyright notices - 
that seems to lead to a lot of unnecessarily confusion and other 
energy
FWIW - this reminded me that there are some licenses that 
require a specific acknowledgment (I’m intentionally not using 
“attribution” :) in the form of specific text you need to 
reproduce, such as Apache-1.1, clause 3 - 
https://www.gnu.org/licenses/identify-licenses-clearly.en.html


Depends on the license (e.g. CC licenses) and jurisdiction (moral rights), 
I’d say. So if someone really wanted to start a stink, they might use.


But you’re right, this is wider than just attribution, but that seemed the 
easiest use case/term for it.


When we began to do the review and conversion for the XML 
format, we began to label licenses that have this. We didn’t 
necessarily catch all of them or implement a XML tag for this, 
but the idea was that it would be possible (if someone wanted to 
do the work, there was enough work at that point that we didn’t 
proceed down this path at the time).  Just thought I’d mention!


That helps with the license( template)s on the SPDX license list, but not 
all of these are included in the license text (again, see CC licenses, or 
UFL-1.1).


Regarding going through the XML sources and putting in the tags, I 
volunteer, so feel free to assign a ticket to me, but don’t have any free 
cycles until OSSEurope.



cheers,
Matija
--
gsm:tel:+386.41.849.552
www:https://matija.suklje.name
xmpp:   matija.suk...@gabbler.org
sip:matija_suk...@ippi.fr

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2671): https://lists.spdx.org/g/Spdx-legal/message/2671
Mute This Topic: https://lists.spdx.org/mt/32590067/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

How to best handle modification notices and notices of origin in SPDX

[Matija ?uklje]

Hi all,

recently I’ve been thinking about how to store¹ additional notices that are 
required by some licenses on the SPDX license list. Specifically reference 
to the origin of the work, and notice of modification of original work.


I’m sure people on this list are very well aware of the notice of 
modification as e.g. in §5.a of GPL-3.0:


“The work must carry prominent notices stating that you modified it, and 
giving a relevant date.”


As an example of where the requirement (of attribution) is to provide a 
notice of where the original work came from, I can offer CC-BY-4.0 and its 
§3.a.1.A.v:


“a URI or hyperlink to the Licensed Material to the extent reasonably 
practicable;”


…which BTW also includes a notice of modification requirement in §3.a.1.B:

“indicate if You modified the Licensed Material and retain an indication of 
any previous modifications;”


This “BY” clause is inherent to all CC-* licenses (apart from CC0-1.0 and 
CC-PDDC), and similar clauses exist already in its 1.0 version, so I think 
it is safe to assume that all CC licenses have this requirement.


So, I was wondering if there was a way to express this information in SPDX 
(other than the generic comment).


I thought of some ugly workarounds, but would first like to hear if there 
is already a proper way, before I soil this mailing list with that.




cheers,
Matija
—
1  Or, better yet, express.
--
gsm:tel:+386.41.849.552
www:https://matija.suklje.name
xmpp:   matija.suk...@gabbler.org
sip:matija_suk...@ippi.fr

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2644): https://lists.spdx.org/g/Spdx-legal/message/2644
Mute This Topic: https://lists.spdx.org/mt/32590067/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: meeting minutes from today

[Matija ?uklje]

Die 1. 06. 19 et hora 00:58 Dave Marr scripsit:
> +1
> 
> SPDX is only pragmatically useful to me if it generally reflects
> the licenses I’m likely to encounter when vetting community
> software.

I agree.

Although the question still remains what constitutes a popular 
license – does a non-FOSS license that is also not used by any 
substantial number of projects, but is used by a very popular 
project qualify?

We have included more-or-less-single-but-very-popular-project FOSS 
licenses in the past (Python, PHP, JSON, …), but those are most 
often licenses for a whole ecosystem, as these tend to be 
languages or similar.

I wonder where to draw the line, because if we go down the road of 
“how likely am I to bump into this license”, we’re going in the 
direction of proprietary licenses for specific, but super popular 
products like e.g. Java EE or OracleDB (not picking on Oracle 
specifically, it is just the first two big pieces of software 
things that pop to mind). If I’m being super-cheeky, I wonder how 
much further before I can suggest adding the Liferay Enterprise 
Subscription license ;)


cheers,
Matija
-- 
gsm:tel:+386.41.849.552
www:https://matija.suklje.name
xmpp:   matija.suk...@gabbler.org
sip:matija_suk...@ippi.fr



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2604): https://lists.spdx.org/g/Spdx-legal/message/2604
Mute This Topic: https://lists.spdx.org/mt/31872337/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Updated project ideas - new login workflow

[Matija ?uklje]

Die 18. 01. 19 et hora 18:30 Gary O'Neall scripsit:
> Let me know if you see any issues with the proposal.  We can
> always tune up the project idea over the next couple of weeks.

I can see no issues (at least after only my first coffee) and it 
looks really cool to me :)


cheers,
Matija
-- 
gsm:+386 41 849 552
www:http://matija.suklje.name
xmpp:   matija.suk...@gabbler.org
sip:matija_suk...@ippi.fr



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2527): https://lists.spdx.org/g/Spdx-legal/message/2527
Mute This Topic: https://lists.spdx.org/mt/29204832/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: New License/Exception Request: The Star And Thank Author License

[Matija ?uklje]

On petek, 19. oktober 2018 08:08:09 CEST qiwihui wrote:
> Short Identifier: SATA

In any case, should we decide to adopt this license, I would 
suggest we use a different short ID, as it could cause confusion 
with the widely known SATA/Serial ATA:
https://en.wikipedia.org/wiki/Serial_ATA


cheers,
Matija Šuklje
-- 
gsm:+386 41 849 552
www:http://matija.suklje.name
xmpp:   matija.suk...@gabbler.org
sip:matija_suk...@ippi.fr




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2428): https://lists.spdx.org/g/Spdx-legal/message/2428
Mute This Topic: https://lists.spdx.org/mt/27412131/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: New License/Exception Request: The Star And Thank Author License

[Matija ?uklje]

On petek, 19. oktober 2018 08:08:09 CEST qiwihui wrote:
> The basic idea is, whenever using a project using SATA license,
> people shall star/like/+1 that project and thank the author.

…this brings up so many questions in me.

Would I really not be allowed to use the software, if I don’t +1 
it? What’s next – “leave a favourable five-star review as a 
condition for you to be able to use it”?

What about if where I got the package from, it doesn’t allow for 
star/like/+1 (e.g. my Linux distro)?

What about if I fork their repository – should the stars/likes/+1s 
and thanks now go to me and/or how do I forward them to their 
rightful upstream owner?

I have no idea what this has to do in a (copyright) license…

Anyway, this is just a vanilla MIT with this “star and thank” 
clause added. I think the project would be best served, if they 
simply used MIT and put their plea for likes and thanks into the 
README file.


cheers,
Matija Šuklje
-- 
gsm:+386 41 849 552
www:http://matija.suklje.name
xmpp:   matija.suk...@gabbler.org
sip:matija_suk...@ippi.fr




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2427): https://lists.spdx.org/g/Spdx-legal/message/2427
Mute This Topic: https://lists.spdx.org/mt/27412131/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Proposal for a generic new exception for OpenSSL

[Matija ?uklje]

First of all, I apologise for the long delay. I got distracted by 
illness, work etc.

I see this discussion has progressed a bit since then. I’ll try to 
weave the new parts of the thread into my old draft.

Dne četrtek, 09. avgust 2018 ob 15:43:15 CEST je James Bottomley 
napisal(a):

> Sure ... as a lawyer just tell me if the form of words achieves 
what I
> need and is optimal.

As you know, you cannot get legal advice from either this (or 
other) public mailing list, but here’s my personal take on it. :)

Here is the original openvpn-openssl-exception as listed by SPDX 
(highlighted are portions that differ between this and wget 
variation; I added manual line breaks for easier legibility):

“_Special exception for linking OpenVPN with OpenSSL:_

In addition, as a special exception,
_OpenVPN Technologies, Inc._ 
gives permission to link the code of
_this program_
with the OpenSSL _Library_ (or with modified versions of _OpenSSL_ 
that use the same license as _OpenSSL_), and distribute
_linked combinations including the two._
You must obey the GNU General Public License in all respects for 
all of the code  used other than _OpenSSL._ If you modify this 
file, you may extend this exception to your version of the file, 
but you are not obligated to do so. If you do not wish to do so, 
delete this exception statement from your version.”


As a separate example in the wild, I will use wget as an example, 
as it quite a popular tool as well as a GNU project and therefore 
under the ægis of FSF. So it may be supposed that they took extra 
care for the exception to be compatible with (their interpretation 
of) the GPL.

See e.g. in `README` of wget-1.10.2, which was under GPL-2.0-or-
later:

“In addition, as a special exception, 
_the Free Software Foundation_
gives permission to link the code of 
_its release of Wget_
with the OpenSSL _project's "OpenSSL" library_ (or with modified 
versions of _it_ that use the same license as _the "OpenSSL"_ 
_library_), and distribute
_the linked executables._
You must obey the GNU General Public License in all respects for 
all of the code used other than _"OpenSSL"._ If you modify this 
file, you may extend this exception to your version of the file, 
but you are not obligated to do so. If you do not wish to do so, 
delete this exception statement from your version.”

… which looks fairly similar.

Deluge’s example that Calum suggested looks very similar as well. 
Althought it does abstract the “copyright holders”.

Now in `README` of wget-1.19, which is under GPL-3.0-or-later you 
can find a newer variation, with the text adapted quite a lot (a 
diff does not help here much):

“Additional permission under GNU GPL version 3 section 7

If you modify this program, or any covered work, by linking or 
combining it with the OpenSSL project's OpenSSL library (or a 
modified version of that library), containing parts covered by the 
terms of the OpenSSL or SSLeay licenses, the Free Software 
Foundation grants you additional permission to convey the 
resulting work. Corresponding Source for a non-source form of such 
a combination shall include the source code for the parts of 
OpenSSL used as well as that of the covered work.”

James’ suggestion on the other hand is much shorter:

“as an additional permission combining this work with OpenSSL via
linking does not create a derivative work of this work.”

As they are much more different from the original OpenVPN OpenSSL 
Exception, I doubt we could accept it as a variation of it. Also, 
the question what is or isn’t derivative work sounds like being a 
bit outside author’s possibility to claim.

For a truly generic “OpenSSL” exception template that we don’t 
need to add over and over again, I would think, what would be 
needed is that it’s:

• agnostic of the copyright holders and the project it is attached 
to (as its outbound license)
• agnostic of the project that is being linked to – at least in 
its template form
• works with both GPL-2.0 and GPL-3.0 (e.g. for GPL-2.0-or-later 
projects)

I think Alexios’ suggestion to templetise the openvpn-openssl-
exception very well meets the first two requirements¹. The 
question remains what to do with GPL-3.0(-or-later) compatibility.

Here is a little franken-exception-monster that I stitched 
together:

“If you modify this program, or any covered work, by linking or 
combining it with  (or a modified version of   
),  grants you additional 
permission to convey the resulting work. Corresponding Source for 
a non-source form of such a combination shall include the source 
code for the parts of  used as well as that of 
the covered work.

If you modify this file, you may extend this exception 
(“Additional permission” under GPL-3.0, section 7) to your version 
of the file, but you are not obligated to do so. If you do not 
wish to do so, delete this exception statement from your version.”

It is not pretty and still holds some GPL-3.0-specific language, 
but might be a start to make 

Re: Proposal for a generic new exception for OpenSSL

[Matija ?uklje]

Dne četrtek, 09. avgust 2018 ob 02:46:21 CEST je James Bottomley 
napisal(a):
> Most of the alternative formulations go for wordier versions, but I
> think brevity is better.

I have pondered on this for longer than I thought I would, but don’t 
have a proposal I would be happy with yet.

Would you mind sharing which others versions you found? Can also be off-
list, if preferred.


cheers,
Matija
-- 
gsm:+386 41 849 552
www:http://matija.suklje.name
xmpp:   matija.suk...@gabbler.org
sip:matija_suk...@ippi.fr



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2367): https://lists.spdx.org/g/Spdx-legal/message/2367
Mute This Topic: https://lists.spdx.org/mt/24235315/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Proposal for a generic new exception for OpenSSL

[Matija ?uklje]

Hi James,

if there is interest, I volunteer to help with this one.


cheers,
Matija
-- 
gsm:+386 41 849 552
www:http://matija.suklje.name
xmpp:   matija.suk...@gabbler.org
sip:matija_suk...@ippi.fr



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2358): https://lists.spdx.org/g/Spdx-legal/message/2358
Mute This Topic: https://lists.spdx.org/mt/24235315/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Change use of SPDX *-Identifier tags in REUSE.software and Linux kernel best practices?

[Matija ?uklje]

Dne četrtek, 02. avgust 2018 ob 15:25:51 CEST je Kate Stewart 
napisal(a):
> I think if we socialize it with the kernel community in advance,  and
> then send a pull request to change the locations in the kernel and
> reference the change to the REUSE.software to implement this,  we
> shouldn't get too much push back.

That’d be wonderful.

Should the three of us discuss how specifically to tackle this off list, 
since it’s not exactly an SPDX issue per se?

If so, Kate, since you probably know best who else (I imagine Greg KH 
and Thomas G) should be included from the Kernel community, would you 
mind starting the thread?


cheers,
Matija
-- 
gsm:+386 41 849 552
www:http://matija.suklje.name
xmpp:   matija.suk...@gabbler.org
sip:matija_suk...@ippi.fr



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2347): https://lists.spdx.org/g/Spdx-legal/message/2347
Mute This Topic: https://lists.spdx.org/mt/24005641/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Change use of SPDX *-Identifier tags in REUSE.software and Linux kernel best practices?

[Matija ?uklje]

Hi all,

I’m currently battling figuring out how to integrate SPDX through 
REUSE.software and am at a stage of severe head-scratching¹. I am CC’ing Jonas 
(FSFE, REUSE), in case he is not actively following this list.

While I am referring to REUSE.software² here, the situation is near identical 
in the Linux kernel licensing rules³.

REUSE.software refers to the following tags:

• ‘Valid-License-Identifier’ to tag the actual *text of* a license  (and 
‘License-Text’ to include a copy of its text)
• ‘SPDX-Exception-Identifier’ to tag the actual *text of* an exception (and 
‘Exception-Text’ to include a copy of its text)

Now, I searched the SPDX Specifications 2.1⁴ and I could not find either.

What I did find is the ‘SPDX-License-Identifier’, which we all know and love 
and is used to tag the governing license of a work/file/part. This tag can 
also include an ‘exception-id’ of course in the form of “‘license-id’ WITH 
‘exception-id’”.

The issue I have with this is the inconsistency and therefore potential 
confusion. Namely: On face value ‘SPDX-Exception-Identifier’ and ’SPDX-
License-Identifier’ seem to be part of one spec and ‘Valid-License-Identifier’ 
of another; but the truth is that the first and the last are of one origin, 
and the middle is in fact the one with a different origin.

It seems as if initially the SPDX tags  ’SPDX-License-Identifier’ and ‘SPDX-
Exception-Identifier’ were used, but then the former changed to ‘Valid-
License-Identifier’ in order to avoid confusion. But the exception tag was 
left unchanged, as it did not clash directly with SPDX specs, which brings us 
to this mess.

Would it be possible to change the  ’SPDX-Exception-Identifier’ to ‘Valid-
Exception-Identifier’ in the Linux kernel and REUSE.software best practices? I 
know that this is not an SPDX question directly, but I am pretty sure people 
involved with both projects are here as well and it is paramount to not break 
SPDX specs while finding a solution.


cheers,
Matija Šuklje
—
1   I don’t need a doctor, just your guidance here ;)
2   https://reuse.software/practices/2.0/
3   https://www.kernel.org/doc/html/v4.17/process/license-rules.html
4   https://spdx.org/spdx-specification-21-web-version
-- 
gsm:+386 41 849 552
www:http://matija.suklje.name
xmpp:   matija.suk...@gabbler.org
sip:matija_suk...@ippi.fr




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2344): https://lists.spdx.org/g/Spdx-legal/message/2344
Mute This Topic: https://lists.spdx.org/mt/24005641/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-