Identification of placeholders in license fulltext

[mspiegel]

Great project! Is there any interest in either standardizing or maybe some meta data annotation the placeholders that are present in the full text of several of the licenses? Some of the licenses use square brackets, some use angle brackets, some use an underscore, etc. Identifying the placeholders is one way to automatically infer the license from the full text. Or maybe there is another approach that I am missing.

[tianon]

Not a maintainer here, but I think the license text here comes directly from the relevant upstream's official license files, usually completely unchanged (and I've filed at least one PR to close a discrepancy between upstream's file and the file here; #20).

[mspiegel]

Got it. Maybe then the placeholder location should be annotated in another
file? I believe a saw some files that already contain metadata information.
On Apr 26, 2016 4:12 PM, "Tianon Gravi" [email protected] wrote:

Not a maintainer here, but I think the license text here comes directly
from the relevant upstream's official license files, usually completely
unchanged (and I've filed at least one PR to close a discrepancy between
upstream's file and the file here; #20
#20).

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#31 (comment)

[paultag]

Yeah! So, I love this idea, but I love the idea of taking out the templates
for source headers and letting folks write out source headers.

The question is, what is the best language agnostic choice?

Let's split this out into text/templates - I have a flight tonight, I might
PoC this!
On Apr 26, 2016 4:03 PM, "mspiegel" [email protected] wrote:

Great project! Is there any interest in either standardizing or maybe some
meta data annotation the placeholders that are present in the full text of
several of the licenses? Some of the licenses use square brackets, some use
angle brackets, some use an underscore, etc. Identifying the placeholders
is one way to automatically infer the license from the full text. Or maybe
there is another approach that I am missing.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#31

[mspiegel]

I was thinking about taking a stab at this. @paultag is that ok with you?

[paultag]

Go for it! All yours!
On Apr 26, 2016 7:55 PM, "mspiegel" [email protected] wrote:

I was thinking about taking a stab at this. @paultag
https://github.com/paultag is that ok with you?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#31 (comment)

[mspiegel]

Thanks! Safe travels.

[mspiegel]

I have a question to give me some additional background about this project: why not leverage the SPDX tools? There seems to be a lot of potential with that group. Granted a lot of the work remains to be done. Specifically http://schd.ws/hosted_files/collabsummit2016/49/Unpected%20Journey%20License%20Matching%20-%202016%20Collab%20Presentation%20-V3.pdf,
http://wiki.spdx.org/view/Legal_Team/Template_proposal, and
https://github.com/myndzi/license-list/tree/xml-test/src.

I'm going to do some more reading into the SPDX tools.

[paultag]

Seems like a fun serialization target, maybe file a PR (or another repo) to
do the transformation into XML
On Apr 26, 2016 9:42 PM, "Michael Spiegel" [email protected] wrote:

I have a question to give me some additional background about this
project: why not leverage the SPDX tools? There seems to be a lot of
potential with that group. Granted a lot of the work remains to be done.
Specifically
http://schd.ws/hosted_files/collabsummit2016/49/Unpected%20Journey%20License%20Matching%20-%202016%20Collab%20Presentation%20-V3.pdf
,
http://wiki.spdx.org/view/Legal_Team/Template_proposal, and
https://github.com/myndzi/license-list/tree/xml-test/src.

I'm going to do some more reading into the SPDX tools.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#31 (comment)

[paultag]

@mspiegel Anything worth noting that you've learned? As far as I can tell, they're mostly using XML as a template language, which I'm tempted not to do, seems like a ton of complexity. Honestly, just using a Go template, and allowing multiple "output" formats in other popular template frameworks (such as Jinja) seems fine for now.

Want to take a crack at a PoC with 3-4 licenses up against here and the API?

[mspiegel]

I think I'm missing some context: I see some overlap between the efforts of the open source initiative and the SPDX community. The SPDX machine readable license effort is currently evolving it is not yet complete. What I like about the effort is that there seems to be a community of people involved, and some of them work on products that test for license compliance. From the discussion on the wikis and the mailing list the people with background experience seem willing to share that experience. What I don't like about the SPDX community is that progress on the standard is scattered across a wiki, a mailing list, an internal git repository, and a separate issue tracking system. But I've seen on their roadmap they might be moving everything to GitHub this year. I'm going to try to lend my efforts to the SPDX work, I am seeing that standard being picked up by several communities.

[paultag]

@mspiegel This work is not incompatible - this is simply a canonical aggregation about the status of open source licenses, as defined by the OSI. Crosswalks to SPDX, which are already in the dataset, will allow the existing SPDX work to automatically pull OSI approval status (and other metadata that we might add) into the SPDX work.

That being said, you should spend your time how you want your time to be spent, and I would be thrilled to see more work going into SPDX :) 👍

[webmink]

Hi all! Returning to the project for a restart, I wonder if this issue still has legs and if so how to handle going forward?