Hacker Newsnew | comments | show | ask | jobs | submitlogin
Concord, our GPL outliner (scripting.com)
65 points by tjr 561 days ago | 61 comments



GPL? How does this interact (legally) with other running JavaScript? Do I have to make the rest of my site's JavaScript "GPL" as a result?

I'm curious, does the dynamic nature of JavaScript make browser-based GPL Javascript essentially LGPL? Any lawyers or FSF advocates out there know?

-----


I have no problems with the GPL or releasing software under it. But if I'm also using MIT code, should I simply release the result as GPL? And could I upgrade that up to an AGPL (which the outliner could have used, being serviceable online.)

-----


IANAL, yadda yadda and hypothetical implementation details (linkage, etc) could make arguments to the contrary. From GPLv3/Wikipedia:

'A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.'

In other words, your MIT library is an independent work and does not limit the rights imparted by the other pieces (namely, the GPL pieces). This is somewhat important since you (presumably) don't own the copyright to that MIT work and so your options for relicensing it are limited.

Meanwhile, your code is a direct, derivative work of the GPL code and at a minimum, must be made available under the GPL. You can additionally release under other licenses, provided that those licenses do not conflict with the GPL. A "public domain" non-license might work. And again, you must always offer a GPL option.

I don't know how the AGPL applies here. I would guess that it's pretty much the same except you acquire those above GPL rights just by consuming the output of the code (e.g. visiting the webpage).

-----


I've never seen a good answer to that question. I've emailed the FSF and others and they all tell me to consult a lawyer for how the license works (if they respond at all).

-----


IANAL, but the spirit seems to be "hey, here's this software, use it how you like, but if you distribute it (including building on it or bundling it in a product) please be kind enough to extend the same freedoms to those you give it to."

Using Concord on your site? Offer a link to the source. Modify it to work better with a framework? Offer that modification too. Build an entire product off of it? Well, be prepared to release the source to that product under GPL as well. If you don't like those terms, feel free to start from scratch and not freeload off the original authors who were kind enough to share source with you in the first place.

I don't understand how people can pay good money for things like game engines, then turn around and think that OSS doesn't have a price too, or get upset when they are asked to pay it. You just end up paying back to the community instead of into a company's coffers.

-----


Not all OSS has a price. All of the code I've releases is under a free license, not a restrictive one like the GPL. This does mean that companies can use my code in their proprietary projects, but that seems to have gotten me more contributions back instead of less.

I also think that a license which is too complicated for anyone to actually understand is simply too flawed to serve it's purpose, which was the original point of my post. This is completely separate from people not giving back to open source.

-----


That's what the LGPL is for, if you prefer that one (I don't; I prefer the MPL to the LGPL, as it's share-alike restrictions trigger on internal changes).

The GPL is less suitable for this because means that all of your code for the page(s) using Concord have to be GPL-compatible. Presumably, this includes Urchin.

-----


And most important, no gratuitous incompatibility or user lock-in based on formats. Commercial developers esp ones that raise huge money, tend to try to lock users in. If that's their plan, they can write their own outliner, should that situation ever arise.

-----


Use of the GPL doesn't merely prevent commercial developers from creating non-compatible formats -- it prevents them from using Concord at all. Let's say I want to build a commercial app that happens to use Concord, and I'm happy to use Concord as is (contributing back any patches or improvements I make) and even make the outlines exportable (assume outlining is just one feature in a much larger app, not the main focus). In that case, I'd have to make much or possibly all of the client-side code GPL compatible, so I can't use Concord, even though I'm not violating your rule about compatibility and am contributing back to the Concord community.

GPL seems like overkill given your goal. It will be limited to a niche of either fully open source public applications or completely private/internal applications.

-----


If you modify Concord to use on your site (ie: to provide a service) then you do not need to distribute the modification.

However, if you incorporate Concord into a product you sell, then you either need to provide the source per the provisions of the GPL, or else negotiate a different license from Winer.

-----


It is probably best to just contact the author and ask their opinion about that. For example, proprietary linux kernel drivers seem to be in a gray zone (to put it mildly), but in practice they are tolerated (whether or not the FSF approves of that).

-----


Tolerated? If only barely: http://www.kroah.com/log/linux/stable_api_nonsense.html also:

Basically, I want people to know that when they use binary-only modules, it's THEIR problem. I want people to know that in their bones, and I want it shouted out from the rooftops. I want people to wake up in a cold sweat every once in a while if they use binary-only modules. -- Linus Torvalds

As a Linux user (and previous developer) I can only commend these positions. I don't care about hardware companies' "intellectual property", all I want is to pay for hardware and have good drivers that don't wreak havoc with my system.

-----


Their existence is absolutely tolerated. They are not liked by any means, nor are they accommodated, but they are allowed to exist (ie, tolerated).

-----


I've never seen a good answer either, despite searching for one. I've also seen a lot of smart people that are confused by the GPL despite reading a lot about it. I've seen much less of this confusion with other copyleft licenses, like the EPL in the Clojure community.

The GPL sucks, full stop.

-----


A law professor at University of Washington has attempted to make a license that is essentially equivalent, and compatible with, GPLv2, but that is not confusing. The result is the Simple Public License [1]. It is OSI approved.

[1] http://www.law.washington.edu/casrip/license/

-----


The GPL is not about being practical, it's about freedom. That's why it's the only licence I would consider releasing software under.

-----


It's not about freedom, and I'm a bit sick of that Orwellian categorization (War is Peace, Freedom is Slavery, Ignorance is Strength). Unlike other open source licenses which outline your rights, the GPL is a document that is filled with taking rights away. It's also ridiculously complicated, to the point where no one is completely clear on what is or isn't allowed (and the LGPL is even worse).

It's not practical and it's not free. That's why I'd never consider releasing software under it.

-----


I wholeheartedly disagree to your first two statements. I would guess that the GPL just prioritizes freedoms differently than you would prefer. Namely, that access to the source code and the ability to fix bugs out-of-band of the original author is higher than your rights to fully commercialize and restrict access to the code, in the way that the BSD license allows. In a "wishing for infinite wishes" sort of way, the GPL is about removing the freedom to take away any more freedoms. So yes it is constricting in a sense but in a very targeted fashion.

I will agree that it is complicated but that's a result of years of companies abusing loopholes and the nature of trying to cover every conceivable scenario. It's an old codebase but still the best we have.

Practicality is never the consideration of an idealist and the GPL is definitely the product of an idealist. RMS has often appeared like a crazy old man but as time passes, he seems to be proven right more often than wrong. A consequence of idealism and the march of progress, maybe.

You're of course well within your rights to choose a different way but your characterization of the GPL not being about freedom is a bit off the mark.

-----


>the GPL is a document that is filled with taking rights away

It's a document that gives and preserves rights of the end user, which include the right to the source code and the right to modify and distribute.

How could it possibly 'take away' rights? Any rights not in the licence didn't exist in the first place and thus can't be 'taken away'.

A licence is a set of conditions which a code author/owner sets for using his/her code, any 'rights' you have to their code is that of the conditions they set.

If a developer chooses GPL for their code then those are the rights to which you can use their code, no rights have been 'taken away from you' at all, it's not your code.

And it's certainly practical, which I'm certain is the reason that it's the most used open source licence.

One particular aspect which makes it practical from a developer standpoint is that if they release their code under GPL they have the right to source code modifications made to their code as end users of such modifications.

There is no BEST licence, the licence profileration is a direct consequence of our different needs and values.

-----


How does a license being confusing to the people that use it (and somewhat to the people that WROTE it) aid in promoting freedom?

-----


I find it a bit dishonest when people describe GPL as confusing.

Sure, anything can be confusing. A door nob is surely confusing to some people, especially if they never seen one before. But a door nob is not inherently confusing, and intellectually honest people would not describe it as such.

Let me ask, what is confusing about a license that say:

  You can and may do anything with this code, so long you allow others to do the same,
  and to any modified version you might create.
There is nothing in the license text beyond that. If all countries legal system was perfectly sane, and that text would be legally full proof, that would be the license text. Since we do not live in utopia, the license text is a bit longer to describe what "can" and "may" mean.

To quote the license:

  To protect your rights, we need to prevent others from denying you these rights or
  asking you to surrender the rights. Therefore, you have certain responsibilities if
  you distribute copies of the software, or if you modify it: responsibilities to
  respect the freedom of others.
Who can say that they are confused by this? tzs, are you really, honestly, confused by that sentence?

-----


The same reason it is hard to learn Emacs, but in the long run learning the tool is worth the startup cost a thousand times.

-----


If commercial developers want to add private features to the outliner, we will try to work with them. We just want to be sure we can have a conversation about compatibility, and perhaps create revenue to fund development.

If someone had specific questions about how she could build on this, surely she would just reach out to Dave and have a conversation?

-----


> GPL? How does this interact (legally) with other running JavaScript? Do I have to make the rest of my site's JavaScript "GPL" as a result?

That has been the interpretation of the guys distributing extjs.

-----


I've been browsing through the code a bit. It has a few problems.

First, the brace and indentation style is extremely unusual and hard to follow. I have never seen this style used in another curly-brace-language project anywhere.

I realize that brace and indentation is a very personal preference, but I've had no trouble following a variety of styles - until this one. Here's an example:

  if(c.op.inTextMode()){
      c.op.focusCursor();
      c.editor.restoreSelection();
      }else{
          c.pasteBinFocus();
          }
The if block and matching else block have different indentation levels? What? That does seem to be the pattern followed in a number of places.

How would you follow this style if there is a chain of else-if's? I don't see any examples in the code, but it seems it would have to look like this to be consistent:

  if(a){
      b();
      }else if(c){
          d();
          }else if(e){
              f();
              }else{
                  g();
                  }
OTOH, this function follows two different indentation styles for its two if/else blocks:

  this.callbacks = function(callbacks) {
      if(callbacks) {
          this.root.data("callbacks", callbacks);
          return callbacks;
      } else {
          if(this.root.data("callbacks")) {
              return this.root.data("callbacks");
              } else {
                  return {};
                  }
          }
      };
Try this quiz: Without loading the code into a brace-matching editor, just eyeball that function and see if you can tell which open brace matches with which close brace.

The function could be much simpler too:

  this.callbacks = function( callbacks ) {
      return callbacks ?
          this.root.data( "callbacks", callbacks ) :
          this.root.data( "callbacks" ) || {};
  };
Also in a half-dozen places or so, the code uses a for..in loop to iterate over an array. This type of loop should never be used with an array for two reasons: If any other code in the page extends Array.prototype the code will break, and the order of iteration is not guaranteed. These loops need to be converted to numeric for loops or $.each() or any similar alternative.

One last point that is just a matter of taste, but I think the code would benefit quite a bit if it followed the popular jQuery convention of using a $ prefix on variables that contain jQuery objects.

I love outliners, and I'd really like to contribute to this project, but the code is so strangely formatted that I'd have a really hard time with it. I wonder if the authors would consider adopting a more conventional coding style, or if they just like it the way it is?

-----


I think the programmer was just getting comfortable with coding in an outliner when he wrote that code. I would consider that indentation a bug, when and if I work in those areas, I'll fix the indentation there. Thanks for pointing it out.

-----


Ah, thanks, Dave, and I'm sorry I went a bit overboard on my remarks about the code! The project does look promising; now I'm encouraged to check it out some more. :-)

-----


Not at all! :-)

I am a total bugger about formatting code.

The outliner approach is pretty good but not perfect.

If-then-else is the sore thumb, for sure.

Along with try-catch.

But overall, outliners are a huge win for writing code.

Let's be hardasses about this stuff, but also understanding.

I think your approach is perfect.

-----


I didn't know what an outliner was:

From the Git page: An outliner is a text editor that organizes information in a hierarchy, allowing users to control the level of detail and to reorganize according to structure. Your notes can have full detail, yet be organized so a casual reader can get a quick overview. Outlining is a great way for teams to organize work.

-----


And isn't this just a special case of an object graph where all the objects are strings, the relationships sub-objects can't have two parents and the traversal is over when you've reached a leaf?

What about hierarchies of objects that aren't strings? (I'd like to organize them too).

What about hierarchies that aren't a strict tree? (I can't really do my genealogy on this).

P.S. I like what Dave does with outliners but I'm not sure I'd apply them everywhere he does.

-----


I've fiddled with this extensively. The problem isn't data representation; sure, "outlines" are "just" graphs. The question is, what on Earth does your UI look like? Editing "graphs" is hardly more structured than creating a "data editor"... ok, those are some nice English words you've got there, but how does it actually work?

At least by limiting it to text and stuff that looks a lot like text, you can produce a real application that does real things of real value. It may not be suitable for everything, but your thing that is suitable for "everything" is likely come out being suitable for nothing in practice.

-----


That's a hard problem - I haven't done any "fiddle" but I've spent a lot of time doing Gedankenexperiment and haven't come up with anything I believe is remotely applicable. The genealogy example I gave is simpler but I'm not sure I've seen an editor for that use-case that's optimal either.

Maybe the problem just can't be simplified further? And as an aside, I wasn't trying to disparage Dave Winer's implementation of tree editing at all.

-----


I wrote one. It might not be exactly what you had in mind. It works okay for me for brainstorming: github.com/andrewf/graphpaper

-----


When folks stop talking about trees and start talking about graphs, they seem to forget that you usually want to have an order on the edges.

I think an outliner is a great way to explore a fully connected directed graph with sequenced edges; just don't hit "Expand everything" when the graph contains a cycle. Leo http://leoeditor.com/ expends a lot of effort to avoid cycles, which shows up in slow execution when adding edges ("cloning", in its terminology) to a node reaching a significant subgraph.

If the graph can contain cycles, a recursive expander needs to contain cycle recognition and terminate after a finite number of trips through the cycle (probably one).

-----


What do you mean by an "order on the edges"? I'm only superficially familiar with graph theory.

-----


In graph theory, one usually has a set of nodes (A, B, C, ...) and a set(!) of edges between the nodes, either directed ((A,B), (A,C), (B,A)) or undirected (in which edge (A,B) implies (B,A), (A,C) implies (C,A), etc.). Sets don't have an order; most graph theory doesn't distinguish between the set of directed edges ((A,B), (A,C), (B,A)) and ((A,C), (A,B), (B,A)).

On the other hand, when dealing with trees (aka outlines) it is almost always assumed that there is a significant order - a sequencing - on the edges between parent and child, and that it means something if you change the order of the children (outline subheads).

I'm interested in more general (directed) graphs that nonetheless have a sequence - an order - on the edges, and where operations on that sequence are explored, in addition to the more usually examined addition and removal of edges. Until holographic displays are cheap (and maybe even after) I think trees, aka outlines, are a great visualization technique for such graphs - just take precautions with "Expand All" when the edges contain ((A,A)) or ((A,B), (B,A)) or any other length cycle. Or, as an outline

    This is heading A
        This is heading A
            ....
    This is heading B
        This is heading A
            This is heading A
                ....
            This is heading B
                This is heading A
                    This is heading A
                        ....

-----


Right, an ordering relation on the edge objects. facepalm That should have been obvious, but I usually think about trees in terms of vectors of children, not traditional graph theory.

I like trees too. I think that as long as computer memory is linear, our serializations are going to be linear, so even when we get holographic displays, our primary abstractions should be linearly serializable (so we don't get lost in leaky abstractions), which means trees. A graph structure built on that would have to be some form of "magic" layered on top, based on links embedded in the tree. Among other possibilities, you can make the "edges" be little independent trees that link to the "nodes".

-----


It's OK. OpenOffice/LibreOffice don't either and they just yell at people that notice MS Office's outliner functionality is missing in OOo.

-----


Me either. That info really should have been in the announcement. I read through the whole thing and still had no real idea what Concord is.

-----


It's crazy to me that there seems to be a backlash against this project being licensed under the GPL. Thank you for choosing copyleft.

Also, if I got it right, an outliner is a note taking application? The best note-taking application I know of is, by far, org-mode in Emacs.

-----


Ah, dwiner, at last my long Linux nightmare of having no decent outliner shall come to an end....

Urf, budgeting the time for this may be a challenge, but odds are good that this can be dropped into a XUL shell to obtain a traditional "local" filesystem outliner with only a few hundred lines more of grease. I'll have to see what I can do. (I've done it once before for something else.)

-----


No decent outliner on Linux? http://orgmode.org/ is by far the best i have seen so far, so could use outline-mode if you do not use any of the extra features. There is something similar to outline-mode for vim users if i remember correctly.

-----


Yes, I use VimOutliner, which is perfect when you already know how to use vim.

-----


Have you ever tried FreeMind? Not an "outliner" like this, but a good way to organize content, and it's Java so it Runs Everywhereâ„¢

-----


Should really have a demo link somewhere.

You can click through to github, to be told that it's what their Fargo tool is based on, and from there you can click through to that... to be told that you have to link it to your dropbox account before you can even try it.

-----


http://littleoutliner.com/

-----


And littleoutliner is an instance of Concord as well. ;-)

-----


In addition to the all ready linked to Little Outliner version, the project on GitHub has to examples.

-----


There are links to two demos in the readme.md file in the repository.

https://github.com/scripting/concord/blob/master/README.md

-----


I would like something like this that translates directly into JSON. Kind of a cross between concord and http://jsoneditoronline.org/

It will just have to be something I write myself, I guess.

-----


hope you all don't mind. little self plug on the subject - I also have an open source outliner

here is the source http://github.com/hhuuggoo/efficiently

and the demo: https://eff.iciently.com/docview/r/4ed70c031a7ba32edb000002/

But this one is an app, not a plugin, so it might be less useful to some.

-----


3k LOC in a single file... ouch. Someone introduce Dave to makefiles.

-----


I'm almost certain he writes the code using an outliner tool as well like was the case for the scripting language that shipped with frontier and the OPML editor so that probably makes it easier for him to manage. At least it will be easy to include into a project ;-)

-----


It's only a problem if you edit in a flat text editor.

If you look in the opml folder of the repo you'll find the source files for all the js and css files.

-----


Ah, thanks for pointing those files out. I'll have to try loading them up in Fargo for fun.

-----


Is 3k lines in a single file really considered that bad? I've never had a problem dealing with it.

-----


Leo is the last outliner you'll ever need. http://leoeditor.com/

-----


GPLv3, which will put off some people who would be fine with GPLv2.

-----


I think more project should be this obvious with their choice of GPL, makes it easier to dismiss :-)

-----


I think more comments should be this obvious with their trolling & stupidity, makes it easier to flag :-)

-----


Might not have been the highest quality comment but there are lots of companies out there that outright forbid GPLv3 code to be used for anything really.

-----




Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: