Hi Egmont, I don't think it's important to use licensing to prevent incompatible versions of the specification. Compatibility is important, but it's ensured by having a single place which everyone agrees is the canonical version of the specification. Many specifications are also usefully amended and updated in later versions, to clarify details or add extra capabilities - this could be harder if the license forbids modifications and the original author is no longer actively involved. If there's any doubt on whether an implementation is a derivative work of the specification, I think it would be best to add a note that implementations are not meant to be bound by license conditions on the specification. But I'd favour using a simple permissive license for the specification in the first place. Best wishes, Thomas
On Wed, Jan 2, 2019, at 1:02 PM, Egmont Koblinger wrote: > Hello, > > I'm new on this list. I've been working on a specification for a few > months that will kindly be hosted on FDO.> > Pretty much the only remaining step is to pick a license for my work.> > I've seen some relevant discussions on this mailing list between March- > May 2018. What I haven't seen, though, is some evaluation of the > potential licenses and guidelines to pick one, nor the final choices > you went for.> > I tried to read and interpret some of the popular licenses. The lack > of good web search matches, and in particular [1] and [2] suggest to > me that there isn't any designed or well suited for specifications.> > My first big dilemma: I'm wondering what does "free" mean in the > context of specifications, and what does FDO want it to mean on its > site and in its overall vision.> > My instincts tell me that a "free specification" should be one that > everybody is free to implement, without imposing restrictions on the > implementation. That is: okay to implement in a closed source > commercial application. As per [1], it's unclear whether an > implementation of a specification counts as "derived work" or not, and > thus whether CC BY-SA allows this.> > Debian's guideline of being "free" instead seems to focus on the > modification and distribution of the material in question instead. > E.g. they only consider GFDL free if it doesn't have an invariant > section. For a piece of software or documentation, Debian's is a > reasonable approach. For specifications I don't think so. And this > leads to my second big dilemma.> > For specifications, even for "free" ones, I think it's outright > undesirable to create and distribute modified work. In order to avoid > incompatible specifications competing against each other, resulting in > quite a mess and poor interoperability between implementations, > contributors should be pushed to improve the original specification > whenever feasible (e.g. the project is maintained actively), or > perhaps come up with extensions as separate new projects that > potentially refer to the original one, but should not create forks and > slightly altered variants (especially in backwards incompatible ways) > of the original.> > Not sure if this restriction belongs to the license, though, or should > sort itself out by other means, e.g. by the original work having some > "respect" and the community refusing to go with forks.> > Also note that even if the license chosen for a specification > disallows the creation of modified work, it should probably still be > allowed if done with the explicit intent of sending suggested > modifications back to mainstream. (If I understand correctly, CC BY-ND > doesn't allow the creation of publicly visible merge request?)> > I would not like to release my work to the public domain / CC0 or so. > Ideally I wouldn't want others to distribute my work (the > specification itself, or parts of it) commercially, so I'm not keen on > CC BY either. And, since I'm not a laywer, I wouldn't want to come up > with something custom.> > Something that occurred to me as a little bit of custom, though, is CC > BY-SA clarifying that implementing in commercial apps is okay. Since > I'm not confident enough to amend the CC license by a sentence, > technically I'm thinking of addressing it by dual-licensing my work > under CC BY-SA and a self-written sentence along the lines of "okay to > implement anywhere, all other rights reserved". Users would need to > pick one of these two, contributors would need accept this OR- > combination of them. This is the approach I like the most so far, but > I'm not sure if it makes sense to you guys too, or if maybe you see a > red flag.> > Or, what happens if I just release without any licensing? What are the > downsides of that approach? Why is it important or encouraged to have > a license? Aren't the "legal defaults" of any published work without a > license good enough, and perhaps closer to what I imagine than any of > these existing license texts? Note that most of the standards I used > during my work, e.g. ECMA ones, come without a license.> > What do you guys think of these? Which licenses did you consider? > Which ones do you or do you not recommend? Which one did you end up > choosing for specifications, and what were the main reasons behind > your decisions?> > Thanks a lot, > > egmont > (gnome-terminal/vte developer) > > [1] https://lu.is/blog/2008/03/27/brief-cc-licensed-specification-rant/> [2] > https://creativecommons.org/2008/03/29/what-good-is-a-cc-licensed-specification/> > _________________________________________________ > xdg mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/xdg
_______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
