GSoC 2013 - Embedding of license and attribution metadata
Hi I'm studying Master in Software Engineering at Mälardalen University in Sweden and looking in to the possiblities of participating in GSoC 2013. I've used Inkscape for several years as a user and want a deeper understanding of how c/c++ is used in larger projects so I feel that Inkscape can be a good project for me. Enough about me for this time, as Johan Engelen posted in an earlier conversation [1] I will try to spend my time fixing bugs instead of "fine tuning" my GSoC application.
So to my suggestion and questions. For the last weeks I've been in contact with Jonas Öberg a Shuttleworth Fellow running the project "License and attribution metadata" [2,3]. With start from the 1st of June 2013 they will begin their work of developing a library for storing license and attribution metadata in digital works.
My suggestion for GSoC 2013 is to use that library in Inkscape. There are both benefits and problems that comes with trying to use a library while it's still in alpha/prototype stages so what do you think about this?
1) Is this work of any interest?
2) What do you think about developing the additions to Inkscape as GSoC project in parallell with creation of a library for this?
[1] http://inkscape.13.x6.nabble.com/Guides-Improvement-and-GSoC-2013-td4966479.... [2] http://jonasoberg.net/post/40518443141/embedded-metadata-for-digital-works [3] http://www.shuttleworthfoundation.org/fellows/jonas-oberg/
Regards
On Fri, 2013-04-12 at 15:32 +0200, Christoffer Holmstedt wrote:
My suggestion for GSoC 2013 is to use that library in Inkscape. There are both benefits and problems that comes with trying to use a library while it's still in alpha/prototype stages so what do you think about this?
- Is this work of any interest?
Inkscape already supports the ability to put the license information in the file. It's in the File menu under Document Metadata. You can basically use Dublin Core to put a bunch of other information in there as well. It's stored in a proper namespace in the XML document.
I think there are two interesting problems that we don't solve well. The first is reading this data from external formats. We basically only support it for SVG. The second is dealing with imports. So if I've got my SVG document and I import data from another, and that has a conflicting license or one that puts restrictions on my document, we don't warn or notify in any way. It seems like we could protect artists from accidentally using another work incorrectly in that way.
Ted
Thanks for the fast reply Ted. Interesting comments and I had totally missed the metadata settings.
I will look into the problem of importing/reading metadata from other formats.
Concerning the second issue on notifying the user seems like a bigger issue than just implementing the feature. When should the user be warned? Which licenses do conflict with each other? How should the user be notified, a popup or just a small red icon somewhere? (For me this sounds too big for GSoC but really interesting).
On Fri, 2013-04-12 at 16:27 +0200, Christoffer Holmstedt wrote:
Concerning the second issue on notifying the user seems like a bigger issue than just implementing the feature. When should the user be warned? Which licenses do conflict with each other? How should the user be notified, a popup or just a small red icon somewhere? (For me this sounds too big for GSoC but really interesting).
Well, yes. How do you think it should be shown? Propose something, we'd be happy to help refine it. I think that this is part of the project proposal ;-)
I think it could be a reasonable GSoC if you just focused on the Creative Commons licenses and how they interact. They're fairly well defined and understood there. Rights in general has as many cases as there are lawyers in the world, so you'd have a harder time finding out whether "can't show on a billboard" applies to this document.
Ted
On Fri, 2013-04-12 at 10:35 -0500, Ted Gould wrote:
Creative Commons licenses
And PD as an exception don't forget! :-)
My concern here is that users shouldn't be prevented from using works for incompatible or ARR. For fair use, transformative works and reference works.
I think that you're only going to warn, so it's no problem.
Martin,
On Fri, Apr 12, 2013 at 11:10 AM, Martin Owens <doctormo@...400...> wrote:
I think that you're only going to warn, so it's no problem.
Yeah - every once in a while I get stuck running pdfcrack because the "company logo" sent is actually some brochure or something with the editing rights locked down. A warning in the status bar or even a pop-up wouldn't bother me much - but having to stop and work around DRM is no fun at all ;)
Chris
To work with CC licenses and PD (I assume it means public domain here) sounds like a reasonable size for a project and a fun one. I will try to come up with a suggestion this week while I dig deeper into Inkscape codebase. Any pointers to where the metadata features are found in the code?
Off-topic: Do you have any mailing list rules/policy? I noticed I was the only one top posting here which can be annoying if you're not supposed to do that =)
Regards
2013/4/15 Christoffer Holmstedt <christoffer.holmstedt@...400...>:
To work with CC licenses and PD (I assume it means public domain here) sounds like a reasonable size for a project and a fun one. I will try to come up with a suggestion this week while I dig deeper into Inkscape codebase. Any pointers to where the metadata features are found in the code?
Start from: src/ui/dialog/document-metadata.* src/rdf.*
Off-topic: Do you have any mailing list rules/policy? I noticed I was the only one top posting here which can be annoying if you're not supposed to do that =)
I think top posting is OK when you are replying to an email as a whole, while if you are replying to specific parts, you should bottom-post below the relevant fragments.
Regards, Krzysztof
participants (5)
-
Chris Mohler -
Christoffer Holmstedt -
Krzysztof Kosiński -
Martin Owens -
Ted Gould