1. posterid:1160242
  2. Messages

Re: Proposed spec for external packages

Philip Odence
 

Adding to Kate’s comments, the SPDX presumption is that developers of open source software would like to:
a. have their software used by others
b. make sure the software is used under the terms they desire, as expressed in a license

We believe SPDX makes is easier for organizations to use open source and to make sure they comply with the developer’s desires, and therefore aligns with the above. That’s why we don’t think the idea is fundamentally flawed. We do understand that even assuming we are right, there’s a chicken/egg problem in getting producers of open source to participate.


From: Kate Stewart <kstewart@...>
Date: Tuesday, August 4, 2015 at 2:09 PM
To: Mike Milinkovich <mike.milinkovich@...>
Cc: "spdx@..." <spdx@...>
Subject: Re: Proposed spec for external packages

On Tue, Aug 4, 2015 at 11:40 AM, Mike Milinkovich <mike.milinkovich@...> wrote:
On 04/08/2015 12:15 PM, Kate Stewart wrote:
I agree we should not depend on closed standards.  However,  the question is do we want to be able to reference to external packages that other systems are supporting?

Beats me. But to me the proposed solution looks much worse than whatever problem it is that you're trying to solve. Speaking of which, where is the document that describes the problem you're trying to solve?

The base document that these changes are being proposed for is SPDX 2.0 see: http://spdx.org/SPDX-specifications/spdx-version-2.0 

My impression is that the consumers of open source software are trying to create a system to make it easier to identify and manage the artifacts used within their organization. Is that correct?

The goal of software package data exchange (SPDX) is to create a common way to communicate copyright and licensing information in the entire ecosystem.   There are producers and consumers through out the entire supply chain.   

Open source projects are built on top of other open source projects all the time (libraries, dependencies, etc.)    Providing a clear way that can be machine readable and trusted, will allow a lot of the discussions about what license applies, etc. to go away.    If this key information is a transparent part of the package - rather than a time intensive opaque exploration,  then its easier for other open source projects that use that package,  to comply with the terms of the code they are using.    Upstream projects can use it to ensure clarity about the licenses the code is provided under, and enable automation (and stop getting bugged by folks who are trying to interpret their wishes).  Distributions and Packagers (including other open software distribution), can use it to summarize what they've received from elsewhere (ie. upstreams) and what they've added.   
 
If so, what I am missing is how you are going to motivate the producers of open source to use such a system. You're already getting our libre software for free. Why are we going to do more work to make your lives easier?

Many open source packages depend on other open source packages - making it clear what obligations come with the use of the software saves the developers lots of investigation work - whether they are part of an open source project or a commercial company that is developing software. 

If we can have open tools that are trusted to generate these software license summaries, it will stop developers from having to do full manual inspection when releasing their software.
 

My apologies in advance if I'm completely off base here.

Happy to discuss the goals of this further with you in a phone call some time.

Kate

 

Join spdx@lists.spdx.org to automatically receive all group messages.