search

OpenChain-Project / Reference-Material

This repository contains the reference material related to the OpenChain Project
Other
71 stars 56 forks source link

Removed figure. Minor edits and consistency updates. #76

Closed myagi2019 closed 4 months ago

shanecoughlan commented 4 months ago

@myagi2019 thanks for making this happen!

@andrewjskatz ok to send to Japan for final review of the document and then proceed to release?

andrewjskatz commented 4 months ago

Thanks Shane

It’s looking good. However, we agreed in the meeting that if we didn’t get any showstopper comments by COB on 14th May, at that point, we would submit to Japan and then release, so please can we hold until then?

I do have a couple of queries with the text.

In the section "What is granted be licenses (Patents)" the word "grants" should be changed to "explicitly grants" (twice) and "grant" to "explicit grant".

In the section "what you need to do to receive the benefits of open source" a new sentence should be added at the end: "Some licenses (e.g. AGPL and Open Software License) can also impose conditions similar to conditions on distribution, when the functionality of the software is accessed over a network, but the user does not receive a copy of of the software itself".

In the following section, a new para 5 needs adding:

"5. Some licenses (such as AGPL or the Open Software License) impose conditions on use of the software where the functionality of the software is made available to third parties (e.g. a user accessing a SaaS service using the software). These so-called "deemed distribution" licenses require that (in certain circumstances) the end-user is entitled to the source code of the software, even if the software code itself is not distributed to them."

I also have a couple of other points I'd like to address, so I am happy to issue a pull request for these shortly, and then they can be considered prior to the 14 May deadline. For my own reference:

  1. Check the wording on the definition of "open source"
  2. MPL 2.0 does not have a modification notice provision
  3. Open source licenses have "conditions" rather than "obligations"
  4. Care with patent language (allow for implied licenses)
  5. It's still necessary to comply with open-source-like licenses (e.g. JSON, SSPL), so this should be highlighted

Thanks

Andrew

kappapiana commented 4 months ago

Andrew,

it all sounds correct. However, while it's OK that they may fall within the scope of Open Chain, I am concerned by using "open-source-like" license for licenses which are non "like" open source, they are just NOT Open Source, they just share some features. Maybe we could call them "source available" (I think I have heard it being used) or "limitedly open" or something that does not call into question the fact that they might be confused with FOSS or that there is a continuum or a spectrum or that openness really spans across the border of open?

All the best,

Carlo

Da: "Andrew Katz" @.> A: "OpenChain-Project/Reference-Material" @.> Cc: "Subscribed" @.***> Inviato: Giovedì, 9 maggio 2024 8:00:09 Oggetto: Re: [OpenChain-Project/Reference-Material] Removed figure. Minor edits and consistency updates. (PR #76)

Thanks Shane

It’s looking good. However, we agreed in the meeting that if we didn’t get any showstopper comments by COB on 14th May, at that point, we would submit to Japan and then release, so please can we hold until then?

I do have a couple of queries with the text.

In the section "What is granted be licenses (Patents)" the word "grants" should be changed to "explicitly grants" (twice) and "grant" to "explicit grant".

In the section "what you need to do to receive the benefits of open source" a new sentence should be added at the end: "Some licenses (e.g. AGPL and Open Software License) can also impose conditions similar to conditions on distribution, when the functionality of the software is accessed over a network, but the user does not receive a copy of of the software itself".

In the following section, a new para 5 needs adding:

"5. Some licenses (such as AGPL or the Open Software License) impose conditions on use of the software where the functionality of the software is made available to third parties (e.g. a user accessing a SaaS service using the software). These so-called "deemed distribution" licenses require that (in certain circumstances) the end-user is entitled to the source code of the software, even if the software code itself is not distributed to them."

I also have a couple of other points I'd like to address, so I am happy to issue a pull request for these shortly, and then they can be considered prior to the 14 May deadline. For my own reference:

1. Check the wording on the definition of "open source"
2. MPL 2.0 does not have a modification notice provision
3. Open source licenses have "conditions" rather than "obligations"
4. Care with patent language (allow for implied licenses)
  1. It's still necessary to comply with open-source-like licenses (e.g. JSON, SSPL), so this should be highlighted

Thanks

Andrew

— Reply to this email directly, [ https://github.com/OpenChain-Project/Reference-Material/pull/76#issuecomment-2101995108 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AGANHLZTFZOA4MBTYYU43ITZBMGGTAVCNFSM6AAAAABHMR4AYSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBRHE4TKMJQHA | unsubscribe ] . You are receiving this because you are subscribed to this thread. Message ID: <OpenChain-Project/Reference-Material/pull/76/c2101995108 @ github . com>

shanecoughlan commented 3 months ago

@kappapiana + @andrewjskatz We seem to be running up against a fascinating issue. There used to be a clear industry line between open source (with its spectrum of permissive to copyleft) and proprietary (with its spectrum of relative flexibility to low flexibility).

Now we are seeing the emergence of something in the middle, splitting the difference between aspects of open source and flexible propriety licenses.

This hints at a new spectrum encompassing the full range from copyleft to low flexibility proprietary licenses. This is a space that is under-addressed from a strategic level, though the discussion around the new “source available” or “same as open source but except for this term” licenses is gaining momentum.

What is the correct terminology to address the evolving market? Undetermined. We do need to avoid confusion. But we also do need to cover the emerging spectrum. It’s a TBD moment.

Anyway, OpenChain standards refer to FSD, OSD or similar licenses. While our editors did not foresee recent developments per se (IIRC the intent was to cover licenses not included in FSD or OSD lists), we are already positioned to provide value as the market sorts itself out.

kappapiana commented 3 months ago

I beg to differ. There is no new evolution, it's the same old dichotomy between proprietary and open, where one branch tries to mimic some traits of open source. Only that certain shades of proprietary have elements in common and may require similar controls and practices as open source. From the point of view of Openchain, the processes may be very similar if not identical and I would think that covering that space is a natural evolution of the standard, while the challenges may be even higher (see the vagueness of non-competition or ethical licenses, which I would not touch with a stick, wearing gloves --- cit). Creating a dictionary for this "new" space is a problem, as people could be confused and think that, all in all, they are shades of the same spectrum, which they are not. Open source has mainly copyleft/weak copyleft and permissive. This space conversely has several vectors of limited or full permissions, which could be treacherous to navigate and need also a lot of specific education, not very dissimilar from vetting a EULA, to match the limited permission with the use case, on the top of the usual checks of conditional permissions.

myagi2019 commented 3 months ago

“same as open source but except for this term” licenses These have been around for a long time. They are around the fuzziness of what is open source Shane and Jeffrey discussed a few calls back.

What is the correct terminology to address the evolving market? Undetermined. We do need to avoid confusion. But we also do need to cover the emerging spectrum. It’s a TBD moment.

IMO its up to the Organisation to decide (potentially including upstream suppliers) whether something is handled via its "open source" compliance processes or its "proprietary license" compliance processes. I've seen items go needlessly ping-pong between internal compliance teams just because of a strict definition of what is (or isn't) open source and a disagreement as to who should handle it.

In principle I agree with the kinds of changes Andrew suggested and await a PR to review with bated breath ;)

kappapiana commented 3 months ago

Dear Shane, all,

I had written a longer reply, but it probably went amiss and I can't find it anywhere.

Gist: nothing new, it's same old, same old, proprietary/open source dichotomy. Many projects have decided to cross the line and become not Open Source any more, but trying to hybridize the model to get the best of the two worlds (arguably; probably they've got the good of neither), and several have converged to the same point from the opposite direction.

But I ack that:

I am afraid that the rhetoric "openness is a continuum" does no good neither to "somewhat open, somewhat close" licensed software, nor to Open Source. One needs to be clear of what they have in common (public, conditioned permission) and what separates them (permission is not given for all Four Freedoms). And the attached risk analysis is also very different.

Additional note, this kind of "rug pulling" (sudden change of licensing conditions moving off the Open Source realm) creates additional perceived risk for single-sourced Open Source software, I have several clients burned by ElasticSearch questioning if Open Source is a reliable source of technology at all: the externalities are incredibly high. But I am digressing.

So: same process? Probably yes (the entity must decide whether to adopt OpenChain or not, depending on many factors). Same-same process? No, need to add more layers of complexity and update the incompatibility matrix, adding at least one dimension.

IMHO OpenChain must be very careful in messaging, avoiding at all any "spectrum" language, treating the coverage of proprietary licensed software that sport many Open Source traits, but do not make the cut, as a separate, yet practically close, thing.

My two personal cents. And I suspect OSI vision is pretty similar (I am not committing to their position, we need to discuss and the official position might be different).

All the best,

Carlo

Da: "Shane Coughlan" @.> A: "OpenChain-Project/Reference-Material" @.> Cc: "kappapiana" @.>, "Mention" @.> Inviato: Venerdì, 17 maggio 2024 12:38:48 Oggetto: Re: [OpenChain-Project/Reference-Material] Removed figure. Minor edits and consistency updates. (PR #76)

[ https://github.com/kappapiana | @kappapiana ] + [ https://github.com/andrewjskatz | @andrewjskatz ] We seem to be running up against a fascinating issue. There used to be a clear industry line between open source (with its spectrum of permissive to copyleft) and proprietary (with its spectrum of relative flexibility to low flexibility).

Now we are seeing the emergence of something in the middle, splitting the difference between aspects of open source and flexible propriety licenses.

This hints at a new spectrum encompassing the full range from copyleft to low flexibility proprietary licenses. This is a space that is under-addressed from a strategic level, though the discussion around the new “source available” or “same as open source but except for this term” licenses is gaining momentum.

What is the correct terminology to address the evolving market? Undetermined. We do need to avoid confusion. But we also do need to cover the emerging spectrum. It’s a TBD moment.

Anyway, OpenChain standards refer to FSD, OSD or similar licenses. While our editors did not foresee recent developments per se (IIRC the intent was to cover licenses not included in FSD or OSD lists), we are already positioned to provide value as the market sorts itself out.

— Reply to this email directly, [ https://github.com/OpenChain-Project/Reference-Material/pull/76#issuecomment-2117276103 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AGANHL64MAYN7ITQGSURMI3ZCXM3RAVCNFSM6AAAAABHMR4AYSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJXGI3TMMJQGM | unsubscribe ] . You are receiving this because you were mentioned. Message ID: <OpenChain-Project/Reference-Material/pull/76/c2117276103 @ github . com>

shanecoughlan commented 3 months ago

@kappapiana great points all. I am thinking about how to tie this together for "elevator pitches" in conference hallway tracks.

How would something like the following work:

There are various types of license.

  1. Open source licenses, which meet the type of requirements explained in the Open Source Definition or the Free Software Definition. They are characterized by being permissionless for every use and combination.
  2. Proprietary licenses, which are usually bespoke - not shared across products or companies - and which tend to take the opposite approach, and introduce significant restrictions on how software can be used.
  3. Licenses will more permissions than traditional proprietary licenses, but a more limited set of permissions than open source, particularly around how the software can be used.
kappapiana commented 3 months ago

@shanecoughlan it seems like a good, dispassionate characterization overall. Mmy point is also that a SWOT analysis of the three model is shaped and rotated differently too. So that's another talking point. Moreover, one should apply it differently if discussing the distributed artifact or the development model. All of them are relevant when sourcing from your supply chain, for the short or the long run.